Figure 1 IP traffic between a Mobile Network Node and a Correspondent Node using NEMO.
Paul Moceri paul.moceri@gmail.com
The growing use of IP devices in portable applications has created the demand for mobility support for entire networks of IP devices. Network Mobility (NEMO) solves this problem by extending Mobile IP. Devices on a mobile network are unaware of their network's mobility; however, they are provided with uninterrupted Internet access even when the network changes its attachment point to the Internet. The Internet Engineering Task Force (IETF) has already created a set of NEMO protocols to provide basic NEMO functionality on both IPv4 and IPv6 and continues to work with other projects to develop advanced performance and functionality enhancing features. The first set of NEMO implementations are available on several platforms including BSD variants, Linux, and Cisco Systems routing equipment.
Network Mobility, NEMO, Mobile IP, MIPv4, MIPv6, Mobile Networks, Mobility, Survey, Multihoming, Route Optimization
Today, using Mobile IP (MIP), it is possible to move a single IP device from point to point on the Internet without losing higher level connections. However, with the proliferation of IP and the desire to always remain connected to the Internet, we are seeing entire networks of IP devices moving together from one place to another. It is possible to enable mobility for all of these devices using standard Mobile IP; however, this would require all devices to be capable of Mobile IP and generate excess overhead as every device has to perform Mobile IP functions.
Another solution to the problem is Network Mobility (NEMO). NEMO works by moving the mobility functionality from Mobile IP mobile nodes to a mobile network's router. The router is able to change its attachment point to the Internet in a manner that is transparent to attached nodes. This survey paper will give an overview of NEMO including how it works, current and future NEMO standards, and an overview of implementations and products that support NEMO. Since NEMO draws heavily from Mobile IP, the author recommends that the reader is familiar with Mobile IP [RFC3344].
In the near future, airplanes, automobiles, and even people will carry entire networks of IP devices that connect to the Internet. However, as they move, these networks must change their point of attachment to the Internet due to availability of Internet connectivity. NEMO would enable devices on these networks to maintain unchanged (in the sense of unchanged IP address and network prefix) connections to other devices on the Internet.
Airplanes - Until recently, wireless devices have been prohibited on commercial airline flights due to the risk of interference with airplanes electrical systems. However, in June of 2005, the Federal Aviation Administration (FAA) gave permission to United Airlines to install Wi-Fi (802.11) wireless network equipment on some of its aircraft [Reuters05]. This new regulation will open the door for in-flight Internet service and invite NEMO as a solution to provide uninterrupted Internet connectivity to multiple passengers.
Automobiles - It is not difficult to image networked systems or even Internet enabled navigation, multimedia, or driving system on automobiles. NEMO has the potential to provide a single, shared Internet access point to these systems. In the case of critical driving systems, NEMO would be essential in order to maintain continuous connectivity and availability [Ernst02].
Personal Area Networks (PANs) - People are beginning to carry multiple Internet enabled devices such as cell phones, PDAs, laptop computes, and music players. Instead of each device connecting to the Internet separate, all of devices could connect the Internet through a PAN. Using NEMO, one device, such as a cell phone, would act as the mobile router providing continuous access to the rest of the devices.
Other applications and uses of mobile networks can be found in the Network Mobility Support Goals and Requirements Internet-Draft [Ernst05].
The following definitions are important for understanding the basics of Mobile IP and NEMO and will be used throughout this survey paper.
Access Router (AR) Router that provides Internet access to a Mobile Router.
Care-of Address (CoA) IP address of Mobile Router at its current Internet attachment point.
Correspondent Node (CN) An IP device that is communicating with Mobile Network Node via IP.
Foreign Agent (FA) An Access Router that is NEMO aware and provides mechanisms to aid the Mobile Router.
Home Agent (HA) Host on the Home Network that enables the Mobile Router to roam.
Home Network (HN) Network that a Mobile Router belongs to when it is not roaming. i.e. the network that is associated with the network link of the Home Agent.
Mobility Agent (MA) Any IP device, including Mobile Router and Home Agent, that perform mobility functions.
Mobile Network Node (MNN) Any IP device on a mobile network. Mobile Network Nodes may be fixed to the mobile network or visiting the mobile network as mobile nodes. MNNs do not need to be aware of the network's mobility.
Mobile Node (MN) An IP device capable of changing its attachment point to the Internet while maintain higher layer connectivity through mobility functionality.
Mobile Router (MR) A router capable of changing its point of attachment to the Internet without disrupting higher layer connections of attached devices.
For a more complete list of the agents and devices involved in network mobility refer to [Ernst06].
The easiest way to understand NEMO is to first understand Mobile IP. Mobile IP enables a device to change its attachment point to the Internet without loosing higher-layer functionality through the use of tunneling between a Mobile Node (MN) and its Home Agent (HA). When a MN is on a foreign network, it obtains a local address, called a Care-of Address (CoA). The MN then sends the CoA to its HA for binding. Once binding is complete, the HA intercepts and forwards packets that arrive for the MN to the MN via a tunnel to its CoA. Reverse traffic follows the same path through the tunnel to the HA for forwarding via standard routing on the Internet. As the MN moves to different foreign networks, it sends binding updates with its new CoA. Under Mobile IP, a MN may also utilize a Foreign Agent (FA). A MN can register with a FA at its current Internet attachment point. The FA will then assist the MN by performing tunneling functions on behalf of the MN.
NEMO is an extension of Mobile IP that enables an entire network to change its attachment point to the Internet. Under NEMO, a Mobile Router (MR) takes over the role of the MN in performing mobility functions. Node that are attached to a MR, Mobile Network Nodes (MNNs), are not aware of the network's mobility and do not perform any mobility functions. MRs also send binding updates to their HAs. However, binding updates from MRs also contain the mobile network's network prefix. HAs will bind an entire network prefix to the MR's CoA and forward all packets for that network to the MR.
Figure 1 demonstrates the path of packets using NEMO. IP packets from a correspondent node (CN) that are destined for a node on a mobile network (MN) are delivered via standard routing on the Internet to the HA of that MN. The HA tunnels the packets to the MR for delivery to the MNN. Reverse packets take the same path in the opposite direction; the MNN sends packets to the MR to be tunneled to the home agent and then sent out to the CN via standard routing on the Internet.
Figure 1 IP traffic between a Mobile Network Node and a Correspondent Node using NEMO.
The Internet Engineering Task Force (IETF) created the NEMO Working Group (WG) to work on the problem of network mobility. The NEMO WG is concerned with the development and standardization of protocols to support NEMO on IP. The work performed by the WG relies heavily on the ground work performed for Mobile IP (MIP). Using MIP as a base, NEMO can be implemented as an extension of MIP. To date, the WG has standardized the NEMO Basic Support Protocol for IPv6 and written several Internet-Drafts that address other NEMO problems including NEMO for IPv4.
The NEMO Basic Support Protocol has been standardized for IPv6 [RFC3963] and drafted for IPv4 [Leung06]. Although, IPv6 and IPv4 are significantly different, the basic design is the same. Both versions are designed as extensions to Mobile IP. Mobile IP already provides HA and Mobile Node functionality. NEMO add Mobile Routers and the ability to bind a network prefix to a HA to Mobile IP.
NEMO signaling is performed with extended MIP messages. Specifically, messages contain an additional router (R) flag to signal a Mobile Router instead of a Mobile Node. These messages are sent using the Mobility Extension Header in IPv6 and UDP control messaging in IPv4. The two major messages used by NEMO are Binding Updates (BUs) and Binding Acknowledgements. MRs use BUs to notify their HAs of a new CoA, thus new Internet attachment point. BUs contain the new CoA, the router flag, and an optional mobile network prefix which is used to update the networks prefix information. Upon receipt of a BU, HAs send a Binding Acknowledgement.
The NEMO Basic Support Protocol defines two operating modes for NEMO: implicit and explicit. In implicit mode, BUs do not contain a Mobile Network Prefix option. Instead, the HA must determine the MR's network prefix by means outside of the NEMO Basic Support Protocol. When in explicit mode, all BUs contain one or more Mobile Network Prefix options. The HA is then able to use the Network Prefix option to set bindings for the MR.
Lastly, the NEMO Basic Support Protocol specifies the routing of packets to and from the Mobile Network. Packets sent to a MNN from a CN are routed over the Internet using standard routing until they reach the HA. The HA intercepts packets and encapsulates them in a tunnel to the MR. The MR decapsulates packets and routes them to the MNN. Reverse traffic must be reverse tunneled to the HA before being routed to the CN. The Basic Support Protocol specifies bi-directional tunneling so that only MRs and HAs need to be aware of the network's mobility and also to prevent firewalls from dropping packets. Some firewalls will drop packets to prevent spoofing - when the source address of packets (the Home Address) does not match the network from which they are being sent.
IPv6 affords NEMO with many mechanisms that do not exist in IPv4. Thus, some of the tasks of NEMO are better suited for IPv6. Also, the differences between NEMO on IPv4 and IPv6 tend to closely parallel the differences between MIPv4 and MIPv6 because NEMO is merely an extension of Mobile IP. Table 1 summarizes the differences between NEMO on IPv4 versus IPv6.
Table 1 Differences between Network Mobility on IPv4 and IPv6.
| IPv4 | IPv6 | |
| IPSec | Optional | Required |
| Aware Agents | MR, HA, FA (optional) | MR, HA |
| Tunnels | Bi-directional MR-HA, Optional Double Tunnel FA-HA | Bi-directional MR-HA |
| Tunneling Mechanism | Encapsulation | Routing Header |
| Messaging | UDP Control Messages | Mobility Extension Header |
On IPv4, Mobile Routers must rely on Mobile IP Foreign Agents for tunneling packets to and from the Home Agent. This means that any access router that a Mobile Router uses to attach to the Internet must be MIPv4 compliant. However, with NEMO Basic Support on IPv6, only the Mobile Router and Home Agent need to be aware of the Mobile Router's mobility. In this case, tunneling is performed directly between the Home Agent and the Mobile Router without the need for a Foreign Agent.
Using IPv6 also affords NEMO with more efficient tunneling and more consistent security. Under IPv6, tunneling is performed by using the routing extension header. On the other hand, IPv4 tunnels IP packets through encapsulation, a process with a higher overhead. NEMO also utilizes IPSec for encryption and authentication of tunneled traffic. However, IPSec is an optional part of IPv4 implementation whereas IPv6 requires IPSec of all implementations.
Security and performance are critical aspects of NEMO. Mobile networks travel on foreign, and possibly untrusted, networks when away from home. Because MNNs are unaware of mobility, it is important that NEMO provides security while a network is away. Also, performance is important in accomplishing the goal of NEMO to provide seamless mobility to unaware IP devices. As part of performance, interoperability is also a concern for NEMO implementations.
By design, the NEMO Basic Support Protocol ( [RFC3963] and [Leung06]) provides MMNs with location privacy. Due to the use of tunneling, the current location of MNNs is not revealed to CNs. The Basic Support Protocol also requires several other security features. First, both the MR and HA must check that all tunneled packets contain a source address that matches the originating network. This ensures that MNNs do not use the tunnel to perform IP spoofing attack. Second, upon reception of a Binding Update, HAs must check that a MR is authorized to bind to a prefix before enabling forwarding to that prefix.
NEMO security is further enhanced through the use of IPSec. IPSec allows authentication of signaling messages as well as encryption of tunneled packets. In fact, because IPSec is a required component of IPv6, the NEMO Basic Support Protocol on IPv6 actually requires that signaling messages are authenticated using IPSec. NEMO on IPv4 does not make this strict requirement because IPSec is only an optional component of IPv4.
Some work has begun to anaylize the performance of various NEMO implementations. The most notable, yet expected, performance characteristic of NEMO implementations is a drop in throughput and an increase in round trip time when a router is acting as a MR. The performance loss is explained by the extra overhead due to encapsulation for tunneling. The current work only tests the basic functionality of NEMO and has yet to test more complex scenarios such as nested mobile networks. For full details of the study see [Kuntz06].
The TAHI Project [TAHI06], an organization created for IPv6 testing and certification, holds an annual event to test the interoperability of IPv6 implementations and devices. As part of the event, NEMO on IPv6 is also tested and has shown that the three aforementioned NEMO implementations, NEPL, SHISHA, and Cisco Mobile Networks, are interoperable and also conform to the standards set by IETF. These results were also verified by the study "Performance Evaluation of NEMO Basic Support Implementations [Kuntz06]."
The NEMO Working Group was established to find a basic solution to network mobility. Unfortunately, many of the performance enhancing features of Mobile IP do not work when using basic NEMO, and solutions to performance and advanced functionality problems were not required of the original NEMO charter. However, this does not mean that work has not been performed on these issues. The WG itself has made official statements and analyses of the problems at hand including route optimization to increase routing efficiency, multihoming to increase fault tolerance and capacity, and DHCPv6 Prefix Delegation to allow dynamic mobile network prefix assignment. Projects outside of the Working Group, such as Nautilus6, are also working on implementing these features in hopes of getting them incorporated into future standards.
Route optimization (RO) provides a mechanism to eliminate the inefficiency in tunneling packets from MRs to their HA before being sent to CNs over the Internet. RO would allow a way for MRs or MMNs to send packets directly to CNs. Figure 2 demonstrates this direct communication between MNN and CN via a tunnel. RO could decrease path delay and network load and avoid bottlenecks at HAs. However, the NEMO Basic Support Protocol does not address this issue and the NEMO Working Group is not currently chartered to define a standard for RO.
Figure 2 An example of Route Optimization. Mobile Network Nodes are able to send packets directly to Correspondent Nodes without tunneling to the Home Agent.
Mobile IP performs RO by utilizing a Binding Cache on the CN. Mobile IP nodes send Binding Updates with current CoAs to their CNs as they change attachment points to the Internet. Mobile nodes and CNs are then able to directly communicate using the CoA of the mobile node [RFC3344]. There are several possible approaches to the NEMO RO problem; however, each has its own trade-offs. Such trade-offs include increased signaling overhead, longer handover delay, and the need to make additional devices such as CNs and MMNs aware of NEMO.
For a full description of the RO problem see the NEMO Route Optimization Problem Statement [Ng05], and for possible approaches for RO see the NEMO Route Optimization Solution Space Analysis [Ng06].
Figure 3 Example of multihoming in NEMO. Mobile Router has multiple access links, thus multiple Care-of Addresses.
In a general sense, multihoming is a technique of increasing reliability and performance by providing redundant links. Under NEMO, multihoming takes the form of multiple HAs, MRs, access links, network prefixes, or combinations there of. Multihoming has the potential to provide loading balancing, fault tolerance and increased bandwidth. However, multihoming is a difficult problem to solve due to the many complex cases of multihoming. Figure 3 shows an example of a multihoming MR with multiple access interfaces, thus multiple CoAs. This MR could be using multihoming for redundancy as well as increased bandwidth. The NEMO Working Group analyzed these complexities in an Internet-Draft [Ng06b], but leaves the solution as work outside of the scope of the WG.
The NEMO Basic Support Protocol does not provide a mechanism to dynamically assign network prefixes to Mobile Networks. However, DHCPv6 Prefix Delegation (DHCPv6PD) would add this capability to NEMO. DHCPv6PD would be initiated by the MR at the time it first establishes a binding with a HA. The HA would act as either a DHCP delegating agent or a DHCP relay agent in order to service a DHCPv6PD request from an MR. The NEMO Working Group has suggested implementing DHCPv6DP as an extension of Dynamic Home Agent Address Discovery. Full details can be found in [Droms06].
DHCPv6PD is one of the features that is also being developed outside of the WG. The previously mentioned Nautilus6 NEPL project is working on prefix delegation and has incorporated the Internet-Draft version of DHCPv6PD into its enhanced version of NEPL [NEPLSE].
Although the NEMO WG and NEMO standards are relatively new, work has already begun on implementations of the NEMO Basic Support Protocol as well as additional NEMO features. Because NEMO is an extension of MIP, naturally implementations are able to build off of existing MIP implementations. Much work is being done to incorporate NEMO into Unix-like kernels as well as commercial products.
The Nautilus6 Working Group, a part of the Widely Integrated Distributed Environment (WIDE) Project, was created to improve mobility in IPv6 on the Linux and BSD platforms. Nautilus6 works towards this goal through the implementation of current IPv6 mobility standards as well as development and implementation of additional mobility features. One such feature that Nautilus6 is working on is NEMO IPv6 support for Linux and BSD. The SHISHA and NEMO Platform for Linux (NEPL) projects are current Nautilus6 implementations for BSD and Linux respectively [Nautilus605].
Before 2004, two separate implementations of Mobile IPv6 were being developed for BSD variants. These two implementations, the KAME Project and SFCMIP, were merged in 2004 to form SHISHA. Today, SHISHA implements Mobile IPv6 as well as the NEMO extensions for several BSD variants including FreeBSD, NetBSD, and OpenBSD. In addition to the Mobile IPv6 and NEMO Basic Support Protocol standards, SISHA has implemented Multiple Care-of Address Registration [SHISHA05].
NEMO Platform for Linux (NEPL) is an implementation of NEMO on Linux by the GO-Core project of the Helsinki University of Technology. NEPL adds NEMO extensions to the existing Mobile IPv6 for Linux (MIPL) implementation also from the GO-Core project. NEPL is working towards complete RFC 3963 compliance as well as additional functionality. Nautilus6 is currently working on Multiple Care-of Addresses and NEMO Prefix Delegation (described below) for NEPL [NIPL06].
As well as being implemented in the academic world, NEMO has made its way into commercial products. Cisco System has supported NEMO in its Cisco IOS Software since version 12.2 under the name Cisco Mobile Networks. IOS implements NEMO as an extension of Mobile IPv4 as defined in [RFC3344]; however, it also partially supports NEMO for IPv6 (RFC 3963) [Cisco05b].
Cisco Mobile Networks implements additional features that are not part of the NEMO Basic Support Protocol. First, Mobile Networks requires double tunneling of packets. An inner tunnel is used between the MR and HA and a second tunnel is used between the FA and HA. Cisco Mobile Networks also have a redundancy feature that is not part of the NEMO work IETF is performing. Using the proprietary Hot Standby Router Protocol (HSRP), Cisco Mobile Network are able to utilize fully redundant MRs [Cisco05a]. In the event that one of HSRP capable router fails, another HSRP router will automatically take over the function of the failed router.
Microsoft does not yet support NEMO in its Windows Operating Systems. However, the current versions of Windows (XP SP1, XP S2, and Server 2003) do support a limited set of Correspondent Node functionality for Mobile IP. And, Microsoft has developed a Mobile IPv6 Technology Preview which implements full MN, HA, and CN functionality for Mobile IP. However, this implementation is not yet publicly available. Microsoft will develop further Mobile IP, and perhaps NEMO support, as demand increases for such features in Windows Operating System [Davies05].
As more and more portable devices are being Internet enabled, the need for entire networks to be mobile is apparent. Current Mobile IP supports the ability for a single mobile device to change its point of attachment to the Internet without disrupting the transport and higher layers. Network Mobility (NEMO) is an extension to current Mobile IP that enables a router to act as a mobility agent on behalf of an entire network of IP devices.
NEMO works through the use of a Home Agent and Mobile Router. MRs bind themselves to a HA when away from their home networks. HAs then forward all packets destined to a mobile network to that network's MR through a tunnel. Reverse traffic is tunneled back to the HA for delivery to a Correspondent Node. IETF defined this protocol as the NEMO Basic Support Protocol in [RFC3962].
In addition to basic support, advanced features are also being developed and implemented for NEMO. Route Optimization aims to solve the routing inefficiency associated with tunneling between the HA and MR while Multihoming works to allow for redundancy and load balancing through the use of multiple mobility agents. Implementations such as those developed by the Nautilus6 Project (see [Nautilus605]) support the Basic Support Protocol as well as some advanced features while the Basic Support Protocol has made its way into commercial products such as Cisco System's IOS (see [Cisco05a]).
The following references are roughly arranged in order of usefulness and relevance to the above paper.
[RFC3963] Devarapalli, V., R. Wakikawa, A. Petrescu P. Thubert. "RFC 3963: Network Mobility (NEMO) Basic Support Protocol," IETF, NEMO Working Group, January, 2005. http://www.ietf.org/rfc/rfc3963.txt
Full definition of NEMO Basic Support Protocol for IPv6.
[Leung06] Leung, K., G. Dommety, V. Narayana, A. Petrescu. "IPv4 Network Mobility (NEMO) Basic Support Protocol," IETF, NEMO Working Group, February 24, 2006. http://ietf.org/internet-drafts/draft-ietf-nemo-v4-base-00.txt
Full definition of NEMO Basic Support Protocol for IPv4.
[RFC3344] C. Perkins, Ed. "RFC 3344: IP Mobility Support for IPv4," IETF, Network Working Group, August, 2002. http://www.ietf.org/rfc/rfc3344.txt
Full standard specification of Mobile IP for IPv4.
[Ernst05] Ernst, T. "Network Mobility Support Goals and Requirements," NEMO Working Group, Internet-Draft, October 24, 2005. http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-05.txt
A good overview of goals and requirements of NEMO.
[Ernst06] Ernst, T., H-Y. Lach. "Network Mobility Support Terminology," NEMO Working Group, March 6, 2006. http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-05.txt
A good reference for NEMO related definitions.
[Ng06] Ng, C., F. Zhao, M. Watari, P. Thubert. "Network Mobility Route Optimization Solution Space Analysis," IEFT, NEMO Working Group, February 10, 2006. http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt
A good analysis and explanation of the route optimization problem.
[Ng05] Ng, C., F. Zhao, M. Watari, P. Thubert. "Network Mobility Route Optimization Problem Statement," IETF, NEMO Working Group, December 28, 2005. http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-02.txt
A good explanation of the route optimization problem.
[Ng06b] Ng, C., E. Paik, T. Ernst, M. Bagnulo. "Analysis of Multihoming in Network Mobility Support," IETF, NEMO Working Group, February 23, 2006. http://ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-05.txt
A good analysis and explanation of multihoming in NEMO.
[Nautilus605] "Nautilus6 - Network Mobility Website," 2005. Nautilus6, WIDE, April, 2006. http://www.nautilus6.org/nemo/index.php
A good example of a project working to implement NEMO.
[NEPLSE] "Nautilus6 - NEPL Enhancement Website," November 11, 2005. Nautilus6, WIDE, April, 2006. http://software.nautilus6.org/NEPL/
An implementation of NEMO for Linux
[SHISHA05] "SHISHA," Dec 1, 2005, WIDE Project, April 9, 2006. http://www.mobileip.jp/
An implementation of NEMO for BSD variants.
[Ernst02] Ernst, T., K. Uehara. "Connecting Automobiles to the Internet," Proceedings 3rd International Workshop on ITS Telecommunications (ITST), November 2002. http://www.sfc.wide.ad.jp/~kei/papers/itst2002-ernst.pdf
A good paper that outlines the use of NEMO in automobiles.
[MIPL06] "Mobile IPv6 for Linux Website," March 13, 2006, Helsinki University of Technology, April 9, 2006. http://www.mobile-ipv6.org/
A resource for Mobile IPv6.
[Cisco05a] "Mobile Networks Documentation," Cisco Systems, February 17, 2005. http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t4/ftmbrout.pdf/
Support documentation for NEMO in Cisco System's products.
[Kuntz06] Kuntz, R., K. Mitsuya, R. Wakikawa. "Performance Evaluation of NEMO Basic Support Implementations." WONEMO Workshop, Sendai, Japan, January 2006. http://www.nautilus6.org/doc/paper/20060119-WONEMO-NEMO-KuntzR.pdf
A comparison of current NEMO implementations.
[TAHI06] "TAHI Project Website," TAHI Project, April 7, 2006.http://www.microsoft.com/technet/community/columns/cableguy/cg0904.mspx
[Davies05] Davies, J. "The Cable Guy." "Introduction to Mobile IPv6 - The Cable Guy," September 1, 2004. updated Noverber 11, 2005. http://www.tahi.org/
Resource for information on compatibility testing of IPv6 and NEMO implementations.
[Droms06] Droms, R., P. Thubert. "DHCPv6 Prefix Delegation for NEMO," IEFT, NEMO Working Group, February 27, 2006 http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-01.txt
Definition of DHCPv6 problem and a solution to the problem.
[Cisco05b] "Standards Supported in Cisco IOS Software Releases 12.4 and 12.2S," Cisco Systems, July, 2005. http://www.cisco.com/application/pdf/en/us/guest/products/ps6392/c1037/cdccont_0900aecd802eaa4f.pdf/
Cisco documentation that describes IETF RFCs support by Cisco's IOS software.
[Reuters05] "United to offer Web in the air," Reuters, CNNMoney.com, June 6, 2005. http://money.cnn.com/2005/06/06/technology/personaltech/united_wifi/
A example of a potential use for NEMO.
| BSD | Berkeley Software Distribution |
| BU | Binding Update |
| CN | Correspondent Node |
| CoA | Care-of Address |
| DHCP | Dynamic Host Configuration Protocol |
| DHCPv6PD | Dynamic Host Configuration Protocol version 6 Prefix Delegation |
| FA | Foreign Agent |
| FAA | Federal Aviation Administration |
| HA | Home Agent |
| HN | Home Network |
| HSRP | Hot Standby Router Protocol |
| IP | Internet Protocol |
| IPSec | Internet Protocol Security |
| IPv4 | Internet Protocol Version 4 |
| IPv6 | Internet Protocol Version 6 |
| IETF | Internet Engineering Task Force |
| MIP | Mobile IP |
| MIPL | Mobile IP for Linux |
| MNN | Mobile Network Node |
| MN | Mobile Node |
| MR | Mobile Router |
| NEMO | Network Mobility |
| NEPL | NEMO Platform for Linux |
| PAN | Personal Area Network |
| RO | Route Optimization |
| SCFMIP | Shonan Fujisawa Campus Mobile IP |
| WG | Working Group |
| WIDE | Widely Integrated Distributed Environment |
| Wi-Fi | 802.11 Wireless Networking |
Last Modified: April, 2006
This paper is available at: http://www.cse.wustl.edu/~jain/index.html