10TB

I am in California for a quick 2 day visit this February, on IETF business. But I'm not so busy that I couldn't stop on the way from the airport to pick up some storage from Fry's :-)

Photo credits (c) 2017 by Jari Arkko

Revenge of the Electronic Shower

If it has electronics, it can break. Like the my teenage son's shower unit...

Oras Ventura is a battery operated shower controller than has a display and drives the water controls via electronic motors. I have two of these in the house, and they generally have given very little grief in their soon 10 years of existence.

The units display temperature, and strength of shower can be controlled via up/down buttons, as well as choosing hand/top shower. Not a big deal as such, and other than looking great they don't add that much functionality. One potentially useful function is that there's an automatic 5-minute cut-off for the shower, if it is left accidentally on. Possibly useful for people like me who worry if they left shower/oven/iron on when they leave the house :-)

The downsides are that this brings more parts that could break, and the potential for battery changes. Also, the Venture seems like a first-generation product. The response to inputs is sluggish. And you can't load any shower apps :-) And there's no touch screen or WiFi. WTF?

But the four D20 batteries last a long time, in the order of five years even with daily use. However, now one of the units is acting up. Not turning on the display, making a constant noise, and not responding to inputs. It first displayed E10 (per unreliable teenager reports) and now displays nothing, even with good batteries.

Revenge of the Things?

More Health Gadgets - Withings BPM

Yay, another gadget arrived today! For a long time, I've been a Withings weight scale user, and have liked the device a lot. But now I got a blood pressure meter from Withings. This is a review of the device, based on my initial experiences.

The Good

First things first, the design is quite cool, the hardware is sturdy, the finish is perfect. The overall idea is great, your measurements sent to the Internet over Bluetooth. The user interface for looking at the measurements is easy and looks great. Furthermore, Withings allows you to download their data easily, as well as upload other measurements to their database. This makes moving your data to your own storage or other providers easier; it avoids the customer lock problem.

And, most importantly, two days have passed with this device and I have made more measurements than I made with the previous equipment all summer. I need to take measurements and have an idea later what numbers I have seen. Having to open a computer to take notes is make-work.

History graphs show developments over longer period of time. Like in this case where (sadly) my weight keeps increasing:

The Bad

There are some complaints, as well, however. A practical issue was that it took half an hour for me to get the device to work with my iPad. Android phones, iPhones, and iPads are all listed as supported devices, and the connection instructions are simple - pair the Bluetooth device, then push the start button and wait instructions from the application.

Except that in my case the application did not react in any way. Nothing. The device was paired, but not recognised by the application. The instruction booklet said nothing useful about this case.

After some googling it turned out that there's a bug that prevents the measurements to start, if the application is already running. But exiting it didn't help; the application did not start when I pressed the button the device.

Some more googling revealed that while iPads are supported, there is no iPad application. One has to download an iPhone application, and only that application supports running the measurements, even if the iPad application supports showing all measurements. And that was the one that I had used for the weight scale as well.

The software installation initiated by Bluetooth pairing was also cumbersome. The pairing takes you automatically to Appstore for loading the application, but to a place that finds no applications and offers just wrong choices for what to do next (like redeeming a voucher). The instruction booklet says that you should either install the application or update it, but nothing about the case where the application is already installed and most recent version. And that is of course the likely situation if you already own a previous Withings product.

The silly thing is that all this could have been easily avoided if the pairing process would have downloaded the right application or if the instruction booklet would have included separate instructions for iPad users.

The other annoying this is that the meter has a "Start" button. But that button doesn't actually start the measurement -- it just starts the application, and then you have to press the real Start button in the application.

Internet of Things Architecture Thoughts

This is just one of the many examples where we buy things that are bonded to our smartphones. You cannot operate them without your phone. Granted, you are not likely to stop carrying your phone around any time soon. And the ability to see the measurements on high-quality user interface is very helpful.

That being said, I cannot help wonder if there's a better way to do this. In particular, there are many devices that are not designed to be used on a person; they could not rely on a smartphone in any case. And even for the blood pressure monitor, I would just like to take a measurement, and not have to press buttons on my iPad.

What the smartphones are useful for is the initial configuration, and the user interface when you need it. So perhaps instead of being a mandatory part, a forced hop on the path of packets, maybe the smartphone could be the way to configure these devices to use the relevant mobile network or wireless LAN, and then use them for the user interface when they are present? And when they are not present, the devices could just work, and connect to the Internet directly. Like this:

This would also be a great way to configure devices that you do not carry around, e.g., home appliances. Configure once, let them do their thing on the Internet on their own.

Conclusion

