<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<!--
     ASCII to XML transformation by Invisible Worlds, Inc.
     http://invisible.net/
     Last transformation: 03-Feb-1999, 02:07:55

     Cannonical version of this document is at:
     http://info.internet.isi.edu/in-notes/rfc/files/rfc2005.txt

     Implementors should verify all content with
     cannonical version.  Failure to do so may result in
     protocol failures.
-->

<rfc number="2005"
     category="std">
<front>
<title abbrev="Mobile IP Applicability Statement">Applicability Statement for IP Mobility Support</title>
<author initials="J." surname="Solomon" fullname="Jim Solomon">
<organization>Motorola Inc.</organization>
<address>
<postal>
<street>1301 E. Algonquin Rd. - Rm 2240</street>
<street>Schaumburg</street>
<street>IL  60196</street>
</postal>
<facsimile>+1-847-576-3240</facsimile>
<email>solomon@comm.mot.com</email>
</address>
</author>
<date month="October" year="1996"/>
<area>Internet</area>
<keyword>mobile ip</keyword>
<keyword>routing</keyword>
<keyword>wireless</keyword>
<abstract>
<t>
   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.
</t>
</abstract>
</front>
<middle>
<!-- RFC original section: (1.) -->
<section title="Protocol Overview">
<t>
   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 <xref target="_XREF_MIP.PROTO"/>.
</t>
<t>
   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&apos;s (permanent)
   home address.  At the home network, the mobile node&apos;s home agent
   intercepts such packets and tunnels them to the mobile node&apos;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.
</t>
<t>
   Thus, Mobile IP relies on protocol tunneling to deliver packets to
   mobile nodes that are away from their home network.  The mobile
   node&apos;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&apos;s care-of address
   -- a topologically significant address -- to which standard IP
   routing mechanisms can deliver packets.
</t>
<t>
   The Mobile IP protocol defines the following:
<list>
<t>
   - an authenticated registration procedure by which a mobile node
     informs its home agent(s) of its care-of address(es);
</t>
<t>
   - an extension to ICMP Router Discovery <xref target="_XREF_RFC1256"/> which allows mobile
     nodes to discover prospective home agents and foreign agents; and
</t>
<t>
   - the rules for routing packets to and from mobile nodes, including
     the specification of one mandatory tunneling mechanism (<xref target="_XREF_MIP.IPinIP"/>)
     and several optional tunneling mechanisms (<xref target="_XREF_MIP.MINENC"/> and
     <xref target="_XREF_RFC1701"/>).
</t></list>
</t>
</section>
<!-- RFC original section: (2.) -->
<section title="Applicability">
<t>
   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.
</t>
<t>
   One can think of Mobile IP as solving the &quot;macro&quot; mobility management
   problem.  It is less well suited for more &quot;micro&quot; 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.
</t>
<t>
   Mobile IP scales to handle a large number of mobile nodes in the
   Internet.  Without route optimization as described in <xref target="_XREF_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.
</t>
<t>
   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.
</t>
</section>
<!-- RFC original section: (3.) -->
<section title="Security">
<t>
   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.
</t>
<t>
   Due to the unavailability of an Internet key management protocol,
   agent discovery messages are not required to be authenticated.
</t>
<t>
   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.
</t>
<t>
   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.
</t>
</section>
<!-- RFC original section: (4.) -->
<section title="MIB">
<t>
   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.
</t>
</section>
<!-- RFC original section: (5.) -->
<section title="Implementations">
<t>
   Several implementations of Mobile IP are known to exist.  The
   following list gives the origin and a contact for several such
   implementations:
</t>
<figure><artwork>
      Organization:   Contact:

      CMU             Dave Johnson &lt;dbj@cs.cmu.edu&gt;
      FTP Software    Frank Kastenholz &lt;kasten@ftp.com&gt;
      IBM             Charlie Perkins &lt;perk@watson.ibm.com&gt;
      Motorola        Jim Solomon &lt;solomon@comm.mot.com&gt;
      Nokia           Gunyho Gabor &lt;gunyho@ncsmsg07he.ntc.nokia.com&gt;
      SUN             Gabriel Montenegro &lt;gab@cali.Eng.Sun.COM&gt;
      Telxon          Frank Ciotti &lt;frankc@teleng.eng.telxon.com&gt;
