The RFC Archive
 The RFC Archive   RFC 2005   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 2005

Applicability Statement for IP Mobility Support

Last modified on Saturday, October 19th, 1996

Permanent link to RFC 2005
Search GitHub Wiki for RFC 2005
Show other RFCs mentioning RFC 2005







Network Working Group                                         J. Solomon
Request for Comments: 2005                                      Motorola
Category: Standards Track                                 October 1996


            Applicability Statement for IP Mobility Support

 Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

 Abstract

   As required by [RFC 1264], this report discusses the applicability of
   Mobile IP to provide host mobility in the Internet.  In particular,
   this document describes the key features of Mobile IP and shows how
   the requirements for advancement to Proposed Standard RFC have been
   satisfied.

1. Protocol Overview

   Mobile IP provides an efficient, scalable mechanism for node mobility
   within the Internet.  Using Mobile IP, nodes may change their point-
   of-attachment to the Internet without changing their IP address.
   This allows them to maintain transport and higher-layer connections
   while moving.  Node mobility is realized without the need to
   propagate host-specific routes throughout the Internet routing
   fabric.  The protocol is documented in [MIP-PROTO].

   In brief, Mobile IP routing works as follows.  Packets destined to a
   mobile node are routed first to its home network -- a network
   identified by the network prefix of the mobile node's (permanent)
   home address.  At the home network, the mobile node's home agent
   intercepts such packets and tunnels them to the mobile node's most
   recently reported care-of address.  At the endpoint of the tunnel,
   the inner packets are decapsulated and delivered to the mobile node.
   In the reverse direction, packets sourced by mobile nodes are routed
   to their destination using standard IP routing mechanisms.

   Thus, Mobile IP relies on protocol tunneling to deliver packets to
   mobile nodes that are away from their home network.  The mobile
   node's home address is hidden from routers along the path from the
   home agent to the mobile node due to the presence of the tunnel.  The
   encapsulating packet is destined to the mobile node's care-of address



Solomon                     Standards Track                  PAGE 1 top


RFC 2005 Mobile IP Applicability Statement October 1996 -- a topologically significant address -- to which standard IP routing mechanisms can deliver packets. The Mobile IP protocol defines the following: - an authenticated registration procedure by which a mobile node informs its home agent(s) of its care-of address(es); - an extension to ICMP Router Discovery [RFC 1256] which allows mobile nodes to discover prospective home agents and foreign agents; and - the rules for routing packets to and from mobile nodes, including the specification of one mandatory tunneling mechanism ([MIP-IPinIP]) and several optional tunneling mechanisms ([MIP-MINENC] and [RFC 1701]). 2. Applicability Mobile IP is intended to solve node mobility across changes in IP subnet. It is just as suitable for mobility across homogeneous media as it is for mobility across heterogeneous media. That is, Mobile IP facilitates node movement from one Ethernet segment to another as well as it accommodates node movement from an Ethernet segment to a wireless LAN. One can think of Mobile IP as solving the "macro" mobility management problem. It is less well suited for more "micro" mobility management applications -- for example, handoff amongst wireless transceivers, each of which covers only a very small geographic area. In this later situation, link-layer mechanisms for link maintenance (i.e. link-layer handoff) might offer faster convergence and less overhead than Mobile IP. Mobile IP scales to handle a large number of mobile nodes in the Internet. Without route optimization as described in [MIP-OPTIM], however, the home agent is a potential load point when serving many mobile nodes. When home agents become overburdened, additional home agents can be added -- and even dynamically discovered by mobile nodes -- using mechanisms defined in the Mobile IP documents. Finally, it is noted that mobile nodes are assigned (home) IP addresses largely the same way in which stationary hosts are assigned long-term IP addresses; namely, by the authority who owns them. Properly applied, Mobile IP allows mobile nodes to communicate using only their home address regardless of their current location. Mobile IP, therefore, makes no attempt to solve the problems related to local or global, IP address, renumbering. Solomon Standards Track PAGE 2 top

