rfc2290.txt

RFC 的详细文档！

   defined in the previous sections.  In the examples which follow, a
   Configure-Request sent by a mobile node and the response generated by
   the peer are shown on the same line.  The number and letter to the
   left of each request/response refer to the numbered and lettered
   items in Section 2.5.

    A. A mobile node prefers a co-located care-of address and the peer
       is a foreign agent that is capable of assigning such an address:

       (1)(a) Request(IP=0,MIPv4=Home) / Nak(IP=coa)
       (2)(a) Request(IP=coa,MIPv4=Home) / Ack(IP=coa,MIPv4=Home)

         - Mobile node waits to receive an Agent Advertisement.
         - If (Advertisement has R-bit set) then
             Mobile node registers using co-located care-of address via
             the foreign agent;
           else
             Mobile node registers using co-located care-of address
             directly with its home agent.

    B. A mobile node prefers a co-located care-of address and the peer
       is a foreign agent that cannot assign a co-located care-of
       address (e.g., it has no pool of addresses from which to allocate
       for the purpose of assignment):

       (1)(c) Request(IP=0,MIPv4=Home) / Reject(IP=0)
       (4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)

         - IPCP completes.
         - Mobile node waits to receive an Agent Advertisement.
         - Mobile node registers using the peer's foreign agent care-of
           address with its home agent.



Solomon & Glass             Standards Track                    [Page 12]

RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998


    C. A mobile node prefers a co-located care-of address and the peer
       determines that the mobile node's home address is such that the
       mobile node is connecting to its home link:

       (1)(b) Request(IP=0,MIPv4=Home) / Nak(IP=Home)
       (3)(a) Request(IP=Home,MIPv4=Home) / Ack(IP=Home,MIPv4=Home)

         - IPCP completes.
         - Mobile node de-registers with its home agent.

    D. A mobile node prefers a foreign agent care-of address and the
       peer is a foreign agent which finds this state of affairs
       satisfactory:

       (4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)

         - IPCP completes.
         - Mobile node waits to receive an Agent Advertisement.
         - Mobile node registers using the peer's foreign agent care-of
           or de-registers at home, depending on the values in the Agent
           Advertisement.

    E. A mobile node prefers a co-located care-of address and the peer
       does not implement the Mobile-IPv4 Configuration Option.  The
       peer is, however, capable of assigning dynamic addresses:

       (1)(d) Request(IP=0,MIPv4=Home) / Reject(MIPv4=Home)
       (5)(a) Request(IP=0) / Nak(IP=a.b.c.d)
       (6)(a) Request(IP=a.b.c.d) / Ack(IP=a.b.c.d)

         - IPCP completes.
         - Mobile node registers using a.b.c.d as a co-located care-of
           address with its home agent.

    F. A mobile node prefers a co-located care-of address and the peer
       does not implement the Mobile-IPv4 Configuration Option. The peer
       is not capable of assigning dynamic addresses:

       (1)(e) Request(IP=0,MIPv4=Home) / Reject(IP=0,MIPv4=Home)
       (7)(a) Request() / Ack()

         - IPCP completes.
         - Mobile node sends an Agent Solicitation and/or attempts to
           obtain a co-located care-of address via means outside IPCP
           (e.g., DHCP or manual configuration), or it gives up.






Solomon & Glass             Standards Track                    [Page 13]

RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998


3. Additional Requirements

3.1. Other IPCP Options

   A mobile node MUST NOT include the deprecated IP-Addresses option in
   any Configure-Request that contains a Mobile-IPv4 option, an IP-
   Address option, or both.

   Conversely, the mobile node MAY include an IP-Compression-Protocol
   option and any other options that do not involve the negotiation of
   IP addresses.

   If a mobile node and a foreign agent or a home agent agree in IPCP to
   use Van Jacobson Header Compression [RFC 1144], then the mobile node
   MUST NOT set the 'V' bit in its ensuing Mobile IP Registration
   Request [RFC 2002].  If the PPP peer entities are utilizing VJ header
   compression there is no gain for the mobile ip entities to do so, and
   requesting this option is likely to cause confusion.

3.2. Move Detection

   Mobile nodes that connect via PPP MUST correctly implement PPP's
   IPCP, since movement by the mobile node will likely change its PPP
   peer.  Specifically, mobile nodes MUST be prepared to renegotiate
   IPCP at any time, including, the renegotiation of the IP-Address
   Configuration Option and the Mobile-IPv4 Configuration Option
   described in this document.  As per [RFC 1661], a mobile node in the
   Opened state MUST renegotiate IPCP upon receiving an IPCP Configure-
   Request from its peer.

   Also note that certain wireless links can employ handoff and proxying
   mechanisms that would not necessarily require bringing down a PPP
   link but would indeed require a mobile node to register with a new
   foreign agent.  Therefore, mobile nodes which connect to an agent via
   PPP MUST employ their move detection algorithms (see section 2.4.2 in
   [RFC 2002]) and register whenever they detect a change in
   connectivity.

   Specifically, a mobile node that fails to receive an Agent
   Advertisement within the Lifetime advertised by its current foreign
   agent, MUST assume that it has lost contact with that foreign agent
   (see Section 2.4.2.1, [RFC 2002]).  If, in the mean time, the mobile
   node has received Agent Advertisements from another foreign agent,
   the mobile node SHOULD immediately register with that foreign agent
   upon timing out with its current foreign agent.






Solomon & Glass             Standards Track                    [Page 14]

RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998


   Likewise, a mobile node that implements move detection based upon the
   Prefix-Length Extension MUST compare the prefix of any advertising
   agents with that of its current foreign agent (see Section 2.4.2.2,
   [RFC 2002]).  If such a mobile node receives an Agent Advertisement
   from a foreign agent specifying a different prefix than that of its
   current foreign agent, then the mobile node that employs this method
   of move detection MUST register with that new foreign agent.

   A mobile node MAY treat PPP link-establishment as a sufficient reason
   to proceed with a new Mobile IP registration.  Section 2 defines the
   circumstances under which mobile nodes MUST wait for an Agent
   Advertisement before registering.  Accordingly, foreign agents and
   home agents SHOULD send an Agent Advertisement over a PPP link
   immediately after IPCP for that link enters the Opened state.

4. Security Considerations

   This document introduces no known security threats over and above
   those facing any node on the Internet that either connects via PPP or
   implements Mobile IP or both.  Specifically, service providers should
   use cryptographically strong authentication (e.g., CHAP [RFC 1994])
   to prevent theft-of-service.  Additionally, users requiring
   confidentiality should use PPP link encryption [RFC 1968], IP-layer
   encryption [RFC 1827], or application-layer encryption, depending
   upon their individual requirements.  Finally, Mobile IP
   authentication [RFC 2002] protects against trivial denial-of-service
   attacks that could otherwise be waged against a mobile node and its
   home agent.

5. References

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

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

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

   [RFC 1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)
      for the Transmission of Multi-protocol Datagrams over Point-to-
      Point Links", STD 51, RFC 1661, July 1994.

   [RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
      RFC 1827, August 1995.





Solomon & Glass             Standards Track                    [Page 15]

RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998


   [RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication
      Protocol (CHAP)", RFC 1994, August 1996.

   [RFC 1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)",
      RFC 1968, June 1996.

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

6. Acknowledgments

   The design of this protocol and option were inspired by an earlier
   submission by B. Patel and C. Perkins, then of IBM, in a now expired
   internet draft.  Also, some of William Simpson's text was copied
   verbatim from [RFC 1661] in order to ensure consistency of
   terminology and specification.  The same goes for some of Charlie
   Perkins' definitions, and other relavent text, from [RFC 2002].

   Tim Wilson and Chris Stanaway (Motorola) contributed significantly to
   the design of this Configuration Option and protocol specification.
   Special thanks to Vernon Schryver (SGI), Craig Fox (Cisco), Karl Fox
   (Ascend), and John Bray (FTP) for their helpful suggestions,
   comments, and patience.

7. Authors' Addresses

   Jim Solomon
   Motorola, Inc.
   1301 E. Algonquin Rd. - Rm 2240
   Schaumburg, IL  60196

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]


   Steven Glass
   FTP Software, Inc.
   2 High Street
   North Andover, MA  01845

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]







Solomon & Glass             Standards Track                    [Page 16]

RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Solomon & Glass             Standards Track                    [Page 17]