This is an overall nice product, well produced and easy to use once you get going. I keep wondering if there would be a way to make it similar to my weight scale; no iPads or iPhones or anything needed. Just the Wireless LAN connection.

You can buy the BPM from the Withings webshop (but be careful to choose the right webshop, there are different ones for different continents).

Photos (c) 2015 by Jari Arkko.

Fast Cars and Networks

How fast can you make a 23-year old Volvo 740 go? Turns out that you can make it go pretty fast... at least 200 mbit/s, maybe more.

I recently got interested in maintaining my old car. Well, it was either maintain it or take it to the scrapper. I chose maintenance, and decided to make two important actions: first, get rid of the rust and repaint the car. And second, add high-speed Internet. With IPv6, of course.

I acquired an LTE Advanced subscription from my local operator (DNA) and a router that can support fast connections. LTE Advanced is a new variant of the 4G LTE standards, capable of speeds up to 300 or 450 mbit/s, using techniques such as carrier aggregation.

To be clear, these are some very fast speeds. My current ADSL connection at home is 18 mbit/s, so there is potential for 10-20x improvements. But the deployment of this technology is just beginning, so it is available only in select areas, and of course, carrier aggregation works best when there's enough spare capacity in the network and not too many other users. I do not yet have a lot of experience about this, but in most places I get 50-80 mbit/s easily, and saw also speeds approaching 200 mbit/s. Cool!

Someone asked what I use the network for. Well, to be honest I don't know. Once the technology is there, ideas for applications can come. What Internet function would you like to see in a car?

Details: I am using Huawei E5186 as a router, and have generally good experiences with this device. It is easy to setup and both IPv4 and IPv6 just work. Some configuration is possible, but isn't strictly speaking needed - the system works out of the box.

For IPv6, the DNA service provides IPv6 for all customers, and as long as the router supports this, devices attached to the router get it too.

On the network side, I believe DNA uses Ericsson network equipment.

For fast connections, the internal network in the car needs to be fast too; I'm using 802.11ac, so the router and devices need to support that.

All this equipment is of course mostly made for non-car use. The router draws 2A of 12V. I'm a bit reluctant to use the car's electricity directly, as the voltage tends to vary quite a bit. Unfortunately, voltage regulators for 12V to 12V weren't in the stock for the local electronics store, so I went for an inverter to 220V and then back to 12V. Not pretty, and uses too much electricity, but it is a temporary solution.

Photos (c) 2015 by Jari Arkko.

Making Networking Easier for Users

One of my pet peeves is how hard it is to connect to various networks. I am on a trip today, and my first stop was at the Helsinki-Vantaa airport. A modern airport that prides itself on efficiency and good infrastructure. Their Wi-Fi has worked very well for me. I came to the airport, launched my browser, and confirmed my connection to the network with one click. The network is fast, has no time limits, and is available everywhere within premises. (It would probably work even in the newly opened airport sauna, if my tablet could take the heat and humidity.)

And, having travelled a lot in recent years, this network really is one of the best airport Wi-Fi networks in the world. So all is well, right?

No.

Many people, me included, have data subscriptions on their devices. This allows cellular networks to be used when no Wi-Fi is available. So I can get Skype messages, send photos, and do anything I like everywhere, or at least within my home country. There is only one place in Finland where my smartphone stops working: the Helsinki-Vantaa airport. The device sees the Wi-Fi, connects, and stops, waiting for the user to make that one click.

Of course, if I need to use the Internet I will notice all this and make that one click. However, I believe we are increasingly in an always-connected world, and information flows when it needs to. I do not want my devices to stop, I want them to keep on working. Even that one click is too much. And it is unclear what value that click brings anyone, me or the airport.

But the Helsinki-Vantaa network is one of the best. My next stop was a large hub airport in northern Europe. I checked if there was local Wi-Fi, and there was. My browser told me that I could use either the free or the paid network. I decided to try the free one first. A screen comes up that requires me to register. But the amount of information that they ask is... at least tiresome, if not privacy insensitive. The e-mail address and password I can understand. Maybe the phone number, because some airport networks send a password over on SMS. But I also had to fill in birth date and country. Why?

But this was just the start of my failed attempt to use the network. I got an error message that my chosen e-mail or password was invalid - without any explanation of why they were invalid. I guessed that perhaps I had entered an e-mail address that I had used on my previous visit, and entered another one. Not wanting to fill all information for the second time, I used the browser back button to get to the registration page. Big mistake! After changing my information and pressing register, I got an error.  I should have started again from the beginning.

