diff options
Diffstat (limited to 'doc/rfc/rfc2290.txt')
| -rw-r--r-- | doc/rfc/rfc2290.txt | 955 |
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] + |