by Carlos J. Bernardos, Ignacio Soto, and María Calderón, Universidad Carlos III de Madrid
The Internet Protocol (IP) is currently accelerating the integration of voice and data communications. The Mobile IP protocol enables host mobility support, but several scenarios exist today, such as the provision of Internet access from mobile platforms (for example, planes, trains, cars, etc.), making it necessary to also support the mobility of complete networks. In response to this demand, the Internet Engineering Task Force (IETF) has developed the Network Mobility (NEMO) Basic Support Protocol , enabling IPv6 network mobility.
This article explains the Network Mobility Basic Support Protocol, by first providing a general overview and then examining the details.
Why Network Mobility?
Accelerated by the success of cellular technologies, mobility has changed the way people communicate. As Internet access becomes more and more ubiquitous, demands for mobility are not restricted to single terminals anymore. It is also needed to support the movement of a complete network that changes its point of attachment to the fixed infrastructure, maintaining the sessions of every device of the network: what is known as network mobility in IP networks. In this scenario, the mobile network has at least a (mobile) router that connects to the fixed infrastructure, and the devices of the mobile network connect to the exterior through this mobile router.
Support of the roaming of networks that move as a whole is required in order to enable the transparent provision of Internet access in mobile platforms, such as the following:
Public transportation systems: These systems would let passengers in trains, planes, ships, etc. access the Internet from terminals onboard (for example, laptops, cellular phones, Personal Digital Assistants [PDAs], and so on) through a mobile router located at the transport vehicle that connects to the fixed infrastructure.
Personal networks: Electronic devices carried by people, such as PDAs, photo cameras, etc. would connect through a cellular phone acting as the mobile router of the personal network.
Vehicular scenarios: Future cars will benefit from having Internet connectivity, not only to enhance safety (for example, by using sensors that could control multiple aspects of the vehicle operation, interacting with the environment and communicating with the Internet), but also to provide personal communication, entertainment, and Internet-based services to passengers.
However, IP networks were not designed for mobile environments. In both IPv4  and IPv6 [3, 4], IP addresses play two different roles. On the one hand, they are locators that specify, based on a routing system, how to reach the node that is using that address. The routing system keeps information about how to reach different sets of addresses that have a common network prefix. This address aggregation in the routing system satisfies scalability requirements. On the other hand, IP addresses are also part of the endpoint identifiers of a communication, and upper layers use the identifiers of the peers of a communication to identify them. For example, the Transmission Control Protocol (TCP), which is used to support most of the Internet applications, uses the IP address as part of the TCP connection identifier.
This dual role played by IP addresses imposes some restrictions on mobility, because when a terminal moves from one network (IP subnet) to another, we would like to maintain the IP address of the node that moves (associated to one of its network interfaces) in order not to change the identifier that upper layers are using in their ongoing sessions. However, we also would like to change the IP address to make it topologically correct in the new location of the terminal, allowing in this way the routing system to reach the terminal.
Protocols such as the Dynamic Host Configuration Protocol (DHCP) [5, 6] facilitated the portability of terminals by enabling the dynamic acquisition of IP configuration information without involving manual intervention. However, this automation is not enough to achieve real and transparent mobility because it requires the restarting of ongoing transport sessions after the point of attachment changes. The IETF has studied the problem of terminal mobility in IP networks for a long time, and IP-layer solutions exist for both IPv4 (Mobile IPv4 [7, 8]) and IPv6 (Mobile IPv6 ) that enable the movement of terminals without stopping their ongoing sessions.
If we focus on IPv6  networks, Mobile IPv6 does not support, as it is now defined, the movement of complete networks. One way of achieving the transparent mobility of all the nodes of a network moving together (for example, in a plane) could be enabling host mobility support in all of them, so they independently manage their mobility. However, this approach has the following drawbacks:
Host mobility support (for example Mobile IP [7, 8, 9]) is required in all the nodes of the network. This support might not be possible, for example, because of the limited capacities of the nodes (such as in sensors or embedded devices) or because it is not possible to update the software in some older devices. By having a single entity (the mobile router) that manages the mobility of the complete network, nodes of the network do not require any special mobility software to benefit from the transparent mobility support provided by the (mobile) router.
The signaling exchanged because of the roaming of the network is limited to a single node sending only one message (avoiding "storms" of signaling messages every time the network moves).
Nodes of the network must be able to attach to the access technology available to connect to the Internet. This requirement might mean that all the nodes of the network should have Universal Mobile Telecommunications Service (UMTS) or WiMAX interfaces, for example. On the other hand, by putting this requirement on a single node (the mobile router), nodes of the network can gain access to the Internet through the mobile router, using cheaper and widely available access technologies (for example, wireless LAN [WLAN] or Bluetooth).
Because of these problems, the IETF NEMO Working Group was created to standardize a solution enabling network mobility at the IPv6 layer. The current solution, called the Network Mobility Basic Support Protocol, is defined in RFC 3963 .
Operation of the NEMO Basic Support Protocol
A mobile network (known also as a "network that moves," or NEMO) is defined as a network whose attachment point to the Internet varies with time. Figure 1 depicts an example of a network-mobility scenario. The router within the NEMO that connects to the Internet is called the Mobile Router (MR). It is assumed that the NEMO is assigned to a particular network, known as its Home Network, where it resides when it is not moving. Because the NEMO is part of the home network, the mobile network has configured addresses belonging to one or more address blocks assigned to the home network: the Mobile Network Prefixes (MNPs). These addresses remain assigned to the NEMO when it is away from home. Of course, these addresses have topological meaning only when the NEMO is at home. When the NEMO is away from home, packets addressed to the nodes of the NEMO, known as Mobile Network Nodes (MNNs), are still routed to the home network. Additionally, when the NEMO is away from home, the mobile router acquires an address from the visited network, called the Care-of Address (CoA), where the routing architecture can deliver packets without additional mechanisms.
When any node located at the Internet, known as a Correspondent Node (CN), exchanges IP datagrams with a Mobile Network Node (MNN; A in Figure 1), the following operations are involved in the communication:
Figure 1: Example of NEMO Basic Support Protocol Operation
The correspondent node transmits an IP datagram destined for MNN A. This datagram carries as its destination address the IPv6 address of MNN A, which belongs to the MNP of the NEMO.
This IP datagram is routed to the home network of the NEMO, where it is encapsulated inside a new IP datagram by a special node located on the home network of the NEMO, called the Home Agent (HA). The new datagram is sent to the CoA of the mobile router, with the IP address of the home agent as source address. This encapsulation (as shown in Figure 2) preserves mobility transparency (that is, neither MNN A nor the correspondent node are aware of the mobility of the NEMO) while maintaining the established Internet connections of the MNN.
The mobile router receives the encapsulated IP datagram, removes the outer IPv6 header, and delivers the original datagram to MNN A.
In the opposite direction, the operation is analogous. The mobile router encapsulates the IP datagrams sent by MNN A toward its home agent, which then forwards the original datagram toward its destination (that is, the correspondent node). This encapsulation is required to avoid problems with ingress filtering, because many routers implement security policies that do not allow the forwarding of packets that have a source address that appears topologically incorrect.
Figure 2: Overview of NEMO Basic Support Protocol Encapsulation
Following are different types of MNNs:
Local Fixed Node (LFN): This node has no mobility-specific software and therefore cannot change its point of attachment while maintaining ongoing sessions. Its IPv6 address is taken from a MNP of the NEMO to which it is attached.
Local Mobile Node (LMN): This node implements the Mobile IPv6 protocol; its home network is located in the mobile network. Its home address (HoA) is taken from an MNP.
Visiting Mobile Node (VMN): This node implements the Mobile IP protocol (and therefore, it can change its point of attachment while maintaining ongoing sessions), has its home network outside the mobile network, and it is visiting the mobile network. A VMN that is temporarily attached to a mobile subnet (used as a foreign link) obtains an address on that subnet (that is, its CoA is taken from an MNP).
Additionally, mobile networks can be nested. A mobile network is said to be nested when it attaches to another mobile network and obtains connectivity through it (refer to Figure 3). An example is a user who enters a vehicle with his personal area network (mobile network 2) and connects, through a mobile router—like a Wi-Fi enabled PDA—to the network of the car (mobile network 1), which is connected to the fixed infrastructure.
Figure 3: Nested Mobile Network: Operation of the NEMO Basic Support Protocol (multiangular routing)
Protocol Details: NEMO Versus Mobile IPv6
The NEMO Basic Support Protocol is an extension of the solution proposed for host mobility support, Mobile IPv6 (MIPv6) .
In Mobile IPv6, three mechanisms support the mobility of a host: movement detection, location registration, and traffic tunneling. The NEMO Basic Support Protocol extends some of these mechanisms to support the movement of complete networks. These mechanisms are described next, with those parts that are different from the Mobile IPv6 protocol highlighted.
In Mobile IPv6, the host needs to discover its own movement, so it can proceed with the required signaling and operations that allow its transpaRouter Advertisements (RAs). Routers send these router-advertisement messages, both periodically and in response to a Router Solicitation message issued by a host. By looking at the information contained in the router advertisements, a host can determine whether or not it has moved to a new link.
The NEMO Basic Support Protocol does not introduce any change on the movement-detection mechanisms that a mobile router can use.
When a host moves to a new network, it has to configure a new IPv6 address on the visited link (belonging to the IPv6 address space of that visited network): the CoA, and inform the home agent of the movement. In Mobile IPv6, the mobile node (that is, a mobile host) informs its home agent of its current CoA using a mobility message called the Binding Update (BU). This message is carried in an IPv6 datagram using a special extension header defined by Mobile IPv6 to encapsulate all messaging related to the creation and management of mobility bindings, called the mobility header. The binding-update message contains information required by the home agent to create a mobility binding, such as the home address of the Mobile Node (MN) and its CoA, where the home agent should encapsulate all the traffic destined to the mobile node. The home agent replies to the mobile node by returning a Binding Acknowledgement (BA) message.
The NEMO Basic Support Protocol extends the binding-update message to convey the following additional information:
Mobile Router Flag (R): The mobile router flag is set to indicate to the home agent that the binding update is from a mobile router. A mobile router can behave as a mobile host: by setting this flag to 0, the home agent does not forward packets destined for the mobile network to the mobile router, but forwards only those packets destined to the home address of the mobile router.
Mobile Network Prefix Option: This option is in the binding update to indicate the prefix information for the mobile network to the home agent. There could be multiple mobile network prefix options if the mobile router has more than one IPv6 prefix in the mobile network and wants the home agent to forward packets for each of these prefixes to the current location of the mobile router.
When the NEMO Basic Support Protocol is used to provide mobility to a complete network, only one binding-update or binding-acknowledgement signaling messages exchange is performed, whereas if the Mobile IP protocol were used by all the nodes of an
N-node network, N + (Binding-update or Binding-acknowledgement) signaling messages synchronized exchanges would be required—usually referred to as a "binding-update signaling storm."
Mobile IPv6 defines a route-optimization mechanism that enables direct path communication between the mobile node and a correspondent node (avoiding traversal of the home agent). This route optimization is achieved by allowing the mobile node to send binding-upda-te messages also to the correspondent nodes. In this way the correspondent node is also aware of the CoA, where the home address of the mobile node is currently reachable. A special mechanism—called the Return Routability (RR) procedure—is defined to prove that the mobile node has been assigned (that is, "owns") both the home address and the CoA at a particular moment in time , and therefore provides the correspondent node with some security guarantees.
Because of the nature of the network-mobility scenario, the task of providing mobile networks with route-optimization support becomes more complex. The IETF is currently working on this topic [12, 13, 14].
In Mobile IPv6, after the mobile node has successfully registered its current location, the home agent starts encapsulating the data traffic destined to the mobile node toward its CoA.
In a NEMO scenario, the home agent forwards not only those IP datagrams arriving at the home network that are destined to the home address of the mobile router, but also all the traffic addressed to any of the mobile-network prefixes managed by the mobile router. The home agent can determine which prefixes belong to the mobile router in three different ways (refer to Figure 4):
Figure 4: NEMO Basic Support Modes of Operation
Explicit mode: The mobile router includes one or more mobile network prefix options in the binding-update message that it sends to the home agent. These options contain information about the mobile-network prefix(es) configured on the mobile network.
Implicit mode: The mobile router does not include prefix infor-mation in the binding-update message it sends to the home agent. The home agent determines the mobile-network prefix(es) owned by the mobile router by using any other mechanism (the NEMO Basic Support Protocol does not define any, leaving this prefix determination open to be implementation-specific).
One example would be manual configuration at the home agent mapping the home address of the mobile router to the information required for setting up forwarding for the mobile network.
Intradomain Dynamic Routing Protocol through the bidirectional tunnel: Alternatively to the previous two modes of operation, the home agent and the mobile router can run an intradomain routing protocol (for example, Routing Information Protocol next generation [RIPng] or Open Shortest Path First [OSPF]) through the bidirectional tunnel. The mobile router can continue running the same routing protocol that it ran when attached to the home link.
Fragmentation may be needed to forward packets through the tunnel between the mobile router and the home agent. In this case, the other end of the tunnel (the home agent of the mobile router) must reassemble the packet before forwarding it to the final destination. This requirement does not contradict the fact that intermediate IPv6 routers do not fragment (as opposed to IPv4), because the mobile router and home agent are the actual ends of the tunnel.
Performance of the NEMO Basic Support Protocol
The NEMO Basic Support Protocol relies on the creation of a bidirectional tunnel between the mobile router and the home agent to provide transparent mobility support to a complete network. The use of this tunnel causes an additional overhead of 40 bytes per packet, because of the extra IPv6 header added by the encapsulation. The effect of this overhead might be relevant for applications that generate small packets, such as voice-over-IP (VoIP) packets, because the 40-byte added overhead may be even bigger than the actual VoIP payload.
The end of the bidirectional tunnel at the side of the mobile router needs to be updated each time the mobile network moves (and also periodically to refresh the binding at the home agent), to reflect the current location of the mobile router. This updating is achieved by the binding-update or binding-acknowledgement signaling exchange between the mobile router and the home agent. As stated previously, only one exchange (two packets, one in each direction) is required per movement, regardless of the number of MNNs that are attached to the mobile router—one of the main advantages of using the NEMO Basic Support Protocol on the mobile router instead of Mobile IPv6 on every node of the mobile network, because the signaling generated by a complete moving network (composed of numerous nodes) is the same as the one generated by a single moving node.
The NEMO Basic Support Protocol  extends the functions of Mobile IPv6 to support the mobility of complete networks. The current specification supports basic mobility, and the IETF is currently working on new enhancements and extensions to provide route-optimization support, multihoming capabilities, and IPv4 support.
Some implementations of the NEMO Basic Support Protocol are already available. For example, the latest Cisco IOS® Software releases provide network mobility support. Open-source implementations also exist, such as the NEMO Platform for Linux (NEPL) (http://www.mobile-ipv6.org/) and SHISA (http://www.mobileip.jp/), for Linux and Berkeley Software Distribution (BSD) operating systems, respectively.
 Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and Pascal Thubert, "Network Mobility (NEMO) Basic Support Protocol," RFC 3963, January 2005.
 Jon Postel, "Internet Protocol," RFC 791, September 1981.
 Iljitsch van Beijnum, "IPv6 Internals," The Internet Protocol Journal, Volume 9, No. 3, September 2006.
 Stephen E. Deering and Robert M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998.
 Ralph Droms, "Dynamic Host Configuration Protocol," RFC 2131, March 1997.
 Ralph Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles E. Perkins, and Mike Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," RFC 3315, July 2003.
 William Stallings, "Mobile IP," The Internet Protocol Journal, Volume 4, No. 2, June 2001.
 Charles E. Perkins, "IP Mobility Support for IPv4," RFC 3344, August 2002.
 David B. Johnson, Charles E. Perkins, and Jari Arkko, "Mobility Support in IPv6," RFC 3775, June 2004.
 Thomas Narten, Erik Nordmark, and William A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998.
 Pekka Nikander, Jari Arkko, Tuomas Aura, Gabriel Montenegro, and Erik Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background," RFC 4225, December 2005.
 Chan-Wah Ng, Pascal Thubert, Masafumi Watari, and Fan Zhao, "Network Mobility Route Optimization Problem Statement," Internet Draft, Work in Progress, September 2006. draft-ietf-nemo-ro-problem-statement-03.txt
 Chan-Wah Ng, Fan Zhao, Masafumi Watari, and Pascal Thubert, "Network Mobility Route Optimization Solution Space Analysis," Internet Draft, Work in Progress, September 2006. draft-ietf-nemo-ro-space-analysis-03.txt
 María Calderón Carlos J. Bernardos, Marcelo Bagnulo, Ignacio Soto, and Antonio de la Oliva, "Design and Experimental Evaluation of a Route Optimisation Solution for NEMO," IEEE Journal on Selected Areas in Communications (J-SAC), Issue on Mobile Routers and Network Mobility, Volume 24, Number 9, pages 1702–1716, September 2006.
CARLOS J. BERNARDOS received a telecommunication engineering degree in 2003, and a Ph.D. in telematics in 2006, both from University Carlos III of Madrid. His Ph.D. thesis focused on Route Optimisation for Mobile Networks in IPv6 Heterogeneous Environments. He has been working as a research and teaching assistant in Telematics Engineering since 2003. His current work focuses on IP-based mobile communication protocols. E-mail: firstname.lastname@example.org
IGNACIO SOTO received a telecommunication engineering degree in 1993, and a Ph.D. in telecommunications in 2000, both from the University of Vigo, Spain. He was a research and teaching assistant in telematics engineering at the University of Valladolid from 1993 to 1999. In 1999 he joined University Carlos III of Madrid, where he has been an associate professor since 2001. His research activities focus on mobility support in packet networks and heterogeneous wireless access networks. E-mail: email@example.com
MARÍA CALDERÓN is an associate professor at the Telematics Engineering Department of University Carlos III of Madrid. She received a computer science engineering degree in 1991 and a Ph.D. degree in computer science in 1996, both from the Technical University of Madrid. She has published more than 20 papers in the fields of advanced communications, reliable multicast protocols, programmable networks, and IPv6 mobility. E-mail: firstname.lastname@example.org