I gave up and decided to try the paid network instead. I clicked on the payment page, but had to stop for a few minutes to walk to my gate. At the gate, I entered the required information. Including my mother's maiden name. Why? Having fulfilled all information, I later realised that my walk had made it impossible to complete the transaction, whether or not I was revealing all my personal information. I got a "your session is no longer valid" error message.

I could go on, but you get the point. The problems with these networks are very wide spread, and in my opinion, unnecessary. Earlier this summer I was waiting for my delayed flight at a major North American airport, and had trouble getting more than a few packets exchanged via their local network. Not enough to download any e-mails, for instance. Later a friend posted a picture of what his wireless network analyser showed at that airport: all the airport's access points were on the same three channels, making the radio environment in practice unusable.

Couple of years ago we had a large meeting in a hotel in Paris, and our network engineers ended up redesigning the hotel network to work much better, in a situation that was similar to what we saw at the above airport.

You might argue that I am talking about a first world problem. Travel. Airports. Hotels. But take the airport Wi-Fi situation as just one example of a more general problem. We all use networks, in developed and developing world. And many of those networks are often in shopping malls, coffee shops, and bus stations. We need to improve their usability.

The smartphone revolution that we have seen last couple of years was initiated largely thanks to the new, easier to use touchscreen phones and operating systems. Perhaps we need a similar revolution in wireless networking. And I think we have had a lot of the technology around but now it is time to put it into use. Examples of this include Hotspot 2.0, 802.11u, EAP, and various network connectivity checkers in our devices. (I worked on EAP at the IETF over ten years ago, but it is only now that it is getting more widespread adoption. A long time!)

And this problem is not limited to Wi-Fi. Again that is just an example. I also have a lot of experience of trying to acquire SIM cards in various places. I've had great experience in some countries and with some operators. Others struggle in providing a service. Some operators sell SIM cards and the needed data allowance package in different shops. Why? And the top-up process can be difficult. An operator in Europe requires a local phone number for the process to complete. Not particularly useful for tourists, is it? An Asia-Pacific operator uses a web-page process that only works on some browsers, not all. Many countries require proof of identity before you can use a network. Perhaps I can understand that, but it does not stop there. I was once asked for a formal proof of my address within the country. How can I produce such a proof, when staying at a hotel?

Here are my guidelines for providing an effective Internet access product:

• If you want to provide an open network, make it truly open.
• If your network is for subscribers, employ an automatic authentication mechanism that does not require the user to perform a web login.
• If you charge for the use of the network, make it easy to provide the credit card information
• If you sell cellular access, make the right size SIM cards available to everyone easily.  Do not force users to go through extra steps to "enable" the SIM card. You sold it, it can be enabled automatically.
• Any web-based purchase, top-up, or login process needs to be tested with all browsers and in different conditions.
• Do not collect information that you do not need.
• Radio networks need to be tested and configured properly.

In short, people want your service. Make it easy to buy and use it!

Jari Arkko

Photo credits (c) Jari Arkko and Joe Abley

IP for Smart Objects

At Ericsson's Lab web site, Jan Höller and myself have published an article. This article deals with the general architecture for the "Internet of Things", and how we must break the current application-specific silos, and move to a model that employs general-purpose network access technology, IP & IPv6, and web technology. The link to the article is here.

Home networks. By magic.

The routers in my automatically configured IPv6 home network

I wanted to talk about personal home networks on IPv6. I have built a prototype of some cool new technology and my first network is now up and running, having configured itself completely automatically. My implementation is a hack, and only works in very limited cases. Nevertheless, I think it is the first implementation of this technology, currently under development at the IETF's new HOMENET working group. And I believe this technology might have an impact on how people set up their home networks in the future. Hence this article.

(Note that the blog is not about finding an ISP that supports IPv6. And not about home gateway products that are IPv6 capable. Of course those are important issues, but there has been enough discussion about those topics in various forums already. See the end of the article for further details on those.)

What I want to talk about is your home network itself. Can you have any type of network? Any number of nodes? What kind of network architecture should you choose? Is there a lot of configuration effort? The simple case is easy, when there is one router and network behind it -- RFC 6204 has the details. And we all know how to handle this and even the little bit more complex cases on IPv4; it is far from perfect but the technology is well understood.

I Have a Dream

The dream is that you can have any number of routers and hosts and connect them in any way you see fit. And the network comes alive automatically, all parts of the network shall have address space, routers shall know where to send packets, and names get resolved to addresses. And all this should happen without any human touch. (Especially by my mother. Bless her, she is a wonderful person. But she is not that good in configuring IPv6 routing entries.)

"One Subnet Should Be Enough for Everybody"