</artwork></figure>
</section>
<!-- RFC original section: (6.) -->
<section title="Implementation Experience">
<t>
   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:
<list>
<t>
   1)  Mobile Nodes receiving and processing Agent Advertisements.
</t>
<t>
   2)  Agents receiving Agent Solicitations and responding with Agent
       Advertisements.
</t>
<t>
   3)  Mobile Nodes registering with foreign agents on foreign networks.
</t>
<t>
   4)  Packets being received by the mobile node after having been
       tunneled by the home agent and de-tunneled by the foreign agent.
</t>
<t>
   5)  Packets from the mobile node being routed directly to their
       destinations.
</t>
<t>
   6)  Mobile nodes discovering that their connectivity/subnet had
       changed and re-registering at their new location.
</t>
<t>
   7)  Mobile nodes discovering that their current foreign agent had
       rebooted and therefore re-registering with that foreign agent.
</t>
<t>
   8)  The required form of tunneling (IP-in-IP encapsulation
       <xref target="_XREF_MIP.IPinIP"/>) as well as the one of the optional forms of tunneling;
       namely, Minimal Encapsulation <xref target="_XREF_MIP.MINENC"/>.
</t>
<t>
   9)  Mobile nodes de-registering upon returning to their home network.
</t>
<t>
   10) Registrations being rejected for authentication failures,
       including invalid authenticators as well as mismatched
       identification values (replay protection).
</t>
<t>
   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.
</t></list>
</t>
<t>
   Interoperability of at least two independent implementations was
   demonstrated for all of the features listed above.
</t>
</section>
<!-- RFC original section: (7.) -->
<section title="Summary">
<t>
   The co-chairs, on behalf of the working group participants, believe
   that the Mobile IP working group has satisfied the requirements set
   forth in <xref target="_XREF_RFC1264"/> 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.
</t>
</section>
<!-- RFC original section: (8.) -->
<section title="References (BOILERPLATE)">
<t>
This RFC contained boilerplate in this section which has been moved
to the RFC2223-compliant unnumbered section &quot;References.&quot;
</t>
</section>
<!-- RFC original section: (9.) -->
<section title="Author&apos;s Address (BOILERPLATE)">
<t>
This RFC contained boilerplate in this section which has been moved
to the RFC2223-compliant unnumbered section &quot;Author&apos;s Address.&quot;
</t>
</section>
</middle>
<back>
<!-- BEGIN INCLUDE REFERENCES ** DO NOT REMOVE -->
<references>
<reference anchor="_XREF_RFC1256">
<front>
<title>ICMP Router Discovery Messages</title>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<date month="September" year="1991"/>
</front>
<seriesInfo>RFC 1256</seriesInfo>
</reference>
<reference anchor="_XREF_RFC1701">
<front>
<title abbrev="Hanks">Hanks, S., Generic Routing Encapsulation (GRE)</title>
<author>
<organization/>
</author>
<date month="October" year="1994"/>
</front>
<seriesInfo>RFC 1701</seriesInfo>
</reference>
<reference anchor="_XREF_RFC1264">
<front>
<title abbrev="Internet Routing Protocol Standardization">Internet Routing Protocol Standardization Criteria</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization/>
</author>
<date month="October" year="1991"/>
</front>
<seriesInfo>RFC 1264</seriesInfo>
</reference>
<reference anchor="_XREF_MIP.IPinIP">
<front>
<title>IP Encapsulation within IP</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<date month="October" year="1996"/>
</front>
<seriesInfo>RFC 2003</seriesInfo>
</reference>
<reference anchor="_XREF_MIP.OPTIM">
<front>
<title abbrev="Route Optimization in Mobile IP">Route Optimization in Mobile IP,  Work in Progress</title>
<author initials="D." surname="Johnson" fullname="D. Johnson">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="_XREF_MIP.PROTO">
<front>
<title>IP Mobility Support</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<date month="October" year="1996"/>
</front>
<seriesInfo>RFC 2002</seriesInfo>
</reference>
<reference anchor="_XREF_MIP.MINENC">
<front>
<title>Minimal Encapsulation within IP</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<date month="October" year="1994"/>
</front>
<seriesInfo>RFC 2004</seriesInfo>
</reference>
</references>
<!-- END INCLUDE REFERENCES ** DO NOT REMOVE -->
</back>
</rfc>
