AsiaBSDCon 2007 Proceedings March 8-11, 2007 Tokyo, Japan INDEX P1: A NetBSD-based IPv6 NEMO Mobile Router 001 Jean Lorchat, Koshiro Mitsuya, Romain Kuntz (Keio University, Japan) P2: Reflections on Building a High Performance Computing Cluster Using FreeBSD 009 Brooks Davis (The Aerospace Corporation/[email protected], USA) P3: Support for Radio Clocks in OpenBSD 023 Marc Balmer ([email protected], Switzerland) P4: puffs - Pass to Userspace Framework File System 029 Antti Kantee (Helsinki University of Technology, Finland) P5: An ISP Perspective, jail(8) Virtual Private Servers 043 Isaac Levy (NYC*BUG/LESMUUG, USA) P6: Nsswitch Development: Nss-modules and libc Separation and Caching 051 Michael A. Bushkov (Southern Federal University/[email protected], Russia) P7: OpenBSD as a Development Platform – Ryan McBride ([email protected], Japan) P8: How the FreeBSD Project Works 057 Robert N. M. Watson (University of Cambridge/[email protected], United Kingdom) P9: OpenBSD Network Randomness Injection: Further Improvements – Ryan McBride ([email protected], Japan) P10: SHISA: The Mobile IPv6/NEMO BS Stack Implementation Current Status 067 Keiichi Shima (Internet Initiative Japan Inc., Japan), Koshiro Mitsuya, Ryuji Wakikawa (Keio University, Japan), Tsuyoshi Momose (NEC Corporation, Japan), Keisuke Uehara (Keio University, Japan) P11: Bluffs: BSD Logging Updated Fast File System – Stephan Uphoff (Yahoo!, Inc./[email protected], USA) P12: Implementation and Evaluation of the Dual Stack Mobile IPv6 079 Koshiro Mitsuya, Ryuji Wakikawa, Jun Murai (Keio University, Japan) P13: Recent Improvements in OpenBSD's IPsec Support – Mathieu Sauve-Frankel ([email protected], Japan) P14: SCTP Introduction – Randall R. Stewart (Cisco Systems) P15: Security Measures in OpenSSH 091 Damien Miller ([email protected], Australia) P16: Porting the ZFS File System to the FreeBSD Operating System 097 Pawel Jakub Dawidek ([email protected], Poland) A NetBSD-based IPv6/NEMO Mobile Router Jean Lorchat, Koshiro Mitsuya Romain Kuntz Keio University The University of Tokyo Graduate School of Media and Governance Gr. School of Information Science and Technology Fujisawa, Kanagawa 252-8520, Japan Information and Communication Engineering Email: lorchat,[email protected] Email: [email protected] Abstract— This paper defines the problem statement NEMO Basic Support allows a group of nodes to of vehicle-embedded networking in order to communi- connect to the Internet via a gateway: the mobile cate with the infrastructure (the Internet) as well as router. It can change its point of attachment to with other cars. Based on this problem statement, we the IPv6 Internet infrastructure while maintaining explain the steps that allowed us to build a mobile router addressing this problem by using state of the all the current connections transparently for all art software. This software includes the NetBSD-current the nodes within the mobile network and their kernel and networking code developed by the Japan- correspondent nodes. The only node in the mo- based WIDE project working groups: the KAME IPv6 bile network that is managing the mobility is stack with SHISA extensions for Mobile IPv6 (MIPv6) the mobile router itself. It updates its current and Network Mobility (NEMO) support, and the Zebra- location in the Internet to a special router known based OLSR daemon with IPv6 extensions allowing for a Mobile Ad Hoc Networks (MANET) and NEMO as the home agent, which is located in the home cooperation, formerly known as MANEMO. network. The home agent maintains a table of relationships between mobile routers permanent I. INTRODUCTION addresses, temporary addresses, and mobile net- Current research on Intelligent Transportation work prefixes. All the traffic to or from the mobile System (ITS) focuses on vehicle-to-vehicle com- network is exchanged between the mobile router munication and information exchange between and the home agent through an IPv6-over-IPv6 vehicles and the infrastructure network (Internet). tunnel. This protocol can then be used to bring In the near future, vehicles will embed various global access to any car component by adding a computers and sensor nodes, making a network, mobile router to the car environment. This is one whose data will be exchanged with nodes in the of our goals in the InternetCAR project [3], and Internet for various purposes such as monitoring, we show our communication model on Fig. 1. safety, or entertainment. For that purpose, the NEMO Basic Support is thus a very likely CALM1 (Communications, Air Interface, Long architecture to ensure permanent connectivity in and Medium Range) architecture specified at ISO mobile environments. Although the main use case (TC204, WG16) recommends the usage of IPv6 would be to connect any kind of vehicles to and IPv6 mobility protocols to ensure permanent the Internet (such as cars, trains, buses, etc.), and uninterrupted communication while moving the underlying architecture would be the same in the Internet topology. (IPv6 and NEMO Basic Support) but customized NEMO Basic Support [1], specified at the IETF at the application layer according to the usages: in the NEMO Working Group [2], was standard- monitoring, safety, entertainment, etc. ized to solve the IPv6 network mobility problem. The Internet Connected Automobile Research (InternetCAR) Working Group was established 1http://www.calm.hu/ within the WIDE Project [4] since 1998 to con- 1 between Wireless LAN and cellular interfaces. However, no vehicle-to-vehicle communication is possible, and no monitoring software on the mobile router makes the evaluation of the system difficult. The purpose of this paper is twofold: first we make out and explain the constraints of such in- vehicle network architecture for both hardware and software sides. We then explain the work done on the implementation side to build a new version of the InternetCAR’s in-vehicle mobile Fig. 1. InternetCAR communication model router, based on the NetBSD operating system with respect to the previously defined constraints. We then show an evaluation of this work. II. A CONSTRAINED ENVIRONMENT As explained in the previous section, one goal of the InternetCAR project is to build an em- bedded mobile router that is suitable for car operation. And while the car environment is not as constraining as some other environments from the embedded computing domain, it still has some features that must be accounted for when choosing hardware and software solutions to spe- Fig. 2. SHISA daemons architecture cific problems. We will explain these environment peculiarities by distinguishing between hardware nect vehicles to the Internet [5], [6], [7] by and software considerations. developing the necessary tools and demonstrate A. Hardware related considerations their applicability in a real-life testbed. We aim to implement all the missing protocols to build an Since the car is moving, we have to pay extra in-vehicle Mobile Router. It is designed to support attention to the toughness of the hardware. The IPv6 mobility and multihoming (simultaneous us- road conditions can make the embedded computer age of several interfaces to share and load-balance bump, so that moving parts should be avoided as the traffic, or for fault-tolerance purposes). much as possible. And of course, as long as the InternetCAR is also developing a monitoring car is moving, it makes wireless communications application for demonstration purposes. Most of (and especially all kinds of radio communica- the outputs are freely available implementations tions) mandatory. for BSD operating systems, such as contribution As an embedded car equipment, the size of to the KAME IPv6 stack [8], and the SHISA the mobile router must be kept to a minimum in mobility stack [9]. order to save space and weight inside the car. This The previous in-vehicle mobile router was means avoiding traditional personal computer de- based on the NetBSD 1.6.2 Operating System. sign and looking for single board computer alter- The KAME IPv6 stack and SHISA stack [10] natives. were used to manage the network mobility. Basic Although AC current from the mains is not multihoming features allowed vertical handover directly available inside the car, we have sufficient 2 access to power resources through the car power must also obey the guidelines that come from source, either the alternator or the car battery. hardware constraints of the car environment. Eventually, cars are equipped with lots of cable, yet there might be no networking cables available III. INTERNETCAR TEAM IMPLEMENTATION to interconnect equipments within the car, espe- cially for current vehicles. Which means that we A. Hardware Platform might have to resort to wireless communications again to provide in-car networking. By taking all hardware-related constraints into account, we decided to use a Soekris2 single- B. Networking related considerations board computer as the key element for our mobile router. While it features an integrated processor, We have already introduced the ISO specified memory and two network controllers on the same recommendation about IPv6 and NEMO proto- board, it also provides room fox expansion with cols. These protocols allow to hide mobility in a two Cardbus and one MiniPCI slots. This will very convenient way, especially by relieving car allow us to use many wireless network interfaces. equipments from any mobility-related overhead, The mass storage is fitted through a Compact handled by the mobile router. Flash slot, which can accommodate either a flash However, in addition to these next generation card or a micro hard-disk. We chose to use flash mobility protocols, we need to take the vehicle cards to achieve a zero-spin architecture, which to vehicle (V2V) scheme into account. Using means that our mobile router has no moving part. the previously mentioned mobility protocols, V2V communication can become very painful because the traffic has to go all the way back to both B. Operating System Choice home agents. In this case, protocols for mobile ad We chose the NetBSD operating system for hoc networks can be used to discover neighboring several reasons.