The simple case with one subnet is easy to deal with. There is already plenty of equipment out in the market that does that. There is an argument that says going beyond this model leads to problems, and that it would be prudent to stick with the simple model. I just don't know if the simple model is sufficient. I can offer a few example cases where it is clearly not sufficient, however:

• Network separation through policy. Many of today's wireless routers have by default a "Guest" and "Private" networks. It is expected that upcoming applications -- such as smart energy networking for power companies -- may increase requirements for having multiple networks in homes.
• Heterogeneous network technology. Some types of link layer technologies can not be bridged together, leaving routing or NATting as a the only option. Other technologies may be bridgeable, but their speed differences are too big to make it wise. For instance, bridging together Gigabit Ethernet and some low-speed sensor networking technology may lead to the latter being overcome by the multicast and broadcast traffic of the former.
• Organic growth of networks. People who have, for instance, insufficient wireless coverage in their houses often end up buying a new device and adding it to their networks. More often than not, these new devices have been routers/NATs in the IPv4 world.

My dream came with a nightmare as well; we might get this wrong. The biggest danger is that IPv6 will be seen as hard to use, leading people to adding more NAT devices into their networks instead. Another danger is causing similar problems as chained NATs already do in the IPv4 side in an organic growth scenario. For instance, difficulties in communicating between devices within the same home. And I really do not want to see the NAT66 solution used for connecting two different parts of an IPv6 network.

The HOMENET WG is trying to address these requirements, by creating a solution that supports multiple routers, multiple subnets, automatic prefix-configuration, automatic routing, and across-the-home name resolution. The working group is currently designing the architecture and various proposals for solutions exist as individual proposals. The group is focused on recommending the use of existing tools, as things like DHCP-based prefix delegation and prefix announcements via Router Advertisements are the right thing to do. And if routing is needed, the existing routing protocols can certainly handle the task. However, the group will have to create a few extensions in some cases where fully automatic configuration is not possible otherwise.

HOMENET WG meeting in Paris, France

The group is looking at a number of different solutions. There are routing protocol designs based on OSPFv3, RIPng, RPL, and even simple routing extensions for Neighbor Discovery options. For prefix assignment, the group has two alternate designs, one based on hierarchical DHCP prefix delegation and another one based on distributed operation over a routing protocol.

The picture below shows the architecture for an OSPFv3-based design, providing both routing and prefix assignment capabilities.

OSPF-based home routing architecture

Example Network

The below figure shows my home network, a good example of a network that would benefit from the HOMENET technology. The network has over 200 Gigabit Ethernet ports, 4 kilometers of Cat6 cable, and enables things like my laundry talking to me via Facebook. In other words, it does all the usual geek network things.

One home network

But the important point from the perspective of the actual network architecture is that I had to create a dozen different subnets within my network. I obviously needed my primary internal subnet, but also had to create other subnets for visitor networks, NAT64 networks (these consume two prefixes), and some of my home automation and utility networks were in their own address space for various reasons.

Subnets in the above home network

I'm a geek, and at the beginning I thought I could easily handle all this manually. Then I realized that I had to run a routing protocol to keep the route entries correct. And a tool to monitor what devices I have in my network, as I had lost count. And then I forgot what prefixes were assigned where. It was too hard to keep all those numbers in my brain.

And this was only the beginning of my problems. A couple of months ago I woke up one morning to realize that my ISP had renumbered my entire network. I had to start over. The moral of the story is that even us geeks need automation, let alone our mothers and other people who have no expertise in networking technology.

Implementing HOMENET

I created a prototype to test the ideas of HOMENET. The primary goal was to understand what the real needs were, find out the missing pieces, as well as to see if our specifications for the OSPFv3 extensions were on the right track. I now have a small implementation. The code is unreadable, the design is a hack, and it still misses large parts of the necessary functionality. But it has already given me an opportunity to see if the ideas work in practice.

First off, the technology seems to be working as intended. I'm writing this article in a network configured by the prototype, so it works. And it feels like the natural way of doing things. If we get the technology fully specified, I'd expect other networks to want to use it as well. Corporate networks, for instance, would probably find it useful.

The implementation is capable of automatic configuration of OSPFv3 itself, generating router identifiers for all involved routers, assigning address space in an optimal manner to the entire network, discovering all available DNS servers, and configuring Router Advertisement daemon to advertise the assigned prefixes and DNS server addresses. And since this week, the prototype also automatically configures Ericsson NAT64 devices by making an assignment for the address space that those devices need.

Logs showing how router IDs, prefixes, RAs, DNS,
and NAT64 have been configured automatically

I've learned a number of detailed lessons about the protocols necessary to do this; those lessons will be fed back to the IETF working group. But the main lesson for me was how connected the routing protocol based auto-configuration software is to other parts of the system. Obviously, an OSPF router talks to other OSPF routers. But in this case it has several other interactions as well, illustrated in the below figure.

