tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5944

 
 
 

IP Mobility Support for IPv4, Revised

Part 4 of 4, p. 77 to 100
Prev RFC Part

 


prevText      Top      Up      ToC       Page 77 
5.  Security Considerations

   The mobile computing environment is potentially very different from
   the ordinary computing environment.  In many cases, mobile computers
   will be connected to the network via wireless links.  Such links are
   particularly vulnerable to passive eavesdropping, active replay
   attacks, and other active attacks.

5.1.  Message Authentication Codes

   Home agents and mobile nodes MUST be able to perform authentication.
   The default algorithm is HMAC-MD5 [10], with a key size of 128 bits.
   The foreign agent MUST also support authentication using HMAC-MD5 and
   key sizes of 128 bits or greater, with manual key distribution.  Keys
   with arbitrary binary values MUST be supported.

   The "prefix+suffix" use of MD5 to protect data and a shared secret is
   considered vulnerable to attack by the cryptographic community.
   Where backward compatibility with existing Mobile IP implementations

Top      Up      ToC       Page 78 
   that use this mode is needed, new implementations SHOULD include
   keyed MD5 [19] as one of the additional authentication algorithms for
   use when producing and verifying the authentication data that is
   supplied with Mobile IP registration messages, for instance, in the
   extensions specified in Sections 3.5.2, 3.5.3, and 3.5.4.

   More authentication algorithms, algorithm modes, key distribution
   methods, and key sizes MAY also be supported for all of these
   extensions.

5.2.  Areas of Security Concern in This Protocol

   The registration protocol described in this document will result in a
   mobile node's traffic being tunneled to its care-of address.  This
   tunneling feature could be a significant vulnerability if the
   registration were not authenticated.  Such remote redirection, for
   instance, as performed by the mobile registration protocol, is widely
   understood to be a security problem in the current Internet if not
   authenticated [30].  Moreover, the Address Resolution Protocol (ARP)
   is not authenticated, and can potentially be used to steal another
   host's traffic.  The use of gratuitous ARP (Section 4.6) brings with
   it all of the risks associated with the use of ARP.

5.3.  Key Management

   This specification requires a strong authentication mechanism (keyed
   MD5) that precludes many potential attacks based on the Mobile IP
   registration protocol.  However, because key distribution is
   difficult in the absence of a network key management protocol,
   messages with the foreign agent are not all required to be
   authenticated.  In a commercial environment it might be important to
   authenticate all messages between the foreign agent and the home
   agent, so that billing is possible and service providers do not
   provide service to users that are not legitimate customers of that
   service provider.

5.4.  Picking Good Random Numbers

   The strength of any authentication mechanism depends on several
   factors, including the innate strength of the authentication
   algorithm, the secrecy of the key used, the strength of the key used,
   and the quality of the particular implementation.  This specification
   requires implementation of keyed MD5 for authentication, but does not
   preclude the use of other authentication algorithms and modes.  For
   keyed MD5 authentication to be useful, the 128-bit key must be both
   secret (that is, known only to authorized parties) and pseudo-random.

Top      Up      ToC       Page 79 
   If nonces are used in connection with replay protection, they must
   also be selected carefully.  RFC 4086 [8] written by Eastlake, et al.
   provides more information on generating pseudo-random numbers.

5.5.  Privacy

   Users who have sensitive data that they do not wish others to see
   should use mechanisms outside the scope of this document (such as
   encryption) to provide appropriate protection.  Users concerned about
   traffic analysis should consider appropriate use of link encryption.
   If absolute location privacy is desired, the mobile node can create a
   tunnel to its home agent.  Then, datagrams destined for correspondent
   nodes will appear to emanate from the home network, and it may be
   more difficult to pinpoint the location of the mobile node.  Such
   mechanisms are all beyond the scope of this document.

5.6.  Ingress Filtering

   Many routers implement security policies such as "ingress filtering"
   [35] that do not allow forwarding of packets that have a Source
   Address that appears topologically incorrect.  In environments where
   this is a problem, mobile nodes may use reverse tunneling [12] with
   the foreign agent supplied care-of address as the Source Address.
   Reverse-tunneled packets will be able to pass normally through such
   routers, while ingress filtering rules will still be able to locate
   the true topological source of the packet in the same way as packets
   from non-mobile nodes.

