idnits 2.17.1 draft-ietf-pppext-ipcp-mip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1661], [RFC2002], [RFC1332]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 153: '..."The mobile node SHOULD first attempt ...' RFC 2119 keyword, line 159: '... node MAY register that address a...' RFC 2119 keyword, line 160: '... own IP address, that address MUST NOT...' RFC 2119 keyword, line 261: '... MUST NOT include an IP Address Opti...' RFC 2119 keyword, line 263: '... MAY include other options that do n...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 24, 1997) is 9894 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Extensions Working Group J. Solomon, Motorola 3 Internet Draft S. Glass, FTP Software 4 expires September 24, 1997 March 24, 1997 6 Mobile IPv4 Configuration Option for PPP IPCP 7 9 Status of this Memo 11 This document is a submission to the PPPEXT working group of the 12 IETF, having already reached consensus within the MOBILEIP working 13 group. Questions can be directed to the respective mailing lists: 14 ietf-ppp@merit.edu and mobile-ip@smallworks.com. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Distribution of this memo is unlimited. 34 Abstract 36 Mobile IP [RFC 2002] defines media-independent procedures by which a 37 Mobile Node can maintain existing transport and application-layer 38 connections despite changing its point-of-attachment to the Internet 39 and without changing its IP address. PPP [RFC 1661] provides a 40 standard method for transporting multi-protocol packets over point- 41 to-point links. As currently specified, Mobile IP Foreign Agents 42 which support Mobile Node connections via PPP can do so only by first 43 assigning unique addresses to those Mobile Nodes, defeating one of 44 the primary advantages of Foreign Agents. This documents corrects 45 this problem by defining the Mobile IPv4 Configuration Option to the 46 Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this 47 option, two peers can communicate their support for Mobile IP during 48 the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP 49 [RFC 1332], and PPP [RFC 1661] is assumed. 51 Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 2 55 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . 3 56 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Mobile IPv4 Configuration Option . . . . . . . . . . . . . . . 6 58 3. Additional Requirements . . . . . . . . . . . . . . . . . . . 9 59 3.1. Other IPCP Options . . . . . . . . . . . . . . . . . . . 9 60 3.2. Move Detection . . . . . . . . . . . . . . . . . . . . . 9 61 4. Supported Scenarios . . . . . . . . . . . . . . . . . . . . . 10 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 65 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 67 1. Introduction 69 Mobile IP [RFC 2002] defines protocols and procedures by which 70 packets can be routed to a mobile node, regardless of its current 71 point-of-attachment to the Internet, and without changing its IP 72 address. Mobile IP is designed to run over any type of media and any 73 type of data link-layer. However, the interaction between Mobile IP 74 and PPP is currently underspecified and generally results in an 75 inappropriate application of Mobile IP when mobile nodes connect to 76 the Internet via PPP. 78 This document defines proper interaction between a mobile node [RFC 79 2002] and a dialup server through which the mobile node connects to 80 the Internet using PPP. This requires the definition of a new option 81 for IPCP [RFC 1332], named the "Mobile IPv4 Configuration Option", 82 which is defined in this document. The mobile node and the dialup 83 server use this option to negotiate the appropriate use of Mobile IP 84 over the PPP link. 86 1.1. Terminology 88 This document uses the following terms as defined in [RFC 2002]: 90 Mobile Node 92 A host or router that changes its point of attachment from one 93 network or subnetwork to another. A mobile node may change its 94 location without changing its IP address; it may continue to 95 communicate with other Internet nodes at any location using its 96 (constant) IP address, assuming link-layer connectivity to a 97 point of attachment is available. 99 Home Agent 101 A router on a mobile node's home network which tunnels 102 datagrams for delivery to the mobile node when it is away from 103 home, and maintains current location information for the mobile 104 node. 106 Foreign Agent 108 A router on a mobile node's visited network which provides 109 routing services to the mobile node while registered. The 110 foreign agent detunnels and delivers datagrams to the mobile 111 node that were tunneled by the mobile node's home agent. For 112 datagrams sent by a mobile node, the foreign agent may serve as 113 a default router for registered mobile nodes. 115 Dialup Server 117 The PPP peer of a mobile node. A dialup server might support 118 home agent functionality, foreign agent functionality, both, or 119 neither. 121 1.2. Problem Statement 123 In Mobile IP, packets sent to a mobile node's home address are routed 124 first to the mobile node's home agent, a router on the mobile node's 125 home link which intercepts packets sent to the home address. The 126 home agent then tunnels such packets to the mobile node's care-of 127 address, where the packets are extracted from the tunnel and 128 delivered to the mobile node. There are two types of care-of 129 addresses: 131 Co-located Care-of Address 133 An address temporarily assigned to a mobile node itself. In 134 this case, the mobile node is the exit-point of the tunnel and 135 decapsulates packets encapsulated for delivery by its home 136 agent. 138 Foreign Agent Care-of Address 140 An address of a foreign agent that has at least one interface 141 on a mobile node's visited link. In this case, the foreign 142 agent decapsulates packets that have been tunneled by the home 143 agent and delivers them to the mobile node over the visited 144 link. 146 In Appendix B, Mobile IP [RFC 2002] currently specifies only the 147 following with respect to PPP: 149 "The Point-to-Point-Protocol (PPP) [RFC 1661] and its Internet 150 Protocol Control Protocol (IPCP) [RFC 1332], negotiates the use of 151 IP addresses. 153 "The mobile node SHOULD first attempt to specify its home address, 154 so that if the mobile node is attaching to its home network, the 155 unrouted link will function correctly. When the home address is 156 not accepted by the peer, but a transient IP address is 157 dynamically assigned to the mobile node, and the mobile node is 158 capable of supporting a co-located care-of address, the mobile 159 node MAY register that address as a co-located care-of address. 160 When the peer specifies its own IP address, that address MUST NOT 161 be assumed to be a foreign agent care-of address or the IP address 162 of a home agent." 164 Inspection of this text reveals that there is currently no way for 165 the mobile node to use a foreign agent care-of address, without first 166 being assigned a unique IP address, even if the dialup server also 167 supports foreign agent functionality. The reason for this can be 168 seen by walking through the IPCP negotiation: 170 1. A mobile node calls a dialup server and proposes its home address 171 in IPCP's "IP Address" option. 173 2. The dialup server has no way of knowing whether this is: (a) a 174 mobile node proposing its home address; or (b) a conventional node 175 proposing a non-routable address. In this case, the dialup server 176 must (conservatively) Nak the IP address option. 178 3. The mobile node, in turn, has no way of knowing whether its home 179 address was Nak'ed because the peer is a foreign agent being 180 conservative, or because the peer does not implement Mobile IP at 181 all. Therefore, the mobile node must (conservatively) assume that 182 the peer does not implement Mobile IP and continue the negotiation 183 of an IP address in IPCP, after which point the mobile node can 184 use the assigned address as a co-located care-of address. 186 Here we observe that, even if the dialup server is a foreign agent 187 and sends an Agent Advertisement to the mobile node after IPCP 188 completes, the mobile node will still have negotiated a routable 189 address in step 3 which it is likely already using as a co-located 190 care-of address. This defeats the purpose of foreign agent care-of 191 addresses, which are designed to be shared by multiple mobile nodes 192 and to eliminate the need to assign a unique address to each mobile 193 node. 195 1.3. Requirements 197 The purpose of this document is to specify the behavior of both ends 198 of the PPP link when one or more of the PPP peers supports Mobile IP. 199 Specifically, the design of the option and protocol defined in this 200 document is based upon the following requirements: 202 1. The option and protocol described in this document must be 203 backwards compatible with conventional nodes and dialup servers 204 which do not implement this option nor any Mobile IP 205 functionality. 207 2. The option and protocol described in this document must 208 accommodate a variety of scenarios, minimally those identified in 209 Section 4. 211 3. A unique address must not be assigned to a mobile node unless 212 absolutely necessary. Specifically, no such address is assigned 213 to a mobile node that connects via PPP to its home link or a 214 mobile node that connects via PPP to a foreign agent (and uses 215 that foreign agent's care-of address). 217 2. Mobile IPv4 Configuration Option 219 The Mobile IPv4 Configuration Option for IPCP is defined as follows: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length |D| reserved1 |C|H| reserved2 | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Mobile Node's Home Address | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Assigned Co-Located Care-Of Address | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Type 137 (Mobile IPv4 Configuration Option) 233 Length 12 (The length of this entire extension in bytes) 235 D 1, if the Mobile Node wants a Dynamically assigned, 236 co-located care-of address, 0 otherwise. 238 reserved1 sent as 0, ignored on reception 240 C 1, if the dialup server Cannot fulfill the mobile 241 node's request to be dynamically assigned a 242 co-located care-of address, 0 otherwise. 244 H 1, if the PPP interface of the dialup server is a 245 neighbor of the mobile node's home address on the 246 home link, 0 otherwise. 248 reserved2 sent as 0, ignored on reception 250 Mobile Node's Home Address 251 The IP home address of the mobile node sending the 252 Mobile IPv4 Configuration Option. 254 Assigned Co-Located Care-of Address 255 A place-holder for the dynamically assigned 256 co-located care-of address. Ignored if the 'D' bit 257 is 0. 259 The option works as follows. A mobile node includes the Mobile IPv4 260 Configuration Option in a Configure-Request of IPCP. A mobile node 261 MUST NOT include an IP Address Option (nor the deprecated IP- 262 Addresses Option) along with the Mobile IPv4 Configuration Option but 263 MAY include other options that do not involve negotiation of an IP 264 address (see section 3.1). 266 The mobile node MUST set the 'D' bit to 1 if it wants to be assigned 267 a co-located care-of address, otherwise it MUST set the 'D' bit to 0. 268 The mobile node SHOULD set all other fields and bits to 0, except for 269 the "Mobile Node's Home Address" field in which it MUST place its IP 270 home address. 272 The response generated at the other end of the PPP link depends upon 273 the identity and the capabilities of the PPP peer (for simplicity, we 274 call this peer a "dialup server"). Several cases are described as 275 follows, which assume that the dialup server has received a 276 Configure-Request from the mobile node containing a Mobile IPv4 277 Configuration Option: 279 1. If the Mobile IPv4 Configuration Option is not recognizable or is 280 not acceptable for negotiation (as configured by a network 281 administrator), then the dialup server MUST respond by sending a 282 Configure-Reject, as described in [RFC 1661]. A mobile node that 283 receives such a Configure-Reject MAY proceed with IPCP negotiation 284 using the IP Address Option [RFC 1332] instead of the Mobile IPv4 285 Configuration Option. The address so negotiated MAY be used by 286 the mobile node as a co-located care-of address. 288 If, instead, the Mobile IPv4 Configuration Option is recognizable 289 and is acceptable for negotiation, then the dialup server MUST 290 respond with either a Configure-Ack or a Configure-Nak, depending 291 upon the acceptability of the specific values contained within the 292 Mobile IPv4 Configuration Option. Each such case is described 293 below where, due to the recognizability of the Mobile IPv4 294 Configuration Option, we assume that the dialup server is either a 295 home agent, a foreign agent, or both. 297 2. If the dialup server is a bridge with one interface on the mobile 298 node's home network or if the dialup server is a router whose 299 address on its PPP interface is a neighbor to the mobile node's 300 home address (i.e., the mobile node is connecting to its home 301 link), then the dialup server sends a Configure-Nak in which it 302 sets the 'H' bit to 1 and leaves all other fields unmodified. A 303 mobile node receiving this Configure-Nak MUST respond by sending a 304 new Configure-Request (containing the Mobile IPv4 Configuration 305 Option) with D=0, C=0, H=1, Mobile Node's Home Address field set 306 to the mobile node's IP home address, and the Assigned Co-Located 307 Care-of Address field set to 0. The dialup server will 308 subsequently send a Configure-Ack in response to this new 309 Configure-Request and IPCP will complete. The mobile node is not 310 required to wait for an Agent Advertisement before de-registering 311 with its home agent. 313 All the remaining cases assume that the dialup server is a foreign 314 agent to the mobile node and specifically not connected to the 315 mobile node's home link (as determined by the Mobile Node's Home 316 Address field). 318 3. If the mobile node set the 'D' bit to 1, if the Assigned Co- 319 Located Care-of Address is set to a value never previously 320 assigned to this mobile node (e.g., 0.0.0.0), and if the foreign 321 agent is capable of assigning an address, then the foreign agent 322 MUST respond with a Configure-Nak in which a newly assigned co- 323 located care-of address is placed in the Assigned Co-Located 324 Care-of Address field and all other fields are left unmodified. A 325 mobile node receiving such a Configure-Nak MUST respond by sending 326 a new Configure-Request containing a Mobile IPv4 Configuration 327 Option copied without modification from this received Configure- 328 Nak. The foreign agent MUST respond to this new Configure-Request 329 with a Configure-Ack. 331 As specified in [RFC 1661] and [RFC 1332], a mobile node MUST 332 receive such a Configure-Ack before it can consider IPCP to be 333 completed and therefore that it may use the assigned address as a 334 co-located care-of address. In addition, the mobile node MUST (!) 335 wait for an Agent Advertisement before registering this co-located 336 care-of address. This is because the foreign agent might set the 337 'R' Bit in its Agent Advertisements (see [RFC 2002]) which forces 338 the mobile node to register via the foreign agent, even when using 339 a co-located care-of address. Accordingly, the foreign agent MUST 340 send an Agent Advertisement over a PPP link immediately after IPCP 341 for that link enters the Opened state. 343 4. If the mobile node set the 'D' bit to 1, and if the Assigned Co- 344 Located Care-of Address is set to a value previously assigned to 345 this mobile node by this foreign agent (i.e., as assigned in case 346 #3 above), then the foreign agent MUST respond with a Configure- 347 Ack and IPCP completes. The mobile node MUST (!) wait for an 348 Agent Advertisement from the foreign agent before registering. 349 This is because the foreign agent might set the 'R' Bit in its 350 Agent Advertisements (see RFC 2002) which forces the mobile node 351 to register via the foreign agent, even when using a co-located 352 care-of address. Accordingly, the foreign agent MUST send an 353 Agent Advertisement over a PPP link immediately after IPCP for 354 that link enters the Opened state. 356 5. If the mobile node set the 'D' bit to 1, and if the foreign agent 357 is *not* capable of assigning an address, then the foreign agent 358 MUST respond with a Configure-Nak in which the 'C' bit is set to 1 359 and all other fields are left unmodified. The mobile node must 360 now either give up and try to find a dialup server that can assign 361 an address, or proceed to use a foreign agent care-of address. In 362 the latter case, the mobile node sends a new Configure-Request 363 containing the Mobile IPv4 Configuration Option with the 'D' bit 364 set to 0, as described in item #6 below. 366 6. If the mobile node set the 'D' bit to 0, then the foreign agent 367 MUST return the option unmodified in a Configure-Ack and IPCP 368 completes. The mobile node MUST wait for an Agent Advertisement 369 from the foreign agent before registering. Accordingly, the 370 foreign agent MUST send an Agent Advertisement over a PPP link 371 immediately after IPCP for that link enters the Opened state. 373 The design and semantics of the Mobile IPv4 Configuration Option are 374 therefore optimized for the case of a mobile node making use of a 375 foreign agent's care-of address. The negotiation takes only one 376 round-trip in this case. 378 3. Additional Requirements 380 3.1. Other IPCP Options 382 Although a mobile node MUST NOT include an IP Address Option (nor the 383 deprecated IP-Addresses Option) in any Configure-Request that 384 contains a Mobile IPv4 Configuration Option, the mobile node MAY 385 include an IP-Compression-Protocol Option or any other option that 386 does not involve the negotiation of an IP address. If a mobile node 387 and a foreign agent or home agent agree in IPCP to use Van Jacobson 388 Header Compression [RFC 1144], then the mobile node MUST NOT set the 389 'V' bit in its ensuing, Mobile IP Registration Request [RFC 2002]. 391 3.2. Move Detection 393 Mobile nodes that connect via PPP MUST correctly implement PPP's 394 IPCP, since movement by the mobile node will likely change its PPP 395 peer. Specifically, mobile nodes MUST be prepared to re-negotiate 396 IPCP at any time, including, the re-negotiation of the Mobile IPv4 397 Configuration Option described in this document. 399 Also note that certain wireless links can employ handoff and proxying 400 mechanisms that would not necessarily require bringing down a PPP 401 link but would indeed require a mobile node to register with a new 402 foreign agent. Therefore, mobile nodes which connect to an agent via 403 PPP MUST employ their move detection algorithms (see section 2.4.2 in 405 [RFC 2002]) and register whenever they detect a change in 406 connectivity. 408 Specifically, a mobile node that fails to receive an Agent 409 Advertisement within the Lifetime advertised by its current foreign 410 agent, MUST assume that it has lost contact with that foreign agent 411 (see Section 2.4.2.1, [RFC 2002]). If, in the mean time, the mobile 412 node has received Agent Advertisements from another foreign agent, 413 the mobile node SHOULD immediately register with that foreign agent 414 upon timing out with its current foreign agent. 416 Likewise, a mobile node that implements move detection based upon the 417 Prefix-Length Extension MUST compare the prefix of any advertising 418 agents with that of its current foreign agent (see Section 2.4.2.2, 419 [RFC 2002]). If such a mobile node receives an Agent Advertisement 420 from a foreign agent specifying a different prefix than that of its 421 current foreign agent, then the mobile node that employs this method 422 of move detection MUST register with that new foreign agent. 424 A mobile node MAY treat PPP link-establishment as a sufficient reason 425 to proceed with a new Mobile IP registration. Section 2 defines the 426 circumstances under which mobile nodes MUST wait for an Agent 427 Advertisement before registering. Accordingly, foreign agents and 428 home agents MUST send an Agent Advertisement over a PPP link 429 immediately after IPCP for that link enters the Opened state. 431 4. Supported Scenarios 433 The Mobile IPv4 Configuration Option is designed to accommodate the 434 following scenarios. This section also helps to illustrate the use 435 of the option and the protocol specified above. 437 In the scenarios which follow, the direction of message flow is 438 indicated along with the type of IPCP message and the contents of the 439 appropriate option. "MN" refers to the mobile node and "dialup" 440 refers to the PPP peer to which the mobile node connects. 442 For sake of brevity, the Type, Length, Reserved, and Mobile Node's 443 Home Address fields have been omitted from the Mobile IPv4 444 Configuration Option below because these fields are always set to 445 their obvious values. Finally, the Assigned Co-Located Care-Of 446 Address field is designated by "IPcol-coa". 448 A. A mobile node wants to use a co-located care-of address and the 449 dialup server is a foreign agent that is capable of assigning such 450 an address: 452 [ From -> To ] PPP Message Type Mobile IPv4 Configuration Option 453 ============== ================= ================================ 454 [MN -> dialup] Configure-Request {D=1,C=0,H=0,IPcol-coa=0.0.0.0} 455 [dialup -> MN] Configure-Nak {D=1,C=0,H=0,IPcol-coa=new-coa} 456 [MN -> dialup] Configure-Request {D=1,C=0,H=0,IPcol-coa=new-coa} 457 [dialup -> MN] Configure-Ack {D=1,C=0,H=0,IPcol-coa=new-coa} 459 - Mobile node waits to receive an Agent Advertisement. 460 - If (Advertisement has R-bit set) then 461 Mobile node registers with co-located care-of address via the 462 foreign agent; 463 else 464 Mobile node registers with co-located care-of address directly 465 with its home agent. 467 B. A mobile node wants to use a co-located care-of address and the 468 dialup server is a foreign agent. The foreign agent cannot assign 469 a co-located care-of address (e.g., it has no pool of addresses 470 from which to allocate for the purposes of assignment): 472 [ From -> To ] PPP Message Type Mobile IPv4 Configuration Option 473 ============== ================= ================================ 474 [MN -> dialup] Configure-Request {D=1,C=0,H=0,IPcol-coa=0.0.0.0} 475 [dialup -> MN] Configure-Nak {D=1,C=1,H=0,IPcol-coa=0.0.0.0} 477 The mobile node has two options: either proceed to use this 478 foreign agent's care-of address or disconnect and try to find a 479 different dialup server which can fulfill the request for a co- 480 located care-of address. In the former case, IPCP continues as 481 follows: 483 [ From -> To ] PPP Message Type Mobile IPv4 Configuration Option 484 ============== ================= ================================ 485 [MN -> dialup] Configure-Request {D=0,C=0,H=0,IPcol-coa=0.0.0.0} 486 [dialup -> MN] Configure-Ack {D=0,C=0,H=0,IPcol-coa=0.0.0.0} 488 - IPCP completes. 489 - Mobile node waits to receive an Agent Advertisement. 490 - Mobile node registers with its home agent via the foreign agent. 492 C. A mobile node wants to use a foreign agent care-of address and the 493 dialup server is a foreign agent which finds this state of affairs 494 satisfactory: 496 [ From -> To ] PPP Message Type Mobile IPv4 Configuration Option 497 ============== ================= ================================ 498 [MN -> dialup] Configure-Request {D=0,C=0,H=0,IPcol-coa=0.0.0.0} 499 [dialup -> MN] Configure-Ack {D=0,C=0,H=0,IPcol-coa=0.0.0.0} 501 - IPCP completes. 502 - Mobile node waits to receive an Agent Advertisement. 503 - Mobile node registers with its home agent via the foreign agent. 505 D. A mobile node connects to a dialup server which is connected to 506 the mobile node's home link (for this scenario, it does not matter 507 whether the mobile node wishes to use a co-located care-of address 508 or a foreign agent care-of address). The dialup server informs 509 the mobile node that it is connected to its home link as follows 510 (the notation "D=x" implies a "don't care" condition): 512 [ From -> To ] PPP Message Type Mobile IPv4 Configuration Option 513 ============== ================= ================================ 514 [MN -> dialup] Configure-Request {D=x,C=0,H=0,IPcol-coa=0.0.0.0} 515 [dialup -> MN] Configure-Nak {D=x,C=0,H=1,IPcol-coa=0.0.0.0} 516 [MN -> dialup] Configure-Request {D=0,C=0,H=1,IPcol-coa=0.0.0.0} 517 [dialup -> MN] Configure-Ack {D=0,C=0,H=1,IPcol-coa=0.0.0.0} 519 - IPCP completes. 520 - Mobile node de-registers with its home agent. 522 E. A mobile node wants to use either type of care-of address and the 523 dialup server does not implement the Mobile IPv4 Configuration 524 Option. The server rejects the option as follows (the notation 525 "D=x" implies a "don't care" condition): 527 [ From -> To ] PPP Message Type Mobile IPv4 Configuration Option 528 ============== ================= ================================ 529 [MN -> dialup] Configure-Request {D=x,C=0,H=0,IPcol-coa=0.0.0.0} 530 [dialup -> MN] Configure-Reject {D=x,C=0,H=0,IPcol-coa=0.0.0.0} 532 At this point, the mobile node can use the IP Address Option [RFC 533 1332] to negotiate an address which it can subsequently use as a 534 co-located care-of address: 536 [ From -> To ] PPP Message Type ***IP Address Option*** 537 ============== ================= =============================== 538 [MN -> dialup] Configure-Request {IPaddress = 0.0.0.0} 539 [dialup -> MN] Configure-Nak {IPaddress = assigned-address} 540 [MN -> dialup] Configure-Request {IPaddress = assigned-address} 541 [dialup -> MN] Configure-Ack {IPaddress = assigned-address} 543 - IPCP completes. 544 - Mobile node registers "IPaddress" as a co-located care-of address 545 with its home agent. 547 5. Security Considerations 549 This document introduces no known security threats over and above 550 those facing any node on the Internet that either connects via PPP or 551 implements Mobile IP or both. Specifically, service providers should 552 use cryptographically strong authentication (e.g., CHAP [RFC 1994]) 553 to prevent theft-of-service. Additionally, users requiring 554 confidentiality should use PPP link encryption [RFC 1968], IP-layer 555 encryption [RFC 1827], or application-layer encryption, depending 556 upon their individual requirements. Finally, Mobile IP 557 authentication [RFC 2002] protects against trivial denial-of-service 558 attacks that could otherwise be waged against a mobile node and its 559 home agent. 561 6. References 563 [RFC 1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed 564 Serial Links", RFC 1144, January 1990. 566 [RFC 1332] McGregor, G., "The PPP Internet Protocol Control Protocol 567 (IPCP)," RFC 1332, May 1992. 569 [RFC 1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) 570 for the Transmission of Multi-protocol Datagrams over Point-to- 571 Point Links," RFC 1661, July 1994. 573 [RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 574 RFC 1827, August 1995. 576 [RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication 577 Protocol (CHAP)", RFC 1994, August 1996. 579 [RFC 1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", 580 RFC 1968, June 1996. 582 [RFC 2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002, 583 October 1996. 585 7. Acknowledgments 587 The design of this protocol and option were inspired by an earlier 588 submission by B. Patel and C. Perkins, then of IBM, in draft-patel- 589 mobileip-pppext-00.txt, which has since expired. Tim Wilson and 590 Chris Stanaway of Motorola contributed significantly to the design of 591 this configuration option and protocol specification. 593 Also, some of William Simpson's text was copied verbatim from [RFC 594 1661] in order to ensure consistency of terminology and 595 specification. The same goes for Charlie Perkins' text, including 596 definitions, from [RFC 2002]. 598 8. Authors' Addresses 600 Questions about this memo can be directed to: 602 Jim Solomon 603 Motorola, Inc. 604 1301 E. Algonquin Rd. - Rm 2240 605 Schaumburg, IL 60196 607 Voice: +1-847-576-2753 608 Fax: +1-847-576-3240 609 E-Mail: solomon@comm.mot.com 611 Steven Glass 612 FTP Software, Inc. 613 2 High Street 614 North Andover, MA 01845 616 Voice: +1-508-685-4000 617 Fax: +1-508-684-6105 618 E-mail: glass@ftp.com