Dependencies

The first group of interactions relates to where the system gets the usable address space it needs. The preferred source for address space is your ISP, and DHCP prefix delegation is the best way to retrieve address space from your ISP. However, not all ISPs support this protocol, and some users may have to manually configure their address space in one of the routers. From there on the HOMENET technology can distribute the address space to all other routers in the network. Finally, when the home routers are coming up for the first time and if no connection to the ISP has been set up yet, they are in a difficult position. There is no address space to be used, but communication between the different nodes in the network is going to be difficult without addresses that can be used across the entire home network. At this point it might be useful to generate some Unique Local Address space -- a feature of IPv6 -- that can be used until actual ISP connectivity comes online.

Another set of interactions relates to where the address space is used: the address space needs to be configured to interfaces, advertised in Router Advertisements, given to the use of a NAT64 implementation, and so on. In my network I also need some address for servers that represent legacy sensor networks on IPv6.

Finally, even when addresses have been assigned and packets are routed correctly, the end user will not be happy unless hosts can resolve names to addresses. For this to happen, the hosts need to be told where the DNS servers are. This can be done via adding DNS server addresses in options to Router Advertisement messages. But the auto-configuration system still has to figure out where the DNS servers are! There are couple of different approaches to this. One straightforward approach would be to run a server on each router, resolving names through the global DNS root system. I have chosen to use a different approach, where I attempt to discover existing DNS servers from my ISP or from my own network. I use the DNS Discovery Daemon (DDD) for this task. There is an interesting complication, however, in that IPv6-only and dual-stack networks are different in some respects. First of all, in a dual stack network the configuration of IPv6 DNS servers is often not absolutely necessary, as the IPv4 DNS servers can serve IPv6 content. But things get more complicated with network tools like NAT64, because they involve translation of DNS results through a technique called DNS64. Given this, a name server that acts as a DNS64 is something that you want to use behind a NAT64 device, but not elsewhere in the network. DDD uses an advanced technique for probing the name servers to determine whether it is performing normal or DNS64 operations.

Some of these interactions have interesting aspects that require further work. The assignment of DNS servers is one such area. Timing the start of the ULA generation process is another one. We will be addressing these issues in the coming months.

Implementation Experiences

The OSPFv3 auto-configuration parts were very simple to implement. The prefix assignment was not as trivial to implement, but still relatively easy. These new extensions of OSPFv3 are in the order of two thousand lines of code, so they should be relatively easily be added to any OSPFv3 implementation. Assuming the implementation has been made reasonably extensible.

However, OSPF itself is a very complex and difficult protocol to implement. I chose to implement it from scratch. How hard could it be? It turned out that it is very hard. I do not yet have a full implementation, among other things the actual route computation is still missing even if the flooding process is complete. In any case, any sane person would start from an existing implementation and would just add the new parts. Oh well. I have learned a lot from routing protocols with this exercise, which was part of my goals.


Conclusions

HOMENET is an interesting piece of technology that has promise to make the configuration of home and other networks much simpler in IPv6. The working group at the IETF is in an active design phase; the participation of all interested parties would be welcome there. There are also several implementation efforts under way, not just mine. I would say, however, that we are still in the exploration phase as we keep discovering what this technology could do. The specifics of the protocols will for sure keep changing. If you have feedback on what kinds of things should be auto-configured in networks or how we should go about it, let me or the working group know!


Details

This blog entry is based on my presentation at RIPE-64, Ljubljana, Slovenia, on April 19th, 2012. See the slides for more information, or go the web page for the HOMENET working group at the IETF. I'd also like to thank my colleagues and various IETF people for interesting discussions in this problem space: Mark Townsley, Ray Bellis, Michael Richardsson, Ari Keränen, Lorenzo Colitti, Fred Baker, Lee Howard, Wassim Haddad, Joel Halpern, Jan Melen and others: thank you. I'd also like to thank Ericsson for letting me work on this (among the thousand other things :-)

HORD, my routing daemon is not open source, at least not at this time. But DDD, the DNS discovery part is. Look here for the details.

IPv6-capable ISPs and Routers

Note: Regarding IPv6-capable ISPs: there are plenty, check out Comcast in US, Nebula in Finland, or Mobitel in Slovenia for instance.

There are also plenty of IPv6-capable routers, my personal preference is Linux-based small PCs but you can also check out commercial models from Netgear, Cisco, and others.

Start of the HOMENET implementation effort in Christmas 2011

Photo credits (c) 2010-2012 by Jari Arkko