5.7.  Replay Protection for Registration Requests

   The Identification field is used to let the home agent verify that a
   registration message has been freshly generated by the mobile node,
   not replayed by an attacker from some previous registration.  Two
   methods are described in this section: timestamps (mandatory) and
   "nonces" (optional).  All mobile nodes and home agents MUST implement
   timestamp-based replay protection.  These nodes MAY also implement
   nonce-based replay protection.

   The style of replay protection in effect between a mobile node and
   its home agent is part of the Mobility Security Association.  A
   mobile node and its home agent MUST agree on which method of replay
   protection will be used.  The interpretation of the Identification
   field depends on the method of replay protection as described in the
   subsequent subsections.

   Whatever method is used, the low-order 32 bits of the Identification
   field MUST be copied unchanged from the Registration Request to the
   Reply.  The foreign agent uses those bits (and the mobile node's home

Top      Up      ToC       Page 80 
   address) to match Registration Requests with corresponding replies.
   The mobile node MUST verify that the low-order 32 bits of any
   Registration Reply are identical to the bits it sent in the
   Registration Request.

   The Identification field in a new Registration Request MUST NOT be
   the same as in an immediately preceding Request, and SHOULD NOT
   repeat while the same security context is being used between the
   mobile node and the home agent.  Retransmission as in Section 3.6.3
   is allowed.

5.7.1.  Replay Protection Using Timestamps

   The basic principle of timestamp replay protection is that the node
   generating a message inserts the current time of day, and the node
   receiving the message checks that this timestamp is sufficiently
   close to its own time of day.  Unless specified differently in the
   security association between the nodes, a default value of 7 seconds
   MAY be used to limit the time difference.  This value SHOULD be
   greater than 3 seconds.  Obviously the two nodes must have adequately
   synchronized time-of-day clocks.  As with any messages, time
   synchronization messages may be protected against tampering by an
   authentication mechanism determined by the security context between
   the two nodes.

   If timestamps are used, the mobile node MUST set the Identification
   field to a 64-bit value formatted as specified by the Network Time
   Protocol [11].  The low-order 32 bits of the NTP format represent
   fractional seconds, and those bits that are not available from a time
   source SHOULD be generated from a good source of randomness.  Note,
   however, that when using timestamps, the 64-bit Identification used
   in a Registration Request from the mobile node MUST be greater than
   that used in any previous Registration Request, as the home agent
   uses this value as a sequence number.  Without such a sequence
   number, it would be possible for a delayed duplicate of an earlier
   Registration Request to arrive at the home agent (within the clock
   synchronization required by the home agent), and thus be applied out
   of order, mistakenly altering the mobile node's current registered
   care-of address.

   Upon receipt of a Registration Request with an authorization-enabling
   extension, the home agent MUST check the Identification field for
   validity.  In order to be valid, the timestamp contained in the
   Identification field MUST be close enough to the home agent's time-
   of-day clock, and the timestamp MUST be greater than all previously
   accepted timestamps for the requesting mobile node.  Time tolerances
   and resynchronization details are specific to a particular Mobility
   Security Association.

Top      Up      ToC       Page 81 
   If the timestamp is valid, the home agent copies the entire
   Identification field into the Registration Reply it returns to the
   mobile node.  If the timestamp is not valid, the home agent copies
   only the low-order 32 bits into the Registration Reply, and supplies
   the high-order 32 bits from its own time of day.  In this latter
   case, the home agent MUST reject the registration by returning Code
   133 (registration Identification mismatch) in the Registration Reply.

   As described in Section 3.6.2.1, the mobile node MUST verify that the
   low-order 32 bits of the Identification field in the Registration
   Reply are identical to those in the rejected registration attempt,
   before using the high-order bits for clock resynchronization.

5.7.2.  Replay Protection Using Nonces

   The basic principle of nonce replay protection is that node A
   includes a new random number in every message to node B, and checks
   that node B returns that same number in its next message to node A.
   Both messages use an authentication code to protect against
   alteration by an attacker.  At the same time, node B can send its own
   nonces in all messages to node A (to be echoed by node A), so that it
   too can verify that it is receiving fresh messages.

   The home agent may be expected to have resources for computing
   pseudo-random numbers useful as nonces [8].  It inserts a new nonce
   as the high-order 32 bits of the Identification field of every
   Registration Reply.  The home agent copies the low-order 32 bits of
   the Identification field from the Registration Request message into
   the low-order 32 bits of the Identification field in the Registration
   Reply.  When the mobile node receives an authenticated Registration
   Reply from the home agent, it saves the high-order 32 bits of the
   Identification field for use as the high-order 32 bits of its next
   Registration Request.

   The mobile node is responsible for generating the low-order 32 bits
   of the Identification field in each Registration Request.  Ideally,
   it should generate its own random nonces.  However, it may use any
   expedient method, including duplication of the random value sent by
   the home agent.  The method chosen is of concern only to the mobile
   node, because it is the node that checks for valid values in the
   Registration Reply.  The high-order and low-order 32 bit values of
   the identification chosen SHOULD both differ from their previous
   values.  The home agent uses a new high-order value, and the mobile
   node uses a new low-order value for each registration message.  The
   foreign agent uses the low-order value (and the mobile host's home
   address) to correctly match registration replies with pending
   Requests (Section 3.7.1).

Top      Up      ToC       Page 82 
   If a registration message is rejected because of an invalid nonce,
   the Reply always provides the mobile node with a new nonce to be used
   in the next registration.  Thus, the nonce protocol is self-
   synchronizing.

6.  IANA Considerations

   Mobile IP specifies several new number spaces for values to be used
   in various message fields.  These number spaces include the
   following:

   o  Mobile IP message types sent to UDP port 434, as defined in
      Section 1.8.

   o  types of extensions to Registration Request and Registration Reply
      messages (see Sections 3.3 and 3.4, and also consult [12], [43],
      [2], [3], and [7]).

   o  values for the code in the Registration Reply message (see Section
      3.4, and also consult [12], [43], [2], [3], and [7]).

   o  Mobile IP defines so-called Agent Solicitation and Agent
      Advertisement messages.  These messages are in fact Router
      Discovery messages [5] augmented with Mobile-IP-specific
      extensions.  Thus, they do not define a new name space, but do
      define additional Router Discovery extensions as described below
      in Section 6.2.  Also see Section 2.1, and consult [3] and [7].

   There are additional Mobile IP numbering spaces specified in [3].

   Information about assignment of Mobile IP numbers derived from
   specifications external to this document is given by IANA at
   http://www.iana.org/protocols.  From that URL, see the "Mobile
   Internet Protocol (IP) Numbers" section.

   In this revised specification, a new code value (for the field in the
   Registration Reply message) is needed within the range typically used
   for foreign agent messages.  This error code is needed to indicate
   the status "Invalid Home Agent Address".  See Section 3.7.2 for
   details.

6.1.  Mobile IP Message Types

   Mobile IP messages are defined to be those that are sent to a message
   recipient at port 434 (UDP or TCP).  The number space for Mobile IP
   messages is specified in Section 1.8.  Approval of new extension

Top      Up      ToC       Page 83 
   numbers is subject to Expert Review, and a specification is required
   [22].  The currently standardized message types have the following
   numbers, and are specified in the indicated sections.

     Type  Name                                             Section
     ----  --------------------------------------------     ---------
     1     Registration Request                             3.3
     3     Registration Reply                               3.4

6.2.  Extensions to RFC 1256 Router Advertisement

   RFC 1256 defines two ICMP message types, Router Advertisement and
   Router Solicitation.  Mobile IP defines a number space for extensions
   to Router Advertisement, which could be used by protocols other than
   Mobile IP.  The extension types currently standardized for use with
   Mobile IP have the following numbers.

     Type  Name                                             Section
     ----  --------------------------------------------     ---------
     0     One-byte Padding                                 2.1.3
     16    Mobility Agent Advertisement                     2.1.1
     19    Prefix-Lengths                                   2.1.2

   Approval of new extension numbers for use with Mobile IP is subject
   to Expert Review, and a specification is required [22].

6.3.  Extensions to Mobile IP Registration Messages

   The Mobile IP messages specified within this document and listed in
   Sections 1.8 and 6.1 may have extensions.  Mobile IP message
   extensions all share the same number space, even if they are to be
   applied to different Mobile IP messages.  The number space for Mobile
   IP message extensions is specified within this document.  Approval of
   new extension numbers is subject to Expert Review, and a
   specification is required [22].

     Type  Name                                             Section
     ----  --------------------------------------------     ---------
     0     One-byte Padding
     32    Mobile-Home Authentication                       3.5.2
     33    Mobile-Foreign Authentication                    3.5.3
     34    Foreign-Home Authentication                      3.5.4

Top      Up      ToC       Page 84 
6.4.  Code Values for Mobile IP Registration Reply Messages

   The Mobile IP Registration Reply message, specified in Section 3.4,
   has a Code field.  The number space for the Code field values is also
   specified in Section 3.4.  The Code number space is structured
   according to whether the registration was successful, the foreign
   agent denied the Registration Request, or the home agent denied the
   Registration Request, as follows:

   +---------+------------------------------------------------------+
   | Code #s |                       Guideline                      |
   +---------+------------------------------------------------------+
   |   0-8   |                     Success Codes                    |
   |         |                                                      |
   |   9-63  | Allocation guidelines not specified in this document |
   |         |                                                      |
   |  64-127 |          Error Codes from the Foreign Agent          |
   |         |                                                      |
   | 128-192 |            Error Codes from the Home Agent           |
   |         |                                                      |
   | 193-200 |    Error Codes from the Gateway Foreign Agent [29]   |
   |         |                                                      |
   | 201-255 | Allocation guidelines not specified in this document |
   +---------+------------------------------------------------------+

         Approval of new code values requires Expert Review [22].

            Table 1:  Guidelines for Allocation of Code Values

7.  Acknowledgments

   Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp
   and John Ioannidis (JI) (Columbia University), for forming the
   working group, chairing it, and putting so much effort into its early
   development.  Columbia's early Mobile IP work can be found in [37],
   [38], [39].

   Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon,
   Erik Nordmark, Basavaraj Patil, and Phil Roberts for their
   contributions to the group while performing the duties of
   chairperson, as well as for their many useful comments.

   Thanks to the active members of the Mobile IP Working Group,
   particularly those who contributed text, including (in alphabetical
   order)

Top      Up      ToC       Page 85 
      Ran Atkinson (Naval Research Lab)
      Samita Chakrabarti (Sun Microsystems)
      Ken Imboden (Candlestick Networks, Inc.)
      Dave Johnson (Carnegie Mellon University)
      Frank Kastenholz (FTP Software)
      Anders Klemets (KTH)
      Chip Maguire (KTH)
      Alison Mankin (ISI)
      Andrew Myles (Macquarie University)
      Thomas Narten (IBM)
      Al Quirt (Bell Northern Research)
      Yakov Rekhter (IBM)
      Fumio Teraoka (Sony)
      Alper Yegin (NTT DoCoMo)

   Thanks to Charlie Kunzinger and to Bill Simpson, the editors who
   produced the first drafts of this document, reflecting the
   discussions of the working group.  Much of the new text in the later
   revisions preceding RFC 2002 is due to Jim Solomon and Dave Johnson.

   Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank
   Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for
   their generous support in hosting interim working group meetings.

   Sections 1.10 and 1.11, which specify new extension formats to be
   used with aggregatable extension types, were included from a
   specification document (entitled "Mobile IP Extensions
   Rationalization (MIER)", which was written by

      Mohamed Khalil (Nortel Networks)
      Raja Narayanan (nVisible Networks)
      Haseeb Akhtar (Nortel Networks)
      Emad Qaddoura (Nortel Networks)

   Thanks to these authors, and also for the additional work on MIER,
   which was contributed by Basavaraj Patil, Pat Calhoun, Neil
   Justusson, N. Asokan, and Jouni Malinen.

   Thanks to Vijay Devarapalli, who put in many hours to convert the
   source for this text document into XML format.

Top      Up      ToC       Page 86 
8.  References

8.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Calhoun, P. and C. Perkins, "Mobile IP Network Access
         Identifier Extension for IPv4", RFC 2794, March 2000.

   [3]   Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
         Challenge/Response Extensions (Revised)", RFC 4721, January
         2007.

   [4]   Cong, D., Hamlen, M., and C. Perkins, "The Definitions of
         Managed Objects for IP Mobility Support using SMIv2", RFC 2006,
         October 1996.

   [5]   Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256,
         September 1991.

   [6]   Deering, S., "Host extensions for IP multicasting", STD 5, RFC
         1112, August 1989.

   [7]   Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-
         Specific Extensions", RFC 3115, April 2001.

   [8]   Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness
         Requirements for Security", BCP 106, RFC 4086, June 2005.

   [9]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.

   [10]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [11]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network
         Time Protocol Version 4: Protocol and Algorithms
         Specification", RFC 5905, June 2010.

   [12]  Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
         revised", RFC 3024, January 2001.

   [13]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
         "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

   [14]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
         1996.

Top      Up      ToC       Page 87 
   [15]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
         October 1996.

   [16]  Plummer, D., "Ethernet Address Resolution Protocol: Or
         Converting Network Protocol Addresses to 48.bit Ethernet
         Address for Transmission on Ethernet Hardware", STD 37, RFC
         826, November 1982.

   [17]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
         1980.

   [18]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
         1981.

   [19]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
         1992.

   [20]  Solomon, J., "Applicability Statement for IP Mobility Support",
         RFC 2005, October 1996.

   [21]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
         August 2002.

   [22]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

8.2.  Informative References

   [23]  Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
         PPP IPCP", RFC 2290, February 1998.

   [24]  Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
         Vaidya, "Long Thin Networks", RFC 2757, January 2000.

   [25]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
         Satellite Channels using Standard Mechanisms", BCP 28, RFC
         2488, January 1999.

   [26]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
         Timer", RFC 2988, November 2000.

   [27]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
         Address Translation (NAT) Devices", RFC 3519, April 2003.

   [28]  Glass, S. and M. Chandra, "Registration Revocation in Mobile
         IPv4", RFC 3543, August 2003.

Top      Up      ToC       Page 88 
   [29]  Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
         Regional Registration", RFC 4857, June 2007.

   [30]  Bellovin, S., "Security Problems in the TCP/IP Protocol Suite",
         ACM Computer Communications Review, 19(2), March 1989.

   [31]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
         Shelby, "Performance Enhancing Proxies Intended to Mitigate
         Link-Related Degradations", RFC 3135, June 2001.

   [32]  Caceres, R. and L. Iftode, "Improving the Performance of
         Reliable Transport Protocols in Mobile Computing Environments",
         IEEE Journal on Selected Areas in Communication, 13(5):850-857,
         June 1995.

   [33]  Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
         Vaidya, "End-to-end Performance Implications of Links with
         Errors", BCP 50, RFC 3155, August 2001.

   [34]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

   [35]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [36]  Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
         Links", RFC 1144, February 1990.

   [37]  Ioannidis, J., Duchamp, D., and G. Maguire, "IP-Based Protocols
         for Mobile Internetworking", In Proceedings of the SIGCOMM '01
         Conference: Communications Architectures and Protocols, pages
         235-245, September 1991.

   [38]  Ioannidis, J. and G. Maguire, "The Design and Implementation of
         a Mobile Internetworking Architecture", In Proceedings of the
         Winter USENIX Technical Conference, pages 489-500, January
         1993.

   [39]  Ioannidis, J., "Protocols for Mobile Internetworking", PhD
         Dissertation - Columbia University in the City of New York,
         July 1993.

   [40]  Jacobson, V., "Congestion Avoidance and Control", In
         Proceedings of the SIGCOMM '88 Workshop, ACM SIGCOMM, ACM
         Press, pages 314-329, August 1998.

Top      Up      ToC       Page 89 
   [41]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
         RFC 2863, June 2000.

   [42]  McGregor, G., "The PPP Internet Protocol Control Protocol
         (IPCP)", RFC 1332, May 1992.

   [43]  Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
         Mobile IP", RFC 2356, June 1998.

   [44]  Perkins, C., Ed., "IP Mobility Support", RFC 2002, October
         1996.

   [45]  Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols",
         Addison-Wesley, Reading, Massachusetts, 1994.

   [46]  Perkins, C. and P. Calhoun, "Authentication, Authorization, and
         Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
         March 2005.

   [47]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
         RFC 1661, July 1994.

   [48]  IANA, "Mobile IPv4 Numbers", http://www.iana.org.

   [49]  Postel, J., "Multi-LAN address resolution", RFC 925, October
         1984.

   [50]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3220,
         January 2002.

Top      Up      ToC       Page 90 
Appendix A.  Link-Layer Considerations

   The mobile node MAY use link-layer mechanisms to decide that its
   point of attachment has changed.  Such indications include the Down/
   Testing/Up interface status [41], and changes in cell or
   administration.  The mechanisms will be specific to the particular
   link-layer technology, and are outside the scope of this document.

   The Point-to-Point-Protocol (PPP) [47] and its Internet Protocol
   Control Protocol (IPCP) [42] negotiate the use of IP addresses.

   The mobile node SHOULD first attempt to specify its home address, so
   that if the mobile node is attaching to its home network, the
   unrouted link will function correctly.  When the home address is not
   accepted by the peer, but a transient IP address is dynamically
   assigned to the mobile node, and the mobile node is capable of
   supporting a co-located care-of address, the mobile node MAY register
   that address as a co-located care-of address.  When the peer
   specifies its own IP address, that address MUST NOT be assumed to be
   a foreign agent care-of address or the IP address of a home agent.
   PPP extensions for Mobile IP have been specified in RFC 2290 [23].
   Please consult that document for additional details for how to handle
   care-of address assignment from PPP in a more efficient manner.

Appendix B.  TCP Considerations

B.1.  TCP Timers

   When high-delay (e.g., SATCOM) or low-bandwidth (e.g., High-Frequency
   Radio) links are in use, some TCP stacks may have insufficiently
   adaptive (non-standard) retransmission timeouts.  There may be
   spurious retransmission timeouts, even when the link and network are
   actually operating properly, but just with a high delay because of
   the medium in use.  This can cause an inability to create or maintain
   TCP connections over such links, and can also cause unneeded
   retransmissions that consume already scarce bandwidth.  Vendors are
   encouraged to follow the algorithms in RFC 2988 [26] when
   implementing TCP retransmission timers.  Vendors of systems designed
   for low-bandwidth, high-delay links should consult RFCs 2757 and 2488
   [24], [25].  Designers of applications targeted to operate on mobile
   nodes should be sensitive to the possibility of timer-related
   difficulties.

Top      Up      ToC       Page 91 
B.2.  TCP Congestion Management

   Mobile nodes often use media that are more likely to introduce
   errors, effectively causing more packets to be dropped.  This
   introduces a conflict with the mechanisms for congestion management
   found in modern versions of TCP [40].  Now, when a packet is dropped,
   the correspondent node's TCP implementation is likely to react as if
   there were a source of network congestion, and initiate the slow-
   start mechanisms [40] designed for controlling that problem.
   However, those mechanisms are inappropriate for overcoming errors
   introduced by the links themselves, and have the effect of magnifying
   the discontinuity introduced by the dropped packet.  This problem has
   been analyzed by Caceres, et al. [32].  TCP approaches to the problem
   of handling errors that might interfere with congestion management
   are discussed in documents from the PILC working group [31] [33].
   While such approaches are beyond the scope of this document, they
   illustrate that providing performance transparency to mobile nodes
   involves understanding mechanisms outside the network layer.
   Problems introduced by higher media error rates also indicate the
   need to avoid designs that systematically drop packets; such designs
   might otherwise be considered favorably when making engineering
   tradeoffs.

Top      Up      ToC       Page 92 
Appendix C.  Example Scenarios

   This section shows example Registration Requests for several common
   scenarios.

C.1.  Registering with a Foreign Agent Care-of Address

   The mobile node receives an Agent Advertisement from a foreign agent
   and wishes to register with that agent using the advertised foreign
   agent care-of address.  The mobile node wishes only IP-in-IP
   encapsulation, does not want broadcasts, and does not want
   simultaneous mobility bindings:

        IP fields:
          Source Address = mobile node's home address
          Destination Address = copied from the IP source address of the
            Agent Advertisement
          Time to Live = 1
        UDP fields:
          Source Port = <any>
          Destination Port = 434
        Registration Request fields:
          Type = 1
          S=0,B=0,D=0,M=0,G=0
          Lifetime = the Registration Lifetime copied from the
            Mobility Agent Advertisement Extension of the
            Router Advertisement message
          Home Address = the mobile node's home address
          Home Agent = IP address of mobile node's home agent
          Care-of Address = the Care-of Address copied from the
            Mobility Agent Advertisement Extension of the
            Router Advertisement message
          Identification = Network Time Protocol timestamp or Nonce
        Extensions:
          An authorization-enabling extension (e.g., the Mobile-Home
            Authentication Extension)

Top      Up      ToC       Page 93 
C.2.  Registering with a Co-Located Care-of Address

   The mobile node enters a foreign network that contains no foreign
   agents.  The mobile node obtains an address from a DHCP server [34]
   for use as a co-located care-of address.  The mobile node supports
   all forms of encapsulation (IP-in-IP, minimal encapsulation, and
   GRE), desires a copy of broadcast datagrams on the home network, and
   does not want simultaneous mobility bindings:

        IP fields:
          Source Address = care-of address obtained from DHCP server
          Destination Address = IP address of home agent
          Time to Live = 64
        UDP fields:
          Source Port = <any>
          Destination Port = 434
        Registration Request fields:
          Type = 1
          S=0,B=1,D=1,M=1,G=1
          Lifetime = 1800 (seconds)
          Home Address = the mobile node's home address
          Home Agent = IP address of mobile node's home agent
          Care-of Address = care-of address obtained from DHCP server
          Identification = Network Time Protocol timestamp or Nonce
        Extensions:
          The Mobile-Home Authentication Extension

Top      Up      ToC       Page 94 
C.3.  Deregistration

   The mobile node returns home and wishes to deregister all care-of
   addresses with its home agent:

        IP fields:
          Source Address = mobile node's home address
          Destination Address = IP address of home agent
          Time to Live = 1
        UDP fields:
          Source Port = <any>
          Destination Port = 434
        Registration Request fields:
          Type = 1
          S=0,B=0,D=0,M=0,G=0
          Lifetime = 0
          Home Address = the mobile node's home address
          Home Agent = IP address of mobile node's home agent
          Care-of Address = the mobile node's home address
          Identification = Network Time Protocol timestamp or Nonce
        Extensions:
          An authorization-enabling extension (e.g., the Mobile-Home
            Authentication Extension)

Appendix D.  Applicability of Prefix-Lengths Extension

   Caution is indicated with the use of the Prefix-Lengths Extension
   over wireless links, due to the irregular coverage areas provided by
   wireless transmitters.  As a result, it is possible that two foreign
   agents advertising the same prefix might indeed provide different
   connectivity to prospective mobile nodes.  The Prefix-Lengths
   Extension SHOULD NOT be included in the advertisements sent by agents
   in such a configuration.

   Foreign agents using different wireless interfaces would have to
   cooperate using special protocols to provide identical coverage in
   space, and thus be able to claim to have wireless interfaces situated
   on the same subnetwork.  In the case of wired interfaces, a mobile
   node disconnecting and subsequently connecting to a new point of
   attachment may well send in a new Registration Request no matter
   whether the new advertisement is on the same medium as the last
   recorded advertisement.  And, finally, in areas with dense
   populations of foreign agents it would seem unwise to require the
   propagation via routing protocols of the subnet prefixes associated
   with each individual wireless foreign agent; such a strategy could
   lead to quick depletion of available space for routing tables,

Top      Up      ToC       Page 95 
   unwarranted increases in the time required for processing routing
   updates, and longer decision times for route selection if routes
   (which are almost always unnecessary) are stored for wireless
   "subnets".

Appendix E.  Interoperability Considerations

   This document specifies revisions to RFC 2002 that are intended to
   improve interoperability by resolving ambiguities contained in the
   earlier text.  Implementations that perform authentication according
   to the new more precisely specified algorithm would be interoperable
   with earlier implementations that did what was originally expected
   for producing authentication data.  That was a major source of non-
   interoperability before.

   However, this specification does have new features that, if used,
   would cause interoperability problems with older implementations.
   All features specified in RFC 2002 will work with the new
   implementations, except for V-J compression [36].  The following list
   details some of the possible areas of compatibility problems that may
   be experienced by nodes conforming to this revised specification,
   when attempting to interoperate with nodes obeying RFC 2002.

   o  A client that expects some of the newly mandatory features (like
      reverse tunneling) from a foreign agent (FA) would still be
      interoperable as long as it pays attention to the 'T' bit.

   o  Mobile nodes (MNs) that use the NAI extension to identify
      themselves would not work with old mobility agents.

   o  Mobile nodes that use a zero home address and expect to receive
      their home address in the Registration Reply would not work with
      old mobility agents.

   o  Mobile nodes that attempt to authenticate themselves without using
      the Mobile-Home authentication extension will be unable to
      successfully register with their home agent.

   In all of these cases, a robust and well-configured mobile node is
   very likely to be able to recover if it takes reasonable actions upon
   receipt of a Registration Reply with an error code indicating the
   cause for rejection.  For instance, if a mobile node sends a
   Registration Request that is rejected because it contains the wrong
   kind of authentication extension, then the mobile node could retry
   the registration with a mobile-home authentication extension, since
   the foreign agent and/or home agent in this case will not be
   configured to demand the alternative authentication data.

Top      Up      ToC       Page 96 
Appendix F.  Changes since RFC 3344

   The following revisions to details of the specification in this
   document were made after RFC 3344 was published.  A list of changes
   from RFC 2002 made during the development of RFC 3344 [21] may be
   found in the latter document.  For items marked with issue numbers,
   more information is available by consulting the MIP4 mailing list
   archives.

   o  Showed more bit definitions in the Agent Advertisement message
      structure (see Section 2.1.1).  New advertisement bits have been
      defined by other specification documents, but not reflected in
      previous publications of this specification; this has led to
      confusion.  Citations for the other specification documents have
      also been included.

   o  (Issue 6) The behavior of the home agent was changed to avoid
      mandating error replies to Registration Requests that were
      invalidated because the foreign agent failed authentication.  The
      intention is to make the home agent more robust against Denial of
      Service attacks in which the malicious device has no intention of
      providing a valid Registration Request but only wants to congest
      traffic on the home network.  See Section 3.8.2.1.

   o  Due to non-unique assignment of IPv4 addresses in many domains, it
      is possible for different mobile nodes to have the same home
      address.  If they use the NAI, the foreign agent can still
      distinguish them.  Language was added to Section 3.7.1 and Section
      3.7.3.1 to specify that the foreign agent MUST use the NAI to
      distinguish mobile nodes with the same home address.

   o  (Issue 45) Specified that a foreign agent MUST NOT apply a
      Foreign-Home Authentication extension to a mobile node's
      deregistration request.  Also, the foreign agent MUST NOT apply a
      Foreign-Home Authentication extension unless the Care-of Address
      in the Registration Request matches an address advertised by the
      foreign agent.

   o  Specified that the Mobility Security Association to be used by the
      foreign agent and home agent depends upon values contained in the
      message data, not the IP headers.

   o  (Issues 9, 18) Created a new error code for use by the foreign
      agent, for the case when the foreign agent does not serve the
      mobile node as a home agent.  Formerly, the foreign agent could
      use an error Code of 136 for this case.

Top      Up      ToC       Page 97 
   o  (Issue 17) Specified that, if the home agent cannot support the
      requested nonzero unicast address in the Home Address field of the
      Registration Request, then it MUST reject the registration with an
      error Code of 129.  See Section 3.8.3.2.

   o  (Issue 19) Specified that multiple authorization-enabling
      extensions may be present in the Registration Request message, but
      that the home agent has to (somehow) ensure that all have been
      checked (see Section 3.8.3.1).

   o  (Issue 20) Specified that the foreign agent SHOULD NOT modify any
      of the fields of the Registration Reply message that are covered
      by the Mobile-Home Authentication Extension, when it relays the
      packet to the mobile node.

   o  (Issue 21) Clarified that the foreign agent removes extensions
      that do not precede any authorization-enabling extension, not just
      the Mobile-Home Authentication extension (Section 3.7.3.2).

   o  (Issue 44) Specified that the address advertised by the foreign
      agent in Agent Advertisements is the care-of address offered on
      that network interface, not necessarily the address of the network
      interface (Section 3.7.2.2).

   o  (Issue 45) Clarification in Section 3.7.2.1 that Code 77 can only
      apply to a Registration Request with nonzero Lifetime.

   o  Created a new error code for use when a foreign agent can detect
      that the Home Agent address field is incorrect.

   o  Prohibited the use of the Foreign-Home Authorization Extension on
      deregistration messages.

   o  Cleaned up some more wording having to do with authorization-
      enabling extensions.

   o  For consistency, changed some wording about copying UDP ports.

   o  Added wording to clearly not disallow dynamically configuring
      netmask and security information at the mobile node.

   o  Revamped Changes section.

   o  Updated citations.

Top      Up      ToC       Page 98 
Appendix G.  Example Messages

G.1.  Example ICMP Agent Advertisement Message Format

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Num Addrs   |Addr Entry Size|           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Router Address[1]                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Preference Level[1]                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Router Address[2]                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Preference Level[2]                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        ....                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 16   |     Length    |      Sequence Number          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Registration Lifetime      |R|B|H|F|M|G|r|T|U|X|I|reserved |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Care-of Address[1]                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Care-of Address[2]                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         ....                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                     Optional  Extensions                      :
    :   ....                ......                      ......      :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 99 
G.2.  Example Registration Request Message Format

   The UDP header is followed by the Mobile IP fields shown below:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type = 1  |S|B|D|M|G|r|T|x|          Lifetime             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Home Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Home Agent                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Care-of Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                         Identification                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Optional Non-Auth Extensions for HA ...        |
    |                     ( variable length )                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 32   |      Length   |           SPI                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          SPI (cont.)          |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    :         MN-HA Authenticator ( variable length )               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :           Optional  Non-Auth Extensions for FA .........
    :           Optional  MN-FA  Authentication Extension...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 100 
G.3.  Example Registration Reply Message Format

   The UDP header is followed by the Mobile IP fields shown below:

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 3    |     Code      |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Home Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Home Agent                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                         Identification                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Optional  HA  Non-Auth Extensions ...         |
    |                     ( variable length )                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 32   |      Length   |           SPI                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          SPI (cont.)          |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    :         MN-HA Authenticator ( variable length )               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :           Optional  Extensions used by FA.........
    :           Optional  MN-FA Authentication Extension...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Author's Address

   Charles E. Perkins (editor)
   WiChorus Inc.
   3590 N. 1st Street, Suite 300
   San Jose, CA  95134
   USA

   EMail: charliep@computer.org