RFC 2005 Mobile IP Applicability Statement October 1996 3. Security Mobile IP mandates the use of cryptographically strong authentication for all registration messages exchanged between a mobile node and its home agent. Optionally, strong authentication can be used between foreign agents and mobile nodes or home agents. Replay protection is realized via one of two possible mechanisms -- timestamps or nonces. Due to the unavailability of an Internet key management protocol, agent discovery messages are not required to be authenticated. All Mobile IP implementations are required to support, at a minimum, keyed MD5 authentication with manual key distribution. Other authentication and key distribution algorithms may be supported. Mobile IP defines security mechanisms only for the registration protocol. Implementations requiring privacy and/or authentication of data packets sent to and from a mobile node should use the IP security protocols described in RFCs 1827 and 1826 for this purpose. 4. MIB At the time of publication of this Applicability Statement, a Management Information Base (MIB) for Mobile IP has been written and documented in RFC 2006. 5. Implementations Several implementations of Mobile IP are known to exist. The following list gives the origin and a contact for several such implementations: Organization: Contact: CMU Dave Johnson <dbj@cs.cmu.edu> FTP Software Frank Kastenholz <kasten@ftp.com> IBM Charlie Perkins <perk@watson.ibm.com> Motorola Jim Solomon <solomon@comm.mot.com> Nokia Gunyho Gabor <gunyho@ncsmsg07he.ntc.nokia.com> SUN Gabriel Montenegro <gab@cali.Eng.Sun.COM> Telxon Frank Ciotti <frankc@teleng.eng.telxon.com> 6. Implementation Experience FTP Software hosted an interim meeting, October 23-27, 1995 in which interoperability of several implementations was demonstrated. The following major features of the Mobile IP protocol were tested: Solomon Standards Track PAGE 3 top

RFC 2005 Mobile IP Applicability Statement October 1996 1) Mobile Nodes receiving and processing Agent Advertisements. 2) Agents receiving Agent Solicitations and responding with Agent Advertisements. 3) Mobile Nodes registering with foreign agents on foreign networks. 4) Packets being received by the mobile node after having been tunneled by the home agent and de-tunneled by the foreign agent. 5) Packets from the mobile node being routed directly to their destinations. 6) Mobile nodes discovering that their connectivity/subnet had changed and re-registering at their new location. 7) Mobile nodes discovering that their current foreign agent had rebooted and therefore re-registering with that foreign agent. 8) The required form of tunneling (IP-in-IP encapsulation [MIP-IPinIP]) as well as the one of the optional forms of tunneling; namely, Minimal Encapsulation [MIP-MINENC]. 9) Mobile nodes de-registering upon returning to their home network. 10) Registrations being rejected for authentication failures, including invalid authenticators as well as mismatched identification values (replay protection). 11) TCP connections remaining open (with data flowing) while a mobile node moved from its home network to a foreign network and then back again to the home network. Interoperability of at least two independent implementations was demonstrated for all of the features listed above. 7. Summary The co-chairs, on behalf of the working group participants, believe that the Mobile IP working group has satisfied the requirements set forth in [RFC 1264] for the advancement of Mobile IP to Proposed Standard RFC. Specifically, the technical specification document is stable, a MIB has been written, the security architecture has been set forth in accordance with IAB principles, and several independent implementations have been demonstrated to be interoperable. 8. References [RFC 1256] Deering, S., Editor, "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC 1701] Hanks, S. et. al., "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC 1264] Hinden, R., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991. Solomon Standards Track PAGE 4 top

RFC 2005 Mobile IP Applicability Statement October 1996 [MIP-IPinIP] Perkins, C., Editor, "IP Encapsulation within IP", RFC 2003, October 1996. [MIP-OPTIM] Johnson, D., and C. Perkins, "Route Optimization in Mobile IP", Work in Progress. [MIP-PROTO] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1996. [MIP-MINENC] Perkins, C., Editor, "Minimal Encapsulation within IP", RFC 2004, October 1994. 9. Author's Address Questions about this memo can be directed to: Jim Solomon Motorola Inc. 1301 E. Algonquin Rd. - Rm 2240 Schaumburg, IL 60196 Voice: +1-847-576-2753 Fax: +1-847-576-3240 EMail: solomon@comm.mot.com Solomon Standards Track PAGE 5 top

Applicability Statement for IP Mobility Support RFC TOTAL SIZE: 10509 bytes PUBLICATION DATE: Saturday, October 19th, 1996 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 2005: The IETF Trust, Saturday, October 19th, 1996
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement