doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc2290.txt b/doc/rfc/rfc2290.txt
new file mode 100644
index 0000000..9131347
--- /dev/null
+++ b/doc/rfc/rfc2290.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                         J. Solomon
+Request for Comments: 2290                                      Motorola
+Updates: 2002                                                   S. Glass
+Category: Standards Track                                   FTP Software
+                                                           February 1998
+
+
+             Mobile-IPv4 Configuration Option for PPP IPCP
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   Mobile IP [RFC 2002] defines media-independent procedures by which a
+   Mobile Node can maintain existing transport and application-layer
+   connections despite changing its point-of-attachment to the Internet
+   and without changing its IP address.  PPP [RFC 1661] provides a
+   standard method for transporting multi-protocol packets over point-
+   to-point links.  As currently specified, Mobile IP Foreign Agents
+   which support Mobile Node connections via PPP can do so only by first
+   assigning unique addresses to those Mobile Nodes, defeating one of
+   the primary advantages of Foreign Agents.  This documents corrects
+   this problem by defining the Mobile-IPv4 Configuration Option to the
+   Internet Protocol Control Protocol (IPCP) [RFC 1332].  Using this
+   option, two peers can communicate their support for Mobile IP during
+   the IPCP phase of PPP.  Familiarity with Mobile IP [RFC 2002], IPCP
+   [RFC 1332], and PPP [RFC 1661] is assumed.
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   2
+       1.1. Specification Language . . . . . . . . . . . . . . . . .   2
+       1.2. Terminology  . . . . . . . . . . . . . . . . . . . . . .   2
+       1.3. Problem Statement  . . . . . . . . . . . . . . . . . . .   3
+       1.4. Requirements . . . . . . . . . . . . . . . . . . . . . .   5
+   2. Mobile-IPv4 Configuration Option . . . . . . . . . . . . . . .   6
+       2.1. Option Format  . . . . . . . . . . . . . . . . . . . . .   6
+       2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . .   7
+
+
+
+Solomon & Glass             Standards Track                     [Page 1]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+       2.3. High-Level Requirements for Non-Mobile-Nodes . . . . . .   7
+       2.4. High-Level Requirements for Mobile Nodes . . . . . . . .   8
+       2.5. Detailed Description . . . . . . . . . . . . . . . . . .   8
+       2.6. Example Scenarios  . . . . . . . . . . . . . . . . . . .  12
+   3. Additional Requirements  . . . . . . . . . . . . . . . . . . .  14
+       3.1. Other IPCP Options . . . . . . . . . . . . . . . . . . .  14
+       3.2. Move Detection . . . . . . . . . . . . . . . . . . . . .  14
+   4. Security Considerations  . . . . . . . . . . . . . . . . . . .  15
+   5. References . . . . . . . . . . . . . . . . . . . . . . . . . .  15
+   6. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  16
+   7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  16
+   8. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  17
+
+1. Introduction
+
+   Mobile IP [RFC 2002] defines protocols and procedures by which
+   packets can be routed to a mobile node, regardless of its current
+   point-of-attachment to the Internet, and without changing its IP
+   address.  Mobile IP is designed to run over any type of media and any
+   type of data link-layer.  However, the interaction between Mobile IP
+   and PPP is currently underspecified and generally results in an
+   inappropriate application of Mobile IP when mobile nodes connect to
+   the Internet via PPP.
+
+   This document defines proper interaction between a mobile node [RFC
+   2002] and a peer through which the mobile node connects to the
+   Internet using PPP.  This requires the definition of a new option for
+   IPCP [RFC 1332], named the "Mobile-IPv4" Configuration Option, which
+   is defined in this document.  The mobile node and the peer use this
+   option to negotiate the appropriate use of Mobile IP over the PPP
+   link.
+
+   The Mobile-IPv4 option defined in this document is intended to work
+   in conjunction with the existing IP-Address option [RFC 1332].
+
+1.1. Specification Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+1.2. Terminology
+
+   This document uses the following terms as defined in [RFC 2002]:
+
+
+
+
+
+
+
+Solomon & Glass             Standards Track                     [Page 2]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+      Mobile Node
+
+         A host or router that changes its point-of-attachment from one
+         link to another.  A mobile node may change its location without
+         changing its IP address; it may continue to communicate with
+         other Internet nodes at any location using its (permanent)
+         home, IP address, assuming link-layer connectivity is available
+         at its current location.
+
+      Home Agent
+
+         A router with at least one interface on a mobile node's home
+         link.  A home agent intercepts packets destined to a mobile
+         node's home address and tunnels them to the mobile node's
+         care-of address when the mobile node is connected to a foreign
+         link.  A mobile node informs its home agent of its current
+         care-of address through an authenticated registration protocol
+         defined by Mobile IP.
+
+      Foreign Agent
+
+         A router with at least one interface on a mobile node's
+         (current) foreign link.  When a mobile node uses a foreign
+         agent's care-of address, the foreign agent detunnels and
+         delivers packets to the mobile node that were tunneled by the
+         mobile node's home agent.  A foreign agent might also serve as
+         a default router for packets sent by a registered mobile node.
+
+      Peer
+
+         The PPP peer of a mobile node.  The mobile node's peer might
+         support home agent functionality, foreign agent functionality,
+         both, or neither.
+
+1.3. Problem Statement
+
+   In Mobile IP, packets sent to a mobile node's home address are routed
+   first to the mobile node's home agent, a router on the mobile node's
+   home link which intercepts packets sent to the home address.  The
+   home agent then tunnels such packets to the mobile node's care-of
+   address, where the packets are extracted from the tunnel and
+   delivered to the mobile node.  There are two types of care-of
+   addresses:
+
+
+
+
+
+
+
+
+Solomon & Glass             Standards Track                     [Page 3]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+   Co-located Care-of Address
+
+      An address temporarily assigned to a mobile node itself.  In this
+      case, the mobile node is the exit-point of the tunnel and
+      decapsulates packets encapsulated for delivery by its home agent.
+      A Co-located Care-of Address may be used by exactly one mobile
+      node at any point in time.
+
+   Foreign Agent Care-of Address
+
+      An address of a foreign agent that has at least one interface on a
+      mobile node's visited, foreign link.  In this case, the foreign
+      agent decapsulates packets that have been tunneled by the home
+      agent and delivers them to the mobile node over the visited link.
+      A Foreign Agent Care-of Address may be used simultaneously by many
+      mobile nodes at any point in time.
+
+   In Appendix B, Mobile IP [RFC 2002] currently specifies only the
+   following with respect to PPP:
+
+      "The Point-to-Point-Protocol (PPP) [RFC 1661] and its Internet
+      Protocol Control Protocol (IPCP) [RFC 1332], negotiates [sic] 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 [link], 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."
+
+   Inspection of this text reveals that there is currently no way for
+   the mobile node to use a foreign agent care-of address, without first
+   being assigned a unique IP address, even if the peer also supports
+   foreign agent functionality.  The reason for this can be seen by
+   walking through the IPCP negotiation:
+
+    1. A mobile node connects to a peer via PPP and proposes its home
+       address in an IPCP Configure-Request containing the IP-Address
+       option.  In this scenario, we assume that the mobile node is
+       connecting to some foreign link.
+
+
+
+
+
+
+Solomon & Glass             Standards Track                     [Page 4]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+    2. The peer has no way of knowing whether this Configure-Request was
+       received from: (a) a mobile node proposing its home address; or
+       (b) a conventional node proposing some topologically non-routable
+       address.  In this case, the peer must (conservatively) send a
+       Configure-Nak of the IP-Address option supplying a topologically
+       appropriate address for use by the node at the other end of the
+       PPP link.
+
+    3. The mobile node, in turn, has no way of knowing whether this
+       Configure-Nak was received because the peer is a foreign agent
+       being conservative, or because the peer does not implement Mobile
+       IP at all.  Therefore, the mobile node must (conservatively)
+       assume that the peer does not implement Mobile IP and continue
+       the negotiation of an IP address in IPCP, after which point the
+       mobile node can use the assigned address as a co-located care-of
+       address.
+
+   Here we observe that, even if the mobile node's peer is a foreign
+   agent and sends an Agent Advertisement to the mobile node after IPCP
+   reaches the Opened state, the mobile node will still have negotiated
+   a routable address in step 3, which it is likely already using as a
+   co-located care-of address.  This defeats the purpose of foreign
+   agent care-of addresses, which are designed to be shared by multiple
+   mobile nodes and to eliminate the need to assign a unique address to
+   each mobile node.
+
+1.4. Requirements
+
+   The purpose of this document is to specify the behavior of both ends
+   of the PPP link when one or more of the PPP peers supports Mobile IP.
+   Specifically, the design of the option and protocol defined in this
+   document is based upon the following requirements:
+
+    1. The option and protocol described in this document must be
+       backwards compatible with conventional nodes and their potential
+       peers which do not implement this option nor any Mobile IP
+       functionality.
+
+    2. The option and protocol described in this document must
+       accommodate a variety of scenarios, minimally those provided in
+       the examples of Section 2.6.
+
+    3. The option and protocol described in this document must not
+       duplicate any functionality already defined in other IPCP
+       options; specifically, the IP-Address option.
+
+
+
+
+
+
+Solomon & Glass             Standards Track                     [Page 5]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+    4. A unique address must not be assigned to a mobile node unless
+       absolutely necessary.  Specifically, no such address is assigned
+       to a mobile node that connects via PPP to its home link or a
+       mobile node that connects via PPP to a foreign agent (and uses
+       that foreign agent's care-of address).
+
+2. Mobile-IPv4 Configuration Option
+
+   This section defines the Mobile-IPv4 Configuration Option and
+   provides several examples of its use.
+
+2.1. Option Format
+
+   The Mobile-IPv4 Configuration Option for IPCP is defined as follows:
+
+    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      |    Length     |         Mobile Node's ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         ...  Home Address         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Type
+
+      4 (Mobile-IPv4)
+
+   Length
+
+      6 (The length of this entire extension in bytes)
+
+   Mobile Node's Home Address
+
+      In a Configure-Request, the IP home address of the mobile node
+      sending this Configuration Option, otherwise the (unmodified) IP
+      home address of the mobile node when sent in a Configure-Ack or
+      Configure-Reject. Configure-Nak'ing this option is undefined and
+      MUST NOT be sent by implementations complying with this version of
+      the specification.  This field MUST NOT be zero.
+
+   Default Value
+
+      The Mobile-IPv4 Configuration Option defaults to the sending
+      mobile node's home address.
+
+   In describing the operation of the Mobile-IPv4 Configuration Option
+   (in conjunction with the IP-Address Configuration Option), we use the
+   following abbreviations:
+
+
+
+Solomon & Glass             Standards Track                     [Page 6]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+      PPP Message Types:
+          Request = Configure-Request
+           Reject = Configure-Reject
+              Ack = Configure-Ack
+              Nak = Configure-Nak
+
+      IPCP Configuration Options:
+            MIPv4 = Mobile-IPv4
+               IP = IP-Address
+
+      IP addresses:
+          a.b.c.d = some non-zero IP address
+          w.x.y.z = some non-zero IP address other than a.b.c.d
+             home = a mobile node's IP Home address
+              coa = an IP Care-Of Address
+                0 = the all-zeroes IP address (0.0.0.0)
+
+2.2. Overview
+
+   The Mobile-IPv4 Configuration Option is designed to be used in
+   conjunction with the IP-Address Configuration Option.  For the
+   convenience of implementors, the detailed description in section 2.5
+   includes all possible combinations of these two options that might be
+   sent by a PPP peer during IPCP.  Along with each possibility is a
+   description of how the receiver should interpret the contents as well
+   as a suggested course of action.
+
+2.3. High-Level Requirements for Non-Mobile-Nodes
+
+   A node that is not performing mobile node functionality (such as
+   non-Mobile-IP-aware nodes as well as nodes performing only home agent
+   functionality, foreign agent functionality, or both) MUST NOT include
+   a Mobile-IPv4 Configuration Option within any Configure-Request
+   message.  As per [RFC 1332], such a node SHOULD send a Configure-
+   Request containing an IP-Address Configuration Option in which the
+   IP-Address field is set to a non-zero IP address that the node has
+   assigned to one of its interfaces.  If an explicit IP address has
+   been assigned to the node's PPP interface then this address SHOULD be
+   sent in preference to any of the node's other addresses.
+
+   A node MUST NOT send a Configure-Nak containing a Mobile-IPv4
+   Configuration Option.  Doing so is currently "undefined" and might
+   cause interoperability problems when a useful meaning for Configure-
+   Nak is ultimately defined for the Mobile-IPv4 Configuration Option.
+   A node that sends a Configure-Ack containing a Mobile-IPv4
+   Configuration Option SHOULD send an Agent Advertisement [RFC 2002]
+   immediately upon IPCP for that link entering the Opened state.
+
+
+
+
+Solomon & Glass             Standards Track                     [Page 7]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+2.4. High-Level Requirements for Mobile Nodes
+
+   A mobile node SHOULD begin its IPCP negotiation by sending the
+   Configure-Request described in either item #1 or item #4 in Section
+   2.5.  The mobile node MAY begin its negotiation with one of the other
+   numbered items in Section 2.5 under extenuating circumstances.
+
+   A mobile node that receives a Configure-Ack containing a Mobile-IPv4
+   Configuration Option MUST receive an Agent Advertisement, possibly in
+   response to an Agent Solicitation, before sending a Registration
+   Request [RFC 2002] if that mobile node is connecting to a foreign
+   link.  This is because the peer might be a foreign agent that
+   enforces a policy which requires a mobile node to register with that
+   foreign agent even if the mobile node is using a co-located care-of
+   address.  A mobile node need not wait for such an advertisement if it
+   connects to its home link.  See item 7a in section 2.5 for one way in
+   which a mobile node can determine if it has connected to its home
+   link.  Another way is by receiving an explicit notification of this
+   fact from its peer, such as receipt of the messages in items 1b, 2c,
+   and 3a in section 2.5.
+
+   A mobile node that receives a Configure-Reject containing a Mobile-
+   IPv4 Configuration Option SHOULD fall back to IPCP negotiation using
+   the IP-Address option [RFC 1332].  A mobile node SHOULD begin this
+   negotiation with Request(IP=home) or Request(IP=0), depending on
+   whether or not the mobile node is connecting to its home link,
+   respectively.  A mobile node MAY make this determination by
+   inspection of an IP-Address option contained within a Configure-
+   Request sent by its peer.  If the prefix of the peer's stated IP-
+   address is equal to the prefix of the mobile node's home address,
+   then the mobile node MAY conclude that it is connecting to its home
+   link.  Otherwise, if the mobile node is connecting to a foreign link,
+   then the mobile node SHOULD send Request(IP=0) since its peer might
+   have no means for assigning addresses other than IPCP.  This
+   specification therefore updates this behavior as described in [RFC
+   2002], the latter of which recommends that a mobile node begin IP-
+   Address negotiation with Request(IP=Home) under all circumstances.
+
+   A peer that is performing neither home agent nor foreign agent
+   functionality SHOULD send a Reject in response to any Request
+   received from its peer that contains a Mobile-IPv4 Configuration
+   Option.
+
+2.5. Detailed Description
+
+   The numbered items below show all possible combinations of Mobile-
+   IPv4 and IP-Address Configuration Options that a mobile node (or a
+   conventional node) might send to its peer.  Mobile nodes SHOULD begin
+
+
+
+Solomon & Glass             Standards Track                     [Page 8]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+   their IPCP negotiation with item #1 or item #4 depending on whether
+   they prefer a co-located or a foreign agent care-of address
+   respectively.  The lettered items list the possible legal responses
+   that a peer might send to the mobile node (or conventional node) in
+   response to the numbered Request.
+
+   In each case, an interpretation is defined and a suggested course of
+   action is provided.  Finally, it is believed that the presentation
+   below has the advantages of conciseness and precision in comparison
+   to an equivalent presentation in "prose form."
+
+    1. Request(IP=0,MIPv4=home) means "I prefer a co-located care-of
+       address to a foreign agent care-of address."  Peer MUST respond
+       with one of the following:
+
+        a. Nak(IP=coa) means "use coa as your co-located care-of
+           address".  Goto 2.
+        b. Nak(IP=home) means "you're at home and don't need a care-of
+           address".  Goto 3.
+        c. Reject(IP=0) means "I cannot assign a co-located care-of
+           address but you're welcome to use me as a foreign agent".
+           Goto 4.
+        d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
+           option".  If the peer also sent Request(IP=address) and the
+           prefix of the peer's assigned address is equal to that of the
+           mobile node's home address, then goto 6 with a.b.c.d=home;
+           otherwise, goto 5.
+        e. Reject(IP=0,MIPv4=home) means "use the default".  Goto 7.
+
+        => Ack(IP=0, ...), Nak(MIPv4=any, ...) MUST NOT be sent.
+
+    2. Request(IP=coa,MIPv4=home) means "I want to use coa as my co-
+       located care-of address."  Peer MUST respond with one of the
+       following:
+
+        a. Ack(IP=coa,MIPv4=home) means "ok, use coa as your co-located
+           care-of address; be sure to wait for an advertisement."
+           Opened.
+        b. Nak(IP=alternate-coa) means "no, use alternate-coa as your
+           co-located care-of address".  Goto 2.
+        c. Nak(IP=home) means "you're at home and don't need a co-
+           located care-of address".  Goto 3.
+        d. Reject(IP=coa) means "coa is not a useful value for a co-
+           located care-of address on this link and I cannot assign a
+           useful one (or I will not negotiate the IP-Address option) --
+           you may use me as a foreign agent".  Goto 4.
+
+
+
+
+
+Solomon & Glass             Standards Track                     [Page 9]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+        e. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
+           option".  If the peer also sent Request(IP=address) and the
+           prefix of the peer's address is equal to that of the mobile
+           node's home address, then goto 6 with a.b.c.d=home;
+           otherwise, goto 5.
+        f. Reject(IP=coa,MIPv4=home) means "use the default".  Goto 7.
+
+        => Nak(MIPv4=any, ...) MUST NOT be sent.
+
+    3. Request(IP=home,MIPv4=home) means "I think I'm at home but if I'm
+       wrong then I prefer a co-located care-of address to a foreign
+       agent care-of address."  Peer MUST respond with one of the
+       following:
+
+        a. Ack(IP=home,MIPv4=home) means "yes, you're at home".  Opened.
+        b. Nak(IP=coa) means "you're not at home, use coa as your co-
+           located care-of address".  Goto 2.
+        c. Reject(IP=home) means "you're not at home and I cannot assign
+           a co-located care-of address (or I will not negotiate the
+           IP-Address option) -- you may use me as a foreign agent".
+           Goto 4.
+        d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
+           option".  If the peer also sent Request(IP=address) and the
+           prefix of the peer's address is equal to that of the mobile
+           node's home address, then goto 6 with a.b.c.d=home;
+           otherwise, goto 5.
+        e. Reject(IP=home,MIPv4=home) means "use the default".  Goto 7.
+
+        => Nak(MIPv4=any, ...) MUST NOT be sent.
+
+    4. Request(MIPv4=home) means "I want to run Mobile IP over this link
+       and I don't want a co-located care-of address." Peer MUST respond
+       with one of the following:
+
+        a. Ack(MIPv4=home) means "ok, wait for an advertisement to
+           figure out where you are."  Opened.
+        b. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
+           option".  If the peer also sent Request(IP=address) and the
+           prefix of the peer's address is equal to that of the mobile
+           node's home address, then goto 6 with a.b.c.d=home;
+           otherwise, goto 5.
+
+        => Nak(MIPv4=any, ...) MUST NOT be sent.
+
+    5. Request(IP=0) means "Please assign an address/co-located-care-
+       of-address".  Peer MUST respond with one of the following:
+
+
+
+
+
+Solomon & Glass             Standards Track                    [Page 10]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+        a. Nak(IP=a.b.c.d) means "use a.b.c.d as your address/co-
+           located-care-of-address".  Goto 6.
+        b. Reject(IP=0) means "I cannot assign an address (for the
+           Mobile Node to use as a co-located-care-of-address), or I do
+           not implement the IP-Address option".  Goto 7.
+
+        => Ack(IP=0) MUST NOT be sent and historically means "I don't
+           know your address either".  Opened.  An implementation MUST
+           NOT use 0 as its IP address upon receiving Ack(IP=0) but MAY
+           use some other, non-zero, interface address for packets sent
+           on its PPP interface.
+
+    6. Request(IP=a.b.c.d) means "I want to use a.b.c.d as my
+       address/home-address/co-located-care-of-address".  Peer MUST
+       respond with one of the following:
+
+        a. Ack(IP=a.b.c.d) means "ok, a.b.c.d is your address/home-
+           address/co-located-care-of-address".  Opened.
+        b. Nak(IP=w.x.y.z) means "no, use w.x.y.z as your address/home-
+           address/co-located-care-of-address".  Goto 6.
+        c. Reject(IP=a.b.c.d) means "a.b.c.d is a bad address to use,
+           but I cannot give you a good one" or "I do not implement the
+           IP-Address option".  Goto 7.
+
+    7. Request() means "I want to use the default".  Peer MUST respond
+       with one of the following:
+
+        a. Ack() means "ok, use the default".  Opened.
+
+           In this case the mobile node will use the "default" values of
+           the IP-Address option (no address configured by IPCP) and the
+           Mobile-IPv4 option (the mobile node's IP home address).  The
+           mobile node SHOULD send Agent Solicitations to see if there
+           are any agents present on the current link. (Note that the
+           current "link" might also include a shared medium if the
+           mobile node's PPP peer is a bridge.)  If an agent is present
+           and the mobile node receives an Agent Advertisement, then the
+           mobile node employs its move-detection algorithm(s) and
+           registers accordingly.
+
+           In any case, if the mobile node's peer supplied an IP-Address
+           option containing a non-zero value within an IPCP Configure-
+           Request, the mobile node MAY use this address to determine
+           whether or not it is connected to its home link.  This can be
+           accomplished by comparing the stated IP address with the
+           mobile node's home address under the prefix-length associated
+           with the home link.  If the mobile node is connected to its
+           home link then it SHOULD de-register with its home agent.
+
+
+
+Solomon & Glass             Standards Track                    [Page 11]
+
+RFC 2290            Mobile-IPv4 Option for PPP IPCP        February 1998
+
+
+           Otherwise, the mobile node MAY attempt to obtain a
+           topologically routable address through any of its supported
+           means (e.g., DHCP, manual configuration, etc.)  for use as a
+           co-located care-of address.  If the mobile node is successful
+           in obtaining such an address then it SHOULD register this
+           address with its home agent.
+
+        => Nak(IP=0) MUST NOT be sent.  Goto 6.
+
+        => Nak() MUST NOT be sent.
+
+        => Reject() MUST NOT be sent.
+
+2.6. Example Scenarios
+
+   This section illustrates the use of the option and protocol as
+   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:  +1-847-576-2753
+   Fax:    +1-847-576-3240
+   EMail:  solomon@comm.mot.com
+
+
+   Steven Glass
+   FTP Software, Inc.
+   2 High Street
+   North Andover, MA  01845
+
+   Phone:  +1-508-685-4000
+   Fax:    +1-508-684-6105
+   EMail:  glass@ftp.com
+
+
+
+
+
+
+
+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]
+