idnits 2.17.1 draft-ietf-mobileip-protocol-13.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-19) 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 are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 485: '... MUST This word, or...' RFC 2119 keyword, line 489: '... MUST NOT This phrase m...' RFC 2119 keyword, line 492: '... SHOULD This word, or...' RFC 2119 keyword, line 500: '... MAY This word, or...' RFC 2119 keyword, line 503: '...nclude this option MUST be prepared to...' (213 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 (22 November 1995) is 10376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1826 (ref. '2') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1541 (ref. '8') (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1750 (ref. '9') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '10') ** Obsolete normative reference: RFC 1573 (ref. '12') (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1305 (ref. '14') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' ** Obsolete normative reference: RFC 1700 (ref. '20') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '21') Summary: 17 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins, editor 2 INTERNET DRAFT IBM 3 22 November 1995 5 IP Mobility Support 6 draft-ietf-mobileip-protocol-13.txt 8 Status of This Memo 10 This document is a submission by the Mobile-IP Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the mobile-ip@tadpole.com mailing list. 14 Distribution of this memo is unlimited. 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 23 any 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 28 Shadow 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 Abstract 34 This document specifies protocol enhancements that allow transparent 35 routing of IP datagrams to mobile nodes in the Internet. Each 36 mobile node is always identified by its home address, regardless of 37 its current point of attachment to the Internet. While situated 38 away from its home, a mobile node is also associated with a 39 care-of address, which provides information about its current point 40 of attachment to the Internet. The protocol provides for registering 41 the care-of address with a home agent. The home agent sends packets 42 destined for the mobile node through a tunnel to the care-of address. 43 After arriving at the end of the tunnel, the packets are then 44 delivered to the mobile node. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 53 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 1 54 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 2 57 1.5. New Architectural Entities . . . . . . . . . . . . . . . 3 58 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 60 1.8. Specification Language . . . . . . . . . . . . . . . . . 8 61 1.9. Message Format and Protocol Extensibility . . . . . . . . 9 63 2. Agent Discovery 11 64 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 11 65 2.1.1. Mobile Service Extension . . . . . . . . . . . . 13 66 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . 14 67 2.1.3. One-byte Padding Extension . . . . . . . . . . . 15 68 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 16 69 2.3. Foreign/Home Agent Considerations . . . . . . . . . . . . 16 70 2.3.1. Advertised Router Addresses . . . . . . . . . . . 17 71 2.3.2. Sequence Numbers, and Rollover Handling . . . . . 17 72 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 17 73 2.4.1. Registration Required . . . . . . . . . . . . . . 18 74 2.4.2. Move Detection . . . . . . . . . . . . . . . . . 18 75 2.4.3. Returning Home . . . . . . . . . . . . . . . . . 19 76 2.4.4. Sequence Numbers, and Rollover Handling . . . . . 19 78 3. Registration 20 79 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 20 80 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 21 81 3.3. Registration Request . . . . . . . . . . . . . . . . . . 21 82 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 23 83 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 26 84 3.5.1. Mobile-Home Authentication Extension . . . . . . 26 85 3.5.2. Mobile-Foreign Authentication Extension . . . . . 27 86 3.5.3. Foreign-Home Authentication Extension . . . . . . 27 87 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 28 88 3.6.1. Sending Registration Requests . . . . . . . . . . 29 89 3.6.2. Receiving Registration Replies . . . . . . . . . 32 90 3.6.3. Registration Retransmission . . . . . . . . . . . 34 91 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 34 92 3.7.1. Configuration and Registration Tables . . . . . . 35 93 3.7.2. Receiving Registration Requests . . . . . . . . . 35 94 3.7.3. Receiving Registration Replies . . . . . . . . . 37 95 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 39 96 3.8.1. Configuration and Registration Tables . . . . . . 39 97 3.8.2. Receiving Registration Requests . . . . . . . . . 39 98 3.8.3. Sending Registration Replies . . . . . . . . . . 42 100 4. Routing Considerations 44 101 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 45 102 4.2. Unicast Packet Routing . . . . . . . . . . . . . . . . . 45 103 4.2.1. Mobile Node Considerations . . . . . . . . . . . 45 104 4.2.2. Foreign Agent Considerations . . . . . . . . . . 46 105 4.2.3. Home Agent Considerations . . . . . . . . . . . . 46 106 4.3. Broadcast packets . . . . . . . . . . . . . . . . . . . . 47 107 4.4. Multicast Packet Routing . . . . . . . . . . . . . . . . 47 108 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 48 109 4.6. Gratuitous and Proxy ARP . . . . . . . . . . . . . . . . 49 111 5. Security Considerations 51 112 5.1. Message Authentication Codes . . . . . . . . . . . . . . 51 113 5.2. Areas of security concern in this protocol . . . . . . . 51 114 5.3. Key management . . . . . . . . . . . . . . . . . . . . . 51 115 5.4. Picking good random numbers . . . . . . . . . . . . . . . 52 116 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 52 117 5.6. Replay Protection for Registration Requests . . . . . . . 52 118 5.6.1. Replay Protection using Nonces . . . . . . . . . 53 119 5.6.2. Replay Protection using Timestamps . . . . . . . 54 121 6. Acknowledgements 54 123 A. Link-Layer considerations 55 124 A.1. Point-to-Point Link-Layers . . . . . . . . . . . . . . . 55 125 A.2. Multi-Point Link-Layers . . . . . . . . . . . . . . . . . 56 127 B. TCP Considerations 56 128 B.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 56 129 B.2. TCP Congestion Management . . . . . . . . . . . . . . . . 57 131 C. Example Scenarios 57 132 C.1. Registering with a Foreign Agent's Care-of Address . . . 57 133 C.2. Registering with a Dynamic Care-of Address . . . . . . . 58 134 C.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 58 136 D. Applicability of Prefix Lengths Extension 59 138 Chair's Address 62 140 Editor's Address 62 141 1. Introduction 143 IP version 4, like its predecessors, assumes that a node's IP address 144 uniquely identifies the node's point of attachment to the Internet. 145 Therefore, a node must be located on the network indicated by its 146 IP address in order to receive packets destined to it; otherwise, 147 packets destined to the node would be undeliverable. For a node 148 to change its point of attachment without losing its ability to 149 communicate, currently one of the two following mechanisms must 150 typically be employed: 152 a) the node must change its IP address whenever it changes its 153 point of attachment, or 155 b) host-specific routes must be propagated throughout much of 156 the Internet routing fabric. 158 Both of these alternatives are often unacceptable. The first makes 159 it impossible for a node to maintain transport and higher-layer 160 connections when the node changes location. The second has obvious 161 and severe scaling problems, especially relevant considering the 162 explosive growth in sales of notebook computers. 164 A new, scalable, mechanism is evidently required to accommodate node 165 mobility within the Internet. This document defines such a mechanism 166 and enables nodes to change their point of attachment to the Internet 167 without changing their IP address. 169 1.1. Protocol Requirements 171 Implementation of the protocol described in this document shall allow 172 a mobile node to communicate with other nodes after changing its 173 point of physical attachment to the Internet, yet without changing 174 its IP address. 176 Implementation of the protocol described in this document shall allow 177 a mobile node to communicate with other nodes that do not implement 178 these mobility functions. No protocol enhancements are required 179 in hosts or routers that are not providing any of the mobility 180 functions. 182 Messages used by this protocol which exchange location information 183 must be authenticated in order to protect against remote redirection 184 attacks. 186 1.2. Goals 188 The link by which the mobile node is directly attached to the 189 Internet is likely to be bandwidth limited, and experience a higher 190 rate of errors than traditional wired networks. Moreover, mobile 191 nodes are more likely to be battery powered, and minimizing power 192 consumption is important. Therefore, only a few administrative 193 messages should be sent between a mobile node and an agent, and the 194 size of these messages should be kept as short as is reasonably 195 possible. 197 1.3. Assumptions 199 The protocols defined in this document place no additional 200 constraints on assignment of IP addresses. That is, a mobile node 201 can be assigned an IP address by the organization that owns the 202 machine, and will be able to use that IP address regardless of the 203 current point of attachment. 205 It is assumed that mobile nodes will not change their point of 206 attachment to the Internet more frequently than once per second. 208 It is assumed that IP unicast datagrams are routed based on the 209 destination address in the datagram header (i.e., not by source 210 address). 212 1.4. Applicability 214 Mobile IP is intended to solve node mobility across changes in IP 215 subnet. It is just as suitable for mobility across homogeneous media 216 as it is for mobility across heterogeneous media. That is, Mobile 217 IP facilitates node movement from one Ethernet segment to another as 218 well as it accommodates node movement from an Ethernet segment to a 219 wireless LAN, as long as the mobile node's IP address remains the 220 same after such a movement. 222 One can think of Mobile IP as solving the "macro" mobility management 223 problem. It is less well suited for more "micro" mobility management 224 applications -- for example, handoff amongst wireless transceivers, 225 each of which covers only a very small geographic area. In this 226 later situation, link-layer mechanisms for link maintenance (i.e. 227 link-layer handoff) may offer faster convergence and far less 228 overhead than Mobile IP. 230 1.5. New Architectural Entities 232 Mobile IP introduces these new functional entities: 234 Mobile Node 236 A host or router that changes its point of attachment from one 237 network or subnetwork to another. 239 Home Agent 241 A router on a mobile node's home network which tunnels packets 242 for delivery to the mobile node when it is away from home, and 243 maintains current location information for the mobile node, 245 Foreign Agent 247 A router that assists a locally reachable mobile node that is 248 away from its home network, by detunneling and delivering those 249 packets to the mobile node that were tunneled by the mobile 250 node's home agent. 252 A mobile node is given a long-term IP address on a home network. 253 This home address is administered in much the same way as "permanent" 254 IP addresses are provided to stationary hosts. When away from its 255 home network, the "care-of address" associated with the mobile node 256 reflects the mobile node's current point of attachment. The mobile 257 node creates new network connections with existing Internet hosts 258 using its home address. 260 1.6. Terminology 262 This document frequently uses the following terms: 264 Agent Advertisement 266 A periodic advertisement constructed by attaching a special 267 extension to a router advertisement [7] message. 269 Care-of Address 271 The care-of address is the termination point of a tunnel toward 272 a mobile node that is away from its home network. Depending 273 on the configuration, the care-of address can be either an 274 address of a foreign agent or a temporary address acquired by 275 the mobile node. 277 Correspondent 279 A peer with which a mobile node is communicating. The 280 correspondent may be either mobile or stationary. 282 Foreign Network 284 Any network other than the mobile node's Home Network. 286 Home Address 288 An IP address that is assigned for an extended period of time 289 to a mobile node. It remains unchanged regardless of where the 290 node is attached to the Internet. 292 Home Network 294 A network, possibly virtual, having a network prefix identical 295 to that of a mobile node's home address. Note that standard IP 296 routing mechanisms will deliver packets destined to a mobile 297 node's home address to the mobile node's home network. 299 Link 301 A facility or medium over which nodes can communicate at the 302 link layer. A link underlies the network layer. 304 Link-Layer Address 306 The address used to identify the endpoints of the communication 307 over a physical link. Typically, the Link-Layer address is an 308 interface's Media Access Control (MAC) address. 310 Mobility Agent 312 Either a home agent or a foreign agent. 314 Mobility Binding 316 The association of a home address with a care-of address, along 317 with the remaining lifetime of that association. 319 Mobility Security Association 321 The mobility security association between a pair of nodes 322 is a collection of security contexts which may be applied 323 to Mobile IP protocol messages exchanged by them. Each 324 context indicates an authentication algorithm and mode 325 (subsection 5.1), a secret (a shared key, or appropriate 326 public/private key pair), and a style of replay protection in 327 use (subsection 5.6). 329 Node 331 A host or a router. 333 Nonce 335 A random value, different from previous choices, inserted in a 336 packet to protect against replays. 338 Security Parameter Index (SPI) 340 The SPI[2] indicates the security context between a pair 341 of nodes among those available in the Mobility Security 342 Association. 344 Tunnel 346 The path followed by a packet while it is encapsulated. The 347 model is that, while it is encapsulated, a packet is routed 348 to a knowledgeable decapsulating agent, which decapsulates 349 the packet and then correctly delivers it to its ultimate 350 destination. 352 Visited Network 354 A network other than a mobile node's Home Network to which the 355 mobile node is currently connected. 357 Visitor List 359 The list of mobile nodes visiting a foreign agent. 361 1.7. Protocol Overview 363 The following support services are defined for Mobile IP: 365 Agent Discovery 367 Home agents and foreign agents may advertise their availability 368 on each link for which they provide service. A newly arrived 369 mobile node can send a solicitation on the link to learn if any 370 prospective agents are present. 372 Registration 374 When the mobile node is away from home, it registers its 375 care-of address with its home agent. Depending on its method 376 of attachment, the mobile node will register either directly 377 with its home agent, or through a foreign agent which forwards 378 the registration to the home agent. 380 The following is a rough outline of the mobile-IP protocol: 382 - Foreign agents and home agents advertise their presence via Agent 383 Agent Advertisements (see section 2). 385 - A mobile node receives these advertisements and determines 386 whether it is on its home network or a foreign network. 388 - When the mobile node detects that it is located on its home 389 network, it operates without mobility services. 391 - When mobile node detects that it has moved to a foreign network, 392 it obtains a care-of address on the foreign network. The 393 care-of address can either be determined from a foreign agent's 394 advertisements, or by some assignment mechanism (for example, 395 DHCP [8]). 397 - The mobile node then registers its new care-of address with its 398 home agent, possibly via a foreign agent (see section 3). 400 - Packets sent to the mobile node's Home Address are received 401 by the home agent, tunneled by the home agent to the care-of 402 address, received at the tunnel endpoint (either at a foreign 403 agent or at the mobile node itself), and finally delivered to the 404 mobile node (see subsection 4.2.3). 406 - In the reverse direction, packets originated by the mobile node 407 are typically delivered to their destination using standard IP 408 routing mechanisms, not necessarily passing through the home 409 agent. 411 When away from home, Mobile IP uses protocol tunneling to hide a 412 mobile node's home address from intervening routers between its home 413 network and its current location. The tunnel terminates at the 414 mobile node's care-of address -- an address to which packets can 415 be delivered via conventional IP routing. At the care-of address, 416 the original packet is removed from the tunnel and delivered to the 417 mobile node. 419 Mobile IP provides two distinct modes for the acquisition of a 420 care-of address: 422 a) A care-of address may be provided by a foreign agent. This 423 mode is preferred because it allows many mobile nodes to 424 share the same care-of address and therefore does not place 425 unnecessary demands on the already limited IPv4 address 426 space. In this mode, the foreign agent is the endpoint of 427 the tunnel and, upon receiving tunneled packets from the 428 mobile node's home agent, decapsulates them and delivers the 429 inner packet to the mobile node. 431 b) A care-of address may be dynamically acquired by, and owned 432 by, a mobile node when visiting a foreign network. The 433 method by which it obtains such an address is beyond the 434 scope of this document (but see, for example, DHCP [8]). 435 With its own care-of address, the mobile node itself performs 436 decapsulation of the packets tunneled by its home agent. 437 The attractiveness of this mode is that it allows a mobile 438 node to function without a foreign agent, for example, in 439 installations that have not yet deployed Mobile IP. It does, 440 however, place additional burden on the IPv4 address space 441 because it requires a pool of addresses to be made available 442 to visiting mobile nodes. 444 It is important to understand the distinction between the care-of 445 address and the foreign agent functions. The care-of address is 446 simply the endpoint of the tunnel. It might indeed be an address 447 of a foreign agent, but it also might be an address temporarily 448 acquired by the mobile node. On the other hand, a foreign agent 449 is a mobility agent that provides services to mobile nodes. See 450 subsections 3.7 and 4.2.2 for additional details. 452 ..................................................................... 453 : : 454 : 2) packet is received 3) packet is : 455 : by home agent and detunneled : 456 : is tunneled to the and delivered : 457 : care-of address to mobile node : 458 : : 459 : +-----+ +-------+ +------+ : 460 : |home | =======> |foreign| ------> |mobile| : 461 : |agent| | agent | <------ | node | : 462 : +-----+ +-------+ +------+ : 463 : 1) packet to /|\ / : 464 : mobile node | / 4) In the opposite direction, : 465 : arrives on | / standard IP routing delivers : 466 : home network | / the packet to its destination. : 467 : via standard | |_ In this figure, the foreign : 468 : IP routing. +----+ agent is the mobile node's : 469 : |host| default router. : 470 : +----+ : 471 : : 472 : Figure 1: Packet Delivery for Mobile Nodes Away from Home : 473 :...................................................................: 475 Figure one illustrates packet routing to/from a mobile node away from 476 home, once the mobile node has registered with its home agent. Shown 477 is the mode in which the care-of address is provided by a foreign 478 agent. 480 1.8. Specification Language 482 In this document, several words are used to signify the requirements 483 of the specification. These words are often capitalized. 485 MUST This word, or the adjective "required", means 486 that the definition is an absolute requirement 487 of the specification. 489 MUST NOT This phrase means that the definition is an 490 absolute prohibition of the specification. 492 SHOULD This word, or the adjective "recommended", 493 means that there may exist valid reasons in 494 particular circumstances to ignore this item, 495 but the full implications must be understood 496 and carefully weighed before choosing a 497 different course. Unexpected results may 498 result otherwise. 500 MAY This word, or the adjective "optional", means 501 that this item is one of an allowed set of 502 alternatives. An implementation which does 503 not include this option MUST be prepared to 504 interoperate with another implementation which 505 does include the option. 507 silently discard The implementation discards the packet without 508 further processing, and without indicating an 509 error to the sender. The implementation SHOULD 510 provide the capability of logging the error, 511 including the contents of the discarded packet, 512 and SHOULD record the event in a statistics 513 counter. 515 1.9. Message Format and Protocol Extensibility 517 Each message in Mobile IP begins with a short fixed part, followed 518 by one or more extensions in type-length-value format, with one 519 exception. That exception is the One-Byte Padding Extension which 520 has only a Type but no Length and no Data fields. These extensions 521 may be found in agent advertisement messages (subsection 2.1) or 522 registration messages (section 3). Each extension is described in 523 detail within the section of this document that it is applicable. 525 0 1 2 526 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 528 | Type | Length | Data ... 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 530 Type 532 Current values are assigned as follows: 534 16 Mobile Service 535 19 Prefix Lengths 536 32 Mobile-Home Authentication 537 33 Mobile-Foreign Authentication 538 34 Foreign-Home Authentication 540 Up-to-date values are specified in the most recent "Assigned 541 Numbers" [20]. 543 Length 545 Indicates the length (in bytes) of the data field. The length 546 does not include the Type and Length bytes. 548 Data 550 This field is zero or more bytes in length and contains the 551 value(s) for this extension. The format and length of the data 552 field is determined by the type and length fields. 554 Extensions allow variable amounts of information to be carried within 555 each datagram. The end of the list of extensions is indicated by the 556 total length of the IP datagram. 558 When an extension numbered in the range 0-127 is encountered but not 559 recognized, the packet containing the extension must be dropped. 560 When an extension numbered in the range 128-255 is encountered which 561 is not recognized, that particular extension is ignored, but the rest 562 of the extensions and packet data can still be processed. The length 563 field of the extension is used to skip the data field in searching 564 for the next extension. 566 2. Agent Discovery 568 Agent Discovery is the method by which a mobile node determines 569 whether it is currently connected to its home network or a foreign 570 network. When on a foreign network, the methods specified in this 571 section allow the mobile node to determine the care-of address being 572 offered by foreign agents on that network. 574 Mobile IP extends ICMP Router Discovery [7] as its primary mechanism 575 for Agent Discovery. An Agent Advertisement is formed by appending 576 one or more of the extensions defined in this section to an ICMP 577 Router Advertisement. An Agent Solicitation is identical to an ICMP 578 Router Solicitation. This section describes the message formats and 579 procedures by which mobile nodes, foreign agents, and home agents 580 cooperate to realize Agent Discovery. 582 Agent Advertisement and Agent Solicitation may not be necessary 583 for link layers which can provide this functionality already. The 584 method by which mobile nodes establish link-layer connection with 585 prospective agents is outside the scope of this document (but 586 see Appendix A. The procedures described below assume that such 587 link-layer connectivity has already been established. 589 No authentication is required for Agent Advertisement and Agent 590 Solicitation messages. They MAY be authenticated using the IP 591 Authentication Header [2], which is external to the messages 592 described here. Further specification of the way that advertisement 593 and solicitation messages are authenticated is outside of the scope 594 of this document. 596 2.1. Agent Advertisement 598 Agent Advertisements are periodic transmissions sent by a mobility 599 agent. Mobile nodes use these advertisements to determine their 600 current point of attachment to the Internet. Agent advertisements, 601 as specified in this document, are ICMP Router Advertisements 602 that have been modified to carry the Mobile Service Extension and, 603 optionally, the Prefix-Lengths Extension or future extensions that 604 might be defined. 606 The following fields within the ICMP Router Advertisement portion of 607 the Agent Advertisement are further refined as follows: 609 - Link Layer Fields 610 Destination Address 612 The link-layer destination address of a unicast Agent 613 Advertisement MUST be the same as the source link-layer 614 address of the Agent Solicitation which prompted the 615 Advertisement. 617 - IP Fields 619 TTL 621 The TTL for Agent Advertisements MUST be set to 1. 623 Destination Address 625 As per RFC1256 [7], the IP destination address of an Agent 626 Advertisement MUST be either the "all hosts" multicast 627 address (224.0.0.1) or the "Limited broadcast" address 628 (255.255.255.255). This is because subnet-directed 629 broadcast addresses of the form .<-1> are generally 630 useless to mobile nodes that are visiting foreign networks. 631 Such mobile nodes will have a different prefix than that of 632 the advertising agents. 634 - ICMP Fields 636 Code 638 The Code field of the agent advertisement is interpreted as 639 follows: 641 0 The mobility agent handles common traffic -- that 642 is, IP data packets not necessarily related to 643 mobile nodes. 645 16 The mobility agent does not route common traffic. 646 However, all foreign agents MUST minimally be 647 capable of forwarding to a default router those 648 packets received from a registered mobile node. 650 Lifetime 652 The maximum length of time that the Advertisement is 653 considered valid in the absence of further Advertisements. 654 The advertisement period SHOULD be 1/3 of the advertisement 655 Lifetime. This allows a mobile node to miss three 656 successive advertisements before deleting the agent from 657 its list of valid agents. Note that this field has no 658 relation whatsoever to the "Lifetime" field within the 659 Mobile Service Extension defined below. 661 Router Addresses 663 See subsection 2.3.1 for a discussion of the addresses that 664 may appear in this portion of the Agent Advertisement. 666 The ICMP fields are immediately followed by the Mobile Service 667 Extension defined in subsection 2.1.1. The Mobile Service 668 Extension MAY optionally be followed by the Prefix-Lengths 669 Extension (subsection 2.1.2), the One-byte Padding Extension 670 (subsection 2.1.3), or future extensions which might be defined. 672 2.1.1. Mobile Service Extension 674 The Mobile Service Extension immediately follows the ICMP Router 675 Advertisement fields. It is used to indicate that an ICMP Router 676 Advertisement message is actually an Agent Advertisement being sent 677 by a mobility agent. The Mobile Service Extension is defined as 678 follows: 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | Sequence Number | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Lifetime |R|B|H|F|M|G|V| reserved | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | zero or more Care-of Addresses | 688 | ... | 690 Type 16 692 Length (6 + 4*N), where N is the number of 693 care-of addresses advertised. 695 Sequence number The count of advertisement messages sent since 696 the agent was initialized (see section 2.3.2). 698 Lifetime The longest lifetime (measured in seconds) 699 that the agent is willing to accept in any 700 registration request. A value of all ones 701 indicates infinity. This field has nothing 702 whatsoever to do with the "Lifetime" field 703 within the ICMP Router Advertisement portion of 704 the Agent Advertisement described above. 706 R Foreign agent registration required bit. 708 B Busy bit. The foreign agent will not accept 709 more registrations. Only valid if F=1. 711 H Agent offers service as a home agent. 713 F Agent offers service as a foreign agent. 715 M Agent offers minimal encapsulation (see [16]). 717 G Agent offers GRE encapsulation (see [10]). 719 V Agent supports Van Jacobson header compression 720 [11] 722 reserved Sent as zero; ignored on reception. 724 Care of Address A foreign agent's care-of address(es). An Agent 725 Advertisement MUST include at least one care-of 726 address if F=1. 728 Any home agent MUST always be prepared to serve its mobile nodes. 729 Thus, it is an error to have the 'B' bit set without also having the 730 'F' bit set, since only foreign agents are permitted to be too busy 731 to service new requests. An agent MUST NOT send Agent Advertisements 732 with neither the 'F' bit nor the 'H' bit set to one. 734 When a foreign agent wishes to require registration even from those 735 mobile nodes which have acquired local, temporary care-of addresses, 736 it sets the 'R' bit to one. Because this applies only to foreign 737 agents, an agent MUST NOT set the 'R' bit to one unless the 'F' bit 738 is also set to one. 740 2.1.2. Prefix-Lengths Extension 742 The Prefix-Lengths Extension MAY follow the Mobile Service Extension. 743 It is used to indicate the number of bits of network prefix that 744 applies to each address listed in the ICMP Router Advertisement 745 portion of the Agent Advertisement. Note that the prefix lengths 746 DO NOT apply to care-of address(es) listed in the Mobile Service 747 Extension. The Prefix-Lengths Extension is defined as follows: 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Length | Prefix Length | .... 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Type 19 (Prefix-Lengths Extension) 757 Length The length of this extension excluding the 758 Type field and the Length field. This field 759 MUST equal N, where N is the value of the "Num 760 Addrs" field in the ICMP Router Advertisement 761 portion of the Agent Advertisement. 763 Prefix length(s) The number of leading bits which define the 764 network number of the corresponding router 765 address listed in the ICMP Router Advertisement 766 portion of the message. 768 See subsection 2.4.2 for information about how to use the Prefix 769 Lengths extension when determining whether movement has occurred. 770 See appendix D for implementation details about the use of this 771 extension. 773 2.1.3. One-byte Padding Extension 775 Some kernel implementations insist upon padding ICMP packets to an 776 even number of bytes. If the ICMP length of an Agent Advertisement 777 is odd, this extension MAY be included in order to make the ICMP 778 length even. Note that this extension is NOT intended to be 779 a general-purpose extension to be included in order to word or 780 long-align the various fields of the Agent Advertisement. In fact, 781 an Agent Advertisement SHOULD NOT include more than one One-byte 782 Padding Extension and this extension SHOULD be the last extension 783 present in an Agent Advertisement. NOTE the absence of both a 784 "Length" field and a "Data" field in the One-byte Pad Extension. 786 The One-byte Padding Extension is defined as follows: 788 0 1 2 3 4 5 6 7 789 +-+-+-+-+-+-+-+-+ 790 | Type | 791 +-+-+-+-+-+-+-+-+ 793 Type 0 (One-byte Padding Extension) 795 2.2. Agent Solicitation 797 An Agent Solicitation is identical to an ICMP Router Solicitation 798 with the further restriction that the IP TTL Field MUST be set to 1. 800 2.3. Foreign/Home Agent Considerations 802 Any mobility agent which is not indicated by a link-layer protocol 803 MUST send Agent Advertisements. An agent which is indicated by a 804 link-layer protocol SHOULD also implement Agent Advertisements. 805 However, the advertisements need not be sent, except when the site 806 policy requires registration with the agent (i.e. when the 'R' bit 807 is set), or as a response to a specific solicitation. All mobility 808 agents SHOULD respond to Agent Solicitations. 810 The same procedures, defaults, and constants are used in agent 811 advertisements as described in RFC 1256 [7], except that: 813 - a foreign agent MUST limit the rate at which it sends agent 814 advertisements; a recommended maximum rate is once per second, 815 AND 817 - a mobility agent that receives a Router Solicitation does not 818 require that the IP Source Address is the address of a neighbor 819 (i.e., an address that matches one of the router's own addresses 820 on the arrival interface, under the subnet mask associated with 821 that address.) 823 The home agent for a given mobile node SHOULD be located on the link 824 identified by the home address, if the home network is not merely a 825 virtual network. In this case, the home agent MUST send out agent 826 advertisements with the 'H' bit set, so that mobile nodes on their 827 home network will be able to determine that they are indeed at home. 829 On a particular subnet, either all mobility agents MUST include 830 the Prefix-Lengths Extension or all of them MUST NOT include this 831 extension. Equivalently, it is prohibited for some agents on a given 832 subnet to include the extension but for others not to include it. 833 Otherwise, one of the move detection algorithms designed for mobile 834 nodes will not function properly (see subsection 2.4.2). 836 2.3.1. Advertised Router Addresses 838 The ICMP Router Advertisement portion of the Agent Advertisement MAY 839 contain one or more router addresses. Thus, an agent may minimally 840 include one of its own addresses in the advertisement. A foreign 841 agent MAY discourage use of this address as a default router by 842 setting the preference to a low value and by including the address of 843 another router in the advertisement (with a correspondingly higher 844 preference). A foreign agent MUST minimally be able to forward 845 packets to a default router that are received from registered mobile 846 nodes (see subsection 4.2.2). 848 2.3.2. Sequence Numbers, and Rollover Handling 850 The sequence number in Agent Advertisements ranges from 0 to 851 0xffff. After booting, an agent shall use the number 0 for its first 852 advertisement. Each subsequent advertisement shall use the sequence 853 number one greater, with the exception that the sequence number 854 0xffff shall be followed by sequence number 256. In this way, mobile 855 nodes can distinguish reductions in sequence numbers that result from 856 reboots, from reductions that result in rollover of the sequence 857 number after it attains the value 0xffff. 859 2.4. Mobile Node Considerations 861 Every mobile node MUST implement Agent Solicitation. Solicitations 862 SHOULD only be sent in the absence of Agent Advertisements and when 863 a care-of address has not been determined through a link-layer 864 protocol or other means. The mobile node uses the same procedures, 865 defaults, and constants for Agent Solicitation as described in RFC 866 1256 for router solicitation, except that the mobile node may solicit 867 more often than once every three seconds and MAX_SOLICITATIONS does 868 not apply for mobile nodes that are currently unconnected to any 869 foreign agent. A mobile node MAY send a solicitation once each 870 MOBILE_SOLICITATION_INTERVAL (1 second) until the solicitation is 871 answered by a mobility agent, when the mobile node can finally issue 872 a Registration Request. 874 Mobile nodes must process Agent Advertisements. Mobile nodes 875 can distinguish Agent Advertisements from "standard" ICMP Router 876 Advertisements by examining the number of advertised addresses and 877 the IP Total Length field. When the IP total length indicates 878 that the ICMP message is longer than needed for the number of 879 advertised addresses, the remaining data is interpreted as one 880 or more extensions. The presence of a Mobile Service Extension 881 identifies the advertisement as an Agent Advertisement. 883 When multiple methods of agent identification are in use, the 884 mobile node SHOULD first attempt registration with agents including 885 Mobile Service Extensions in their advertisements in preference 886 to those sending link-layer advertisements. This order maximizes 887 the likelihood that the registration will be recognized, thereby 888 minimizing the number of registration attempts. 890 Other extensions MAY also be present in an Agent Advertisement, as 891 discussed in section 2.1. When an extension numbered in the range 892 0-127 is encountered but not recognized, the packet containing the 893 extension must be dropped. When an extension numbered in the range 894 128-255 is encountered which is not recognized, that particular 895 extension is ignored, but the rest of the extensions and packet data 896 can still be processed. The Length field of the extension is used to 897 skip the Data field in searching for the next extension. 899 2.4.1. Registration Required 901 When the mobile node receives an Agent Advertisement with the 'R' 902 bit set to 1, the mobile node SHOULD register through the foreign 903 agent, even when the mobile node might be able to acquire its own 904 temporary care-of address. This feature allows sites to enforce 905 visiting policies (such as accounting) which require exchanges of 906 authorization. 908 2.4.2. Move Detection 910 Two primary mechanisms are provided for mobile nodes to detect 911 movement from one subnet to another. Other mechanisms MAY be used. 912 When the mobile node detects that it has moved, it SHOULD register 913 (see section 3) with a suitable care-of address on the new foreign 914 network (but not too often -- see subsection 3.6.3). 916 The first method of move detection is based upon the Lifetime field 917 within the main body of the ICMP Router Advertisement portion of 918 the Agent Advertisement. A mobile node SHOULD record the Lifetime 919 received in any Agent Advertisements. If the mobile node fails 920 to receive another advertisement from the same agent within the 921 specified Lifetime, it SHOULD assume that it has lost contact with 922 the agent and therefore it SHOULD attempt to discover and then 923 register with other agents. 925 The second method uses network prefixes. The Prefix-Lengths 926 Extension MAY be used by mobile nodes to determine whether or not a 927 newly received Agent Advertisement was received on the same subnet as 928 the mobile node's current agent. If the prefixes differ, the mobile 929 node assumes that it has moved. A mobile node SHOULD NOT use this 930 method of move detection unless both the current agent and the new 931 agent include the Prefix-Lengths Extension in their respective Agent 932 Advertisements. If this extension is missing from one or both of the 933 advertisements, this method of move detection SHOULD NOT be used. 935 2.4.3. Returning Home 937 If the mobile node detects that it has moved to its home network, 938 it MUST deregister with its home agent (see section 3). Before 939 attempting to deregister, the mobile node SHOULD configure 940 its routing table appropriately for its home network (see 941 subsection 4.2.1) and, if the home network is using ARP, the mobile 942 node SHOULD send gratuitous ARPs on its behalf to clear out any 943 stale ARP entries in the ARP caches of nodes on the home network 944 (see section 4.6). This ordering allows the mobile node to resume 945 communications immediately upon returning home, rather than waiting 946 for its deregistration to complete. 948 2.4.4. Sequence Numbers, and Rollover Handling 950 If a mobile node detects two successive values of the sequence number 951 in the advertisements from its foreign agent, the second of which is 952 less than the first and inside the range 0 to 255, the mobile node 953 MUST register again. If the second value is less than the first, but 954 greater than or equal to 256, the mobile node may assume that the 955 sequence number has rolled over past its maximum value (0xffff), and 956 that there is no need to re-register (see subsection 2.3). 958 3. Registration 960 Mobile IP registration provides a flexible mechanism for mobile nodes 961 to communicate their current reachability information to their home 962 agent. It is the method by which mobile nodes: 964 - request forwarding services when visiting a foreign network, 965 - inform their home agent of their current care-of address, 966 - renew a registration which is due to expire, and/or 967 - deregister when they return home. 969 Registration messages exchange information between a mobile node, 970 (optionally) a foreign agent, and the home agent. Registration 971 creates or modifies a mobility binding at the home agent, associating 972 the mobile node's home address with its care-of address for the 973 specified Lifetime. 975 Several other (optional) capabilities are available through the 976 registration procedure, which enable a mobile node to: 978 - maintain multiple simultaneous registrations, wherein a copy of 979 each datagram will be tunneled to each active care-of addressm 981 - deregister specific care-of addresses while retaining other 982 mobility bindings, and 984 - discover the address of a home agent if the mobile node is not 985 configured with this information. 987 3.1. Registration Overview 989 If a mobile node acquires a dynamic care-of address, or if the mobile 990 node is returning home, the mobile node registers or deregisters 991 directly with a home agent by the exchange of only 2 messages: 993 a) The mobile node sends a registration request to a home agent, 994 asking it to provide service. 996 b) The home agent sends a registration reply to the mobile node, 997 granting or denying service. 999 When the care-of address is associated with a foreign agent, the 1000 mobile node MUST register via that foreign agent. If the mobile node 1001 receives an Agent Advertisements with the 'R' bit set, it SHOULD 1002 register via that foreign agent. In these cases, the foreign agent 1003 acts as a relay between the mobile node and the home agent. This 1004 extended registration process requires 4 messages: 1006 a) The mobile node sends a registration request to the 1007 prospective foreign agent to begin the registration process. 1009 b) The foreign agent relays the request to the home agent, 1010 asking the home agent to register the mobile node at the 1011 foreign agent's care-of address. 1013 c) The home agent sends a registration reply to the foreign 1014 agent to grant or deny service. 1016 d) The foreign agent relays the registration reply to the mobile 1017 node to inform it of the disposition of its request. 1019 The registration messages defined in subsections 3.3 and 3.4 use the 1020 User Datagram Protocol (UDP) header [18]. A nonzero UDP checksum 1021 SHOULD be included in the header, and checked by each recipient. 1023 3.2. Authentication 1025 Each mobile node, foreign agent, and home agent MUST be able to 1026 support a mobility security association for mobile entities, indexed 1027 by their IP address. See section 5.1 for requirements for support 1028 of authentication algorithms. Registration messages between mobile 1029 node and home agent MUST be authenticated with the Mobile-Home 1030 Authentication Extension (subsection 3.5.1). This extension 1031 immediately follows all non-authentication extensions, except those 1032 foreign agent specific extensions which may be added to the packet 1033 after the mobile node computes the authentication. 1035 3.3. Registration Request 1037 A mobile node sends a registration request message so that its home 1038 agent can create or modify a mobility binding for that mobile node 1039 (with a new lifetime). The request may be relayed to the home agent 1040 by the foreign agent from which the mobile node is accepting service, 1041 or it may be sent directly in case the mobile node has received a 1042 care-of address by some other means (e.g, DHCP [8]). 1044 IP fields: 1046 Source Address Typically the interface address from which 1047 the packet is sent. 1049 Destination Address Typically that of the foreign agent or the 1050 home agent. 1052 See subsections 3.6.1.1 and 3.7.2.2 for details. 1054 UDP fields: 1056 Source Port variable 1058 Destination Port 434 1060 The UDP header is followed by the Mobile-IP fields shown below: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type |S|B|D|M|G|rsvd | Lifetime | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Home Address | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Home Agent | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Care-of Address | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Identification | 1074 | | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Extensions ... 1077 +-+-+-+-+-+-+-+- 1079 Type 1 (Registration Request) 1081 S If the 'S' bit is set, the mobile client is 1082 requesting that the home agent retain its 1083 prior mobility bindings, as described in 1084 subsection 3.6.1.2. 1086 B If the 'B' bit is set, the mobile client 1087 requests that the home agent send to it, all 1088 broadcasts on the home network, as described in 1089 subsection 4.3. 1091 D If the 'D' bit is set, the mobile client will 1092 itself decapsulate datagrams which are sent to 1093 the care-of address. That is, the mobile node 1094 has dynamically acquired a care-of address. 1096 M If the 'M' bit is set, the mobile node asks its 1097 home agent to use minimal encapsulation [16]. 1099 G If the 'G' bit is set, the mobile node asks its 1100 home agent to use GRE encapsulation [10]. 1102 Lifetime The number of seconds remaining before the 1103 registration is considered expired. A value of 1104 zero indicates a request for deregistration. A 1105 value of all ones indicates infinity. 1107 Home Address The IP address of the mobile node. 1109 Home Agent The IP address of a home agent. 1111 Care-of Address The IP address for the end of a tunnel. 1113 Identification A 64-bit number, constructed by the mobile node, 1114 useful for matching requests with replies, and 1115 for protecting against replay attacks (see 1116 subsections 5.4, 5.6). 1118 Extensions The fixed portion of the Registration Request 1119 is followed by one or more of the extensions 1120 listed in subsection 3.5. The Mobile-Home 1121 Authentication Extension MUST be included in 1122 all Registration Requests. See the sections on 1123 mobile node, and foreign agent considerations 1124 (3.6.1.3 and 3.7.2.2) for ordering rules on 1125 extensions. 1127 3.4. Registration Reply 1129 A mobility agent returns registration reply message to a mobile node 1130 which has sent a registration request (subsection 3.3) message. 1131 If the mobile node is accepting service from a foreign agent, 1132 that foreign agent will receive the reply from the home agent and 1133 subsequently relay it to the mobile node. The reply message contains 1134 the necessary codes to inform the mobile node about the status of its 1135 request, along with the lifetime granted by the home agent, which MAY 1136 be smaller than the original request. 1138 Mobility agents MUST NOT increase the lifetime selected by the mobile 1139 node in the registration request. If the lifetime of the reply is 1140 greater than the original request, the excess time MUST be ignored. 1141 When the lifetime of the reply is smaller than the original request, 1142 another registration SHOULD occur before the smaller lifetime 1143 expires. 1145 IP fields: 1147 Source Typically copied from the destination address of the 1148 Registration Request to which the agent is replying. 1149 See subsections 3.7.2.3 and 3.8.3.1 for complete 1150 details. 1152 Destination Copied from the source address of the Registration 1153 Request to which the agent is replying 1155 UDP fields: 1157 Source Port 1159 Destination Port Copied from the source port of the 1160 corresponding Registration Request 1161 (subsection 3.7.1). 1163 The UDP header is followed by the Mobile-IP fields shown below: 1165 0 1 2 3 1166 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 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Type | Code | Lifetime | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Home Address | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Home Agent | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | Identification | 1175 | | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Extensions ... 1178 +-+-+-+-+-+-+-+- 1180 Type 3 (Registration Reply) 1182 Code One of the following codes: 1184 0 registration accepted 1185 1 registration accepted; simultaneous mobility 1186 bindings unsupported 1188 Service denied by the foreign agent: 1190 64 reason unspecified 1191 65 administratively prohibited 1192 66 insufficient resources 1193 67 mobile node failed authentication 1194 68 home agent failed authentication 1195 69 requested lifetime too long 1196 70 poorly formed request 1197 71 poorly formed reply 1198 72 requested encapsulation unavailable 1199 73 requested VJ compression unavailable 1200 80 home network unreachable (ICMP error) 1201 81 home agent host unreachable (ICMP error) 1202 82 home agent port unreachable (ICMP error) 1203 88 home agent unreachable (other ICMP error) 1205 Service denied by the home agent: 1207 128 reason unspecified 1208 129 administratively prohibited 1209 130 insufficient resources 1210 131 mobile node failed authentication 1211 132 foreign agent failed authentication 1212 133 identification mismatch 1213 134 poorly formed request 1214 135 too many simultaneous mobility bindings 1215 136 unknown home agent address 1217 Up-to-date values of the Code field are specified 1218 in the most recent "Assigned Numbers" [20]. 1220 Lifetime The seconds remaining before the registration is 1221 considered expired. A value of zero confirms a 1222 request for deregistration. A value of all ones 1223 indicates infinity. 1225 Home Address The IP address of the mobile node. 1227 Home Agent The IP address of a home agent. 1229 Identification The registration identification is copied from 1230 the request message, for use by the mobile 1231 node in matching its reply with an outstanding 1232 request. 1234 Extensions The fixed portion of the Registration Reply 1235 is followed by one or more of the extensions 1236 listed in subsection 3.5. The Mobile-Home 1237 Authentication Extension MUST be included in all 1238 Registration Replies returned by the home agent. 1239 See the sections on foreign agent and home agent 1240 considerations (3.7.2.2 and 3.8.3.3) for the 1241 ordering rules on extensions. 1243 3.5. Registration Extensions 1245 Each authenticator required in the authentication extensions which 1246 follow is defined to be a value computed from a stream of bytes 1247 including: 1249 - the shared secret, 1250 - the UDP payload (that is, the registration request or reply data), 1251 - all prior extensions in their entirety, and 1252 - the type and length of this extension, 1254 but not including the Authenticator field itself nor the UDP header. 1255 See subsection 5.1 for information about support requirements for 1256 message authentication codes, etc. which are to be used with the 1257 various authentication extensions. 1259 3.5.1. Mobile-Home Authentication Extension 1261 This extension must be present in all registration requests and 1262 replies, and is intended to eliminate problems [3] which result from 1263 the uncontrolled propagation of remote redirects in the Internet. 1264 The location of the authentication extension marks the end of the 1265 authenticated data. 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Type | Length | SPI .... 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 ... SPI (cont.) | Authenticator ... 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Type 32 1277 Length The number of data bytes in the extension. 1279 SPI Security Parameter Index (4 bytes) 1281 Authenticator (variable length) (see 3.5) 1283 3.5.2. Mobile-Foreign Authentication Extension 1285 This extension may be found in registration requests and replies 1286 where a security association exists between the mobile node and a 1287 foreign agent. See subsection 5.1 for information about support 1288 requirements for message authentication codes, etc. 1290 0 1 2 3 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Type | Length | SPI .... 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 ... SPI (cont.) | Authenticator ... 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Type 33 1300 SPI Security Parameter Index (4 bytes) 1302 Length The number of data bytes in the extension. 1304 Authenticator (variable length) (see 3.5) 1306 3.5.3. Foreign-Home Authentication Extension 1308 This extension may be found in registration requests and replies 1309 where a security association exists between the foreign agent and 1310 a home agent. See subsection 5.1 for information about support 1311 requirements for message authentication codes, etc. 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Type | Length | SPI .... 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 ... SPI (cont.) | Authenticator ... 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 Type 34 1323 SPI Security Parameter Index (4 bytes) 1325 Length The number of data bytes in the extension. 1327 Authenticator (variable length) (see 3.5) 1329 3.6. Mobile Node Considerations 1331 A mobile node must be configured with its home address, a netmask, 1332 and a mobility security association for each home agent. In 1333 addition, a mobile node MAY be configured with the IP address of one 1334 or more of its home agents; otherwise, the mobile node MAY discover a 1335 home agent using the procedures described in section 3.6.1.2. 1337 For each pending registration, the mobile node needs the following: 1339 - link-layer address of foreign agent, if applicable 1340 - Care-of Address 1341 - registration Identification 1342 - registration Lifetime 1344 A mobile node initiates registration whenever it detects a change in 1345 its network connectivity. See section 2.4.2 for the methods by which 1346 mobile nodes can make such a determination. When it is away from 1347 home, the mobile node's Registration Request allows its home agent to 1348 create or modify a mobility binding. When it is at home, the mobile 1349 node's (de)Registration Request allows its home agent to erase any 1350 previous mobility binding(s). A mobile node operates without the 1351 support of mobility functions when it is at home. 1353 There are other conditions under which the mobile node SHOULD 1354 (re)register with its foreign agent, such as when the mobile node 1355 detects that the agent has rebooted (as specified in section 2.4.4) 1356 and when the current registration's Lifetime is near expiration. 1358 In the absence of link-layer indications of changes in point of 1359 attachment, Agent Advertisements from new agents do not necessarily 1360 affect a current registration. In the absence of link-layer 1361 indications, a mobile node MUST NOT attempt to register more often 1362 than once per second. 1364 A mobile node MAY register with a different agent when 1365 transport-layer protocols indicate excessive retransmissions. 1366 A mobile node MUST NOT register with a new foreign agent because 1367 it has received an ICMP Redirect from the foreign agent that is 1368 currently providing service to it. Within these constraints, the 1369 mobile node MAY register again at any time. 1371 Please refer to the examples in appendix C to see how the fields in 1372 registration messages would be set up in some typical registration 1373 scenarios. 1375 3.6.1. Sending Registration Requests 1377 The following sections provide additional detail for the values 1378 the mobile node MUST supply in the fields of Registration Request 1379 messages. 1381 3.6.1.1. IP Fields 1383 This section provides the specific rules by which mobile nodes pick 1384 values for the IP header fields of a Registration Request. 1386 IP Source Address: 1388 - When registering on a foreign network with a dynamically acquired 1389 care-of address, the IP source address MUST be the care-of 1390 address. 1391 - In all other circumstances, the IP source address MUST be the 1392 mobile node's home address. 1394 IP Destination Address: 1396 - When the IP address is unknown (e.g., the agent was discovered 1397 via a link-layer protocol), the "All Mobility Agents" multicast 1398 address (224.0.0.11) MUST be used. In such a case, the mobile 1399 node SHOULD use the agent's link-layer unicast address in order to 1400 deliver the datagram to the correct agent. 1401 - When registering with a foreign agent, the address of the agent 1402 as learned from the IP source address of the corresponding Agent 1403 Advertisement MUST be used. 1404 - When registering directly with the home agent, the destination 1405 address is set to the (unicast) address that the mobile node uses 1406 for its home agent. 1407 - If the mobile node is connected to its home network or if the 1408 mobile node is registering without a foreign agent, and the mobile 1409 node is attempting to perform home agent discovery, then the 1410 IP destination address is set to the subnet-directed broadcast 1411 address of the home network. This address MUST NOT be used if the 1412 mobile node is registering via a foreign agent. 1414 IP Time to Live: 1416 - The IP TTL field MUST be set to 1 if the IP destination address is 1417 set to the "All Mobility Agents" multicast address as described 1418 above. Otherwise a suitable value should be chosen in accordance 1419 with standard IP practice [19]. 1421 3.6.1.2. Registration Request Fields 1423 This section provides specific rules by which mobile nodes pick 1424 values for the fields within the fixed portion of a Registration 1425 Request. 1427 A mobile node MAY set the 'S' bit in order to request that the home 1428 agent maintain prior mobility binding(s). Otherwise, the home agent 1429 deletes any previous binding(s) and replaces them with the new 1430 binding specified in the Registration Request. Multiple simultaneous 1431 mobility bindings are likely to be useful when a mobile node moves 1432 within range of multiple cellular systems. IP explicitly allows 1433 duplication of datagrams. When the home agent allows simultaneous 1434 bindings, it will encapsulate a separate copy of each arriving 1435 datagram to each care-of address, and the mobile node will receive 1436 multiple copies of its datagrams. 1438 A mobile node MAY set the 'B' bit if the mobile node would like 1439 to receive a copy of all IP broadcasts on its home network. Note 1440 that in order to "shield" local broadcast packets from nodes on the 1441 foreign network (particularly the foreign agent), the home agent is 1442 required to tunnel broadcasts either directly to a mobile node's 1443 dynamically acquired care-of address (hence the 'D' bit) -or- it 1444 must recursively tunnel such packets first to the mobile node's home 1445 address and then to the (foreign agent-provided) care-of address. 1446 The mobile node must be capable of de-tunneling packets in order to 1447 obtain the original broadcast datagram. For this reason, the 'B' bit 1448 MUST NOT be set unless the mobile node is capable of de-tunneling 1449 packets. 1451 The mobile node SHOULD set the 'D' bit if it is registering with its 1452 own dynamically acquired care-of address. Otherwise, this bit MUST 1453 NOT be set. 1455 The mobile node MAY request alternative forms of encapsulation by 1456 setting the 'M' bit and/or the 'G' bit, but only if the mobile node 1457 is decapsulating its own packets (with a dynamically acquired care-of 1458 address) or if its foreign agent has indicated support for these 1459 forms of encapsulation by setting the corresponding bits in the 1460 Mobile Service Extension of an Agent Advertisement. Otherwise, the 1461 mobile node MUST NOT set these bits. 1463 The Lifetime field is chosen as follows: 1465 - If the mobile node is registering with a foreign agent, the 1466 Lifetime SHOULD NOT exceed the value learned in the Agent 1467 Advertisement. When the method by which the care-of address is 1468 learned does not include a Lifetime, the default ICMP Router 1469 Advertisement Lifetime (1800 seconds) MAY be used. 1470 - The mobile node MAY ask a home agent to terminate forwarding 1471 service to a particular care-of address, by sending a registration 1472 with a Lifetime of zero (see section 3.8.2). 1473 - Similarly, a Lifetime of zero is used when the mobile node 1474 deregisters all care-of addresses upon returning home. 1476 The Home Agent field is set to the address of one of the mobile 1477 node's home agents, if the mobile node possesses this information. 1478 Otherwise, the mobile node MAY discover a home agent by setting this 1479 field to the subnet-directed broadcast address of the home network. 1480 (Each home agent will reject the mobile node's registration, but in 1481 the reply they will provide their unicast address for use by the 1482 mobile node in a future registration attempt). 1484 The Care-of Address field is set to the value of the particular 1485 care-of address that the mobile node wishes to (de)register. In the 1486 special case when a mobile node wishes to deregister all care-of 1487 addresses, it sets this field to the value of the its home address. 1488 A mobile node on its home network need not register again with a home 1489 agent when a change of sequence number occurs, or the advertisement 1490 lifetime expires, or even when the home agent crashes, since it is 1491 not seeking service from the home agent. 1493 The mobile node chooses the Identification field in accordance with 1494 the style of replay protection it uses with its home agent. This is 1495 part of the mobility security association the mobile node shares with 1496 its home agent. See section 5.6 on replay protection for the method 1497 by which the mobile node computes the Identification field. 1499 3.6.1.3. Extensions 1501 This section describes the ordering of any mandatory and any optional 1502 extensions that a mobile node appends to a Registration Request. 1503 This following ordering MUST be followed: 1505 a) The IP header, followed by the UDP header, followed by the 1506 fixed-length portion of the Registration Request 1508 b) Any non-authentication extensions relevant to the home agent 1509 (which may or may not also be relevant to the foreign agent) 1511 c) The Mobile-Home Authentication Extension 1513 d) Any non-authentication extensions relevant only to the 1514 foreign agent. 1516 e) The Mobile-Foreign Authentication Extension 1518 Note that items (a) and (c) MUST appear in every Registration Request 1519 sent by the mobile node. Items (b), (d), and (e) are optional. 1520 However, item (e) MUST be included when the mobile node and the 1521 foreign agent share a security association. 1523 3.6.2. Receiving Registration Replies 1525 Registration Replies will be received by the mobile node in response 1526 to its Registration Requests. Registration Replies generally fall 1527 into three categories: 1529 - service request was accepted, 1530 - service request was denied by foreign agent, and 1531 - service request was denied by home agent. 1533 The remainder of this section describes handling by mobile nodes 1534 under these various categories, based upon the contents of the 1535 Registration Reply. 1537 3.6.2.1. Validity Checks 1539 Registration Replies with an invalid, non-zero UDP checksum MUST be 1540 silently discarded. 1542 In addition, the low-order 32 bits of the Identification field in 1543 the Registration Reply MUST be compared to the low-order 32 bits of 1544 Identification field in the most recent Registration Request sent to 1545 the replying agent. If they do not match, the Reply MUST be silently 1546 discarded. 1548 Also, the Registration Reply MUST be checked for authenticity. 1549 That is, the mobile node MUST check for the presence of a valid 1550 authentication extension, based upon the Code field in the Reply. 1551 The rules are as follows: 1553 a) The mobile node MUST check for a valid Mobile-Home 1554 Authentication Extension. If no such extension is found, the 1555 mobile node MUST silently discard the Reply and the mobile 1556 node SHOULD log the event as a security exception. 1558 b) If the mobile node finds a valid Mobile-Home authentication 1559 extension in a registration reply indicating a successful 1560 registration, and the mobile node and foreign agent share a 1561 security association, the mobile node MUST additionally check 1562 for a valid Mobile-Foreign Authentication Extension. If, 1563 under these circumstances, no such extension is found, the 1564 mobile node MUST silently discard the Reply and the mobile 1565 node SHOULD log the event as a security exception. 1567 If the Code field indicates an authentication failure, either at the 1568 foreign agent or the home agent, then it is quite possible that any 1569 authenticators in the Registration Reply will also be in error. This 1570 could happen, for example, if the shared secret between the mobile 1571 node and home agent was erroneously configured. The mobile node 1572 SHOULD log such errors as security exceptions. 1574 3.6.2.2. Service Request Accepted 1576 If the Code field indicates that service will be provided, the mobile 1577 node SHOULD configure its routing table appropriately for its current 1578 point of attachment (see subsection 4.2.1). 1580 If the mobile node is returning to its home network and that network 1581 is one which implements ARP, the mobile node SHOULD send gratuitous 1582 ARPs on its behalf to clear out any stale ARP entries in the ARP 1583 caches of nodes on the home network, as described in section 4.6. 1585 If the mobile node has registered on a foreign network, it SHOULD 1586 re-register before the granted Lifetime expires. 1588 3.6.2.3. Service Request Denied 1590 If the Code field indicates that service is being denied, the mobile 1591 node SHOULD log the error. There are several scenarios under which 1592 the mobile node may be able to "repair" the error. These include: 1594 - Code 69: (Denied by foreign agent, Lifetime too long) 1595 In this case, the Lifetime field in the Registration Reply 1596 will contain the maximum amount of time for which that foreign 1597 agent is willing to accept registrations. The mobile node MAY 1598 attempt to register with this same agent, using a Lifetime in the 1599 Registration Request that MUST be less than or equal to the value 1600 specified in the Reply. 1601 - Code 133: (Denied by home agent, Identification mismatch) 1602 In this case, the Identification field in the Registration Reply 1603 will contain a value that allows the mobile node to synchronize 1604 with the home agent, based upon the style of replay protection 1605 in effect. (See section 5.6 for details). The mobile node MUST 1606 adjust the parameters it uses to compute the Identification field 1607 based upon the information in the Registration Reply, before 1608 issuing any future Registration Requests. 1609 - Code 136: (Denied by home agent, Unknown home agent address) 1610 This code is returned by a home agent when the mobile 1611 node is performing home agent discovery as described in 1612 subsections 3.6.1.1 and 3.6.1.2. In this case, the Home Agent 1613 field within the Reply will contain the unicast IP address of the 1614 home agent returning the reply. The mobile node MAY then attempt 1615 to register with this home agent in future Registration Requests. 1617 3.6.3. Registration Retransmission 1619 When no Registration Reply has been received within a reasonable 1620 time, another Registration Request is transmitted. When timestamps 1621 are used, a new registration Identification is chosen for each 1622 retransmission; thus it counts as a new registration. When nonces 1623 are used, the unanswered request is retransmitted unchanged; 1624 thus the retransmission does not count as a new registration (see 1625 subsection 5.6). In this way a retransmission will not require the 1626 home agent to resynchronize with the mobile node by issuing another 1627 nonce. 1629 The maximum time until a new Registration Request is sent SHOULD be 1630 no greater than the requested Lifetime of the Registration Request. 1631 The minimum value SHOULD be large enough to account for the size 1632 of the packets, twice the round trip time for transmission at the 1633 link speed, and at least an additional 100 milliseconds to allow 1634 for processing the packets before responding. Some circuits add 1635 another 200 milliseconds of satellite delay. The minimum time 1636 between Registration Requests MUST NOT be less than 1 second. Note 1637 that retransmissions with nonces do not count as new registration 1638 requests. Each successive wait SHOULD be at least twice the previous 1639 wait, as long as that is less than the maximum. 1641 3.7. Foreign Agent Considerations 1643 The foreign agent plays a passive role in Mobile IP registration. It 1644 relays Registration Requests between mobile nodes and home agents, 1645 and, when it provides the care-of address, decapsulates datagrams for 1646 delivery to the mobile node. It MAY also advertise its presence as 1647 described in subsection 2.3. 1649 The foreign agent MUST NOT originate a Registration Request or Reply 1650 that has not been prompted by the mobile node. The foreign agent 1651 MUST NOT generate a Registration Request or Reply to indicate that 1652 the service Lifetime has expired. A foreign agent MUST NOT originate 1653 a message that asks for deregistration of a mobile node; however, it 1654 MUST relay valid deregistration requests originated by a mobile node. 1656 3.7.1. Configuration and Registration Tables 1658 Each foreign agent will need a care-of address. In addition, for 1659 each pending or current registration, the foreign agent will need a 1660 visitor list entry containing the following information obtained from 1661 the mobile node's Registration Request: 1663 - link-layer source address 1664 - IP Source Address (mobile node's Home Address) 1665 - UDP Source Port 1666 - Home Agent 1667 - Lifetime 1668 - Identification 1670 As with any host on the Internet, a foreign agent may also maintain 1671 a security association for each pending or current registrant, 1672 and use it to authenticate the Registration Requests and Replies 1673 of the mobile node or its home agent (subsections 3.3, 3.4) 1674 The foreign agent may use an available security association 1675 with the home agent to compute the authentication data for the 1676 Foreign-Home Authentication Extension. Even if a foreign agent 1677 implements authentication, it might not use authentication with each 1678 registration, because of the key management difficulties. 1680 3.7.2. Receiving Registration Requests 1682 If the foreign agent is able to satisfy an incoming Registration 1683 Request, it then relays the Request to the home agent. Otherwise, it 1684 denies the request by sending a Registration Reply to the mobile node 1685 with an appropriate rejection Code. The following sections describe 1686 this behavior in more detail. 1688 If a foreign agent receives a deregistration request from a mobile 1689 node in its visitor list, the visitor list entry SHOULD NOT be purged 1690 until the home agent sends back a Registration Reply with a Code 1691 indicating success. 1693 3.7.2.1. Validity Checks 1695 Registration Requests with an invalid, non-zero UDP checksum MUST be 1696 silently discarded. 1698 Also, the Registration Request MUST be checked for authenticity. 1699 That is, the foreign agent MUST check for the presence of a valid 1700 Mobile-Foreign Authentication Extension if it shares a security 1701 association with the mobile node. If, under these circumstances, no 1702 such extension is found, the foreign agent MAY reject the Request by 1703 sending a Registration Reply to the mobile node with Code 67. The 1704 foreign agent SHOULD do no further processing with such a Request. 1706 3.7.2.2. Forwarding a Valid Request to the Home Agent 1708 If the foreign agent is able to satisfy the mobile node's 1709 Registration Request, it relays the Request to the mobile node's home 1710 agent. The foreign agent MUST NOT modify any of the fields beginning 1711 within the fixed portion of the Registration Request up through and 1712 including the Mobile-Home Authentication Extension. Otherwise, an 1713 authentication failure is very likely to occur at the home agent. In 1714 addition, the foreign agent MUST perform the following additional 1715 procedures: 1717 - It MUST consume any extensions following the Mobile-Home 1718 Authentication Extension, 1719 - It SHOULD append any of its own non-authentication extensions of 1720 relevance to the home agent, if applicable, and 1721 - It MUST append the Foreign-Home Authentication Extension, if the 1722 foreign agent shares a security association with the home agent. 1724 Specific fields within the IP header and the UDP header of the 1725 relayed Registration Request MUST be set as follows: 1727 IP Source Address 1729 The foreign agent's address on the interface from which the 1730 packet will be sent. 1732 IP Destination Address 1734 Copied from the Home Agent field within the Registration 1735 Request. 1737 UDP Source Port 1739 1741 UDP Destination Port 1743 434 1745 3.7.2.3. Denying Invalid Requests 1747 If the foreign agent is unable to satisfy the mobile node's 1748 Registration Request, it SHOULD send the mobile node a Registration 1749 Reply with a suitable rejection Code. In such a case, the 1750 Home Address, Home Agent, and Identification fields within the 1751 Registration Reply are copied from the corresponding fields of the 1752 Registration Request. 1754 If the request is being denied because the requested Lifetime is too 1755 long, the foreign agent sets the Lifetime in the Reply to the maximum 1756 length of time for which it is willing to accept a registration, and 1757 sets the Code field to 69. Otherwise, the Lifetime SHOULD be copied 1758 from the Lifetime field in the Request. 1760 Specific fields within the IP header and the UDP header of the 1761 Registration Reply MUST be set as follows: 1763 IP Source Address 1765 Copied from the IP Destination Address of Registration Request, 1766 unless the "All Agents Multicast" address was used. In this 1767 case, the foreign agent's address (on the interface from which 1768 the packet will be sent) is used. 1770 IP Destination Address 1772 Copied from the IP Source Address of the Registration Request. 1774 UDP Source Port 1776 434 1778 UDP Destination Port 1780 Copied from the UDP Source Port of the Registration Request. 1782 3.7.3. Receiving Registration Replies 1784 The foreign agent updates its visitor list when it receives a 1785 valid Registration Reply from a home agent. It then relays the 1786 Registration Reply to the mobile node. The following sections 1787 describe this behavior in more detail. 1789 If upon relaying a Registration Request to a home agent, the foreign 1790 agent receives an ICMP error message instead of a Registration Reply, 1791 then the foreign agent sends to the mobile node a Registration Reply 1792 with an appropriate "Home Agent Unreachable" failure Code (within the 1793 range 80-95, inclusive). See section 3.7.2.3 for details of building 1794 the Registration Reply. 1796 3.7.3.1. Validity Checks 1798 Registration Replies with an invalid, non-zero UDP checksum MUST be 1799 silently discarded. 1801 A Registration Reply MUST be silently discarded if the low-order 1802 32 bits of the Identification field do not match that of a pending 1803 Registration Request. 1805 Also, the Registration Reply MUST be checked for authenticity. 1806 That is, the foreign agent MUST check for the presence of a valid 1807 Foreign-Home Authentication Extension if it shares a security 1808 association with the home agent. If, under these circumstances, no 1809 such extension is found, the foreign agent MAY reject the Request 1810 by sending a Registration Reply to the mobile node with Code 1811 68. The foreign agent MUST NOT perform further processing on the 1812 Reply, though the foreign agent SHOULD log the error as a security 1813 exception. 1815 3.7.3.2. Forwarding Replies to the Mobile Node 1817 A Registration Reply which satisfies the validity checks of 1818 section 3.8.2.1 is relayed to the mobile node. If the reply contains 1819 a status code indicating that service will be provided, then the 1820 foreign agent updates its visitor list accordingly. 1822 The foreign agent MUST NOT modify any of the fields beginning 1823 with the fixed portion of the Registration Reply up through and 1824 including the Mobile-Home Authentication Extension. Otherwise, 1825 an authentication failure is very likely to occur at the mobile 1826 node. In addition, the foreign agent SHOULD perform the following 1827 additional procedures: 1829 - It MUST consume any extensions following the Mobile-Home 1830 Authentication Extension, 1831 - It SHOULD append its own non-authentication extensions of 1832 relevance to the mobile node, if applicable, and 1833 - It MUST append the Mobile-Foreign Authentication Extension, if the 1834 foreign agent shares a security association with the mobile node. 1836 Specific fields within the IP header and the UDP header of the 1837 relayed Registration Reply are set according to the same rules set 1838 forth in section 3.7.2.3. 1840 3.8. Home Agent Considerations 1842 Home agents also play a reactive role in the registration process. 1843 They receive Registration Requests from mobile nodes (perhaps relayed 1844 by a foreign agent), update their mobility bindings appropriately, 1845 and issue suitable Registration Replies in response. 1847 A home agent MUST NOT originate a Registration Reply that has not 1848 been prompted by the mobile node. The home agent MUST NOT generate a 1849 Registration Reply to indicate that the service Lifetime has expired. 1851 3.8.1. Configuration and Registration Tables 1853 Each home agent will need an IP address, and the prefix size for the 1854 home network, if the home network is not a virtual network. The 1855 home agent will need to know the home address and mobility security 1856 association of each authorized mobile node. When an authorized 1857 mobile node becomes registered, the home agent will create or modify 1858 its mobility binding list entry containing: 1860 - care-of address 1861 - registration Identification 1862 - registration Lifetime 1864 The home agent MAY also maintain security associations with 1865 various foreign agents. The home agent may use these security 1866 associations to compute the authentication data for the Foreign-Home 1867 Authentication Extension. 1869 3.8.2. Receiving Registration Requests 1871 If the home agent is able to satisfy an incoming Registration 1872 Request, it then updates the mobile node's mobility binding(s) 1873 and issues a Registration Reply with a suitable Code. Otherwise, 1874 it denies the request by sending a Registration Reply with an 1875 appropriate Code specifying the reason the request was rejected. The 1876 following sections describe this behavior in more detail. 1878 3.8.2.1. Validity Checks 1880 Registration Requests with an invalid, non-zero UDP checksum MUST be 1881 silently discarded by the home agent. 1883 Also, the Registration Request MUST be checked for authenticity. 1884 This minimally involves the following operations: 1886 a) The home agent MUST check for the presence of a valid 1887 Mobile-Home Authentication Extension. If no such extension 1888 is found, the home agent MAY reject the Request by sending 1889 a Registration Reply to the mobile node with Code 131. The 1890 home agent MUST do no further processing with such a Request, 1891 though it SHOULD log the error as a security exception. 1893 b) The home agent MUST check that the registration 1894 Identification field is correct under the context selected 1895 by the security parameter index within the Mobile-Home 1896 Authentication Extension. See section 5.6 for a description 1897 of how this is performed. If incorrect, the home agent MAY 1898 reject the Request by sending a Registration Reply to the 1899 mobile node with Code 133, and including an Identification 1900 field computed in accordance with the rules set forth in 5.6. 1901 The home agent MUST do no further processing with such 1902 a Request, though it SHOULD log the error as a security 1903 exception. 1905 c) In addition, the home agent MUST check for the presence of a 1906 valid Foreign-Home Authentication Extension if it shares a 1907 security association with the foreign agent. If, under these 1908 circumstances, no such extension is found, the home agent MAY 1909 reject the Request by sending a Registration Reply to the 1910 mobile node with Code 132. The home agent MUST do no further 1911 processing with such a Request, but is SHOULD log the error 1912 as a security exception. 1914 In addition to validating the authenticity of a Registration Request, 1915 home agents MUST NOT grant service for Registration Requests that are 1916 sent to the subnet-directed broadcast address of the home network 1917 (as opposed to being unicast to the home agent). The home agent MAY 1918 reject such a request by returning status code 136. In this case, 1919 the Registration Reply will contain the home agent's unicast address, 1920 so that the mobile node can re-issue the Registration Request with 1921 the correct home agent address. 1923 3.8.2.2. Accepting a Valid Request 1925 If the Registration Request satisfies the validity checks in 1926 section 3.8.2.1, and the home agent is able to accommodate the 1927 request, the home agent updates its mobility binding list for the 1928 requesting mobile node and returns a Registration Reply to the mobile 1929 node. In this case, the reply Code will be either 0 if the home 1930 agent supports simultaneous mobility bindings or 1 if it does not. 1931 See section 3.8.3 for details of building the Registration Reply 1932 message. 1934 The home agent updates its mobility bindings as follows: 1936 - If the Lifetime is zero and the Care-of Address equals the mobile 1937 node's home address, the home agent deletes all of the entries in 1938 the mobility binding list for the requesting mobile node. This 1939 is how a mobile node requests that its home agent cease providing 1940 mobility services. 1941 - If the Lifetime is zero and the Care-of Address does not equal the 1942 mobile node's home address, the home agent deletes only the entry 1943 containing the specified Care-of Address from the mobility binding 1944 list for the requesting mobile node. Any other active entries 1945 containing other care-of addresses will remain active. 1946 - If the Lifetime is nonzero, the home agent adds an entry 1947 containing the requested Care-of Address to the mobility binding 1948 list for the mobile node. If the 'S' bit is set to one, and the 1949 home agent supports simultaneous mobility bindings, the previous 1950 mobility binding entries remain active. Otherwise, the home agent 1951 removes all previous entries in the mobility binding list for the 1952 mobile node. 1954 In all cases, the home agent sends a Registration Reply to the 1955 source of the Registration Request, which might indeed be a 1956 different foreign agent than that whose care-of address is being 1957 (de)registered. If the home agent shares a security association with 1958 the foreign agent whose care-of address is being deregistered -- 1959 wherein said foreign agent is different from the one which relayed 1960 the Registration Request -- the home agent MAY additionally send a 1961 Registration Reply to the foreign agent whose care-of address is 1962 being deregistered. The home agent MUST NOT send such a Reply if it 1963 does not share a security association with the foreign agent. If no 1964 Reply is sent, the foreign agent's visitor list will expire naturally 1965 when the original Lifetime expires. 1967 It is not an error for the mobile node to request a Lifetime longer 1968 than the home agent is willing to accept. In such a case, the home 1969 agent simply reduces the Lifetime to a permissible amount and returns 1970 this amount in the Registration Reply. This informs the mobile node 1971 when it should reregister. The home agent MUST NOT increase the 1972 Lifetime above that specified by the mobile node in the Registration 1973 Request. 1975 If the Registration Request duplicates an accepted current 1976 Registration Request, the new Lifetime MUST NOT extend beyond the 1977 Lifetime originally granted. 1979 If the Registration Request asks the home agent to create a mobility 1980 binding for a mobile node which previously had zero entries in its 1981 mobility binding list, the home agent SHOULD send gratuitous ARPs for 1982 the mobile node as described in section 4.6. This, of course, only 1983 applies when the home network is one which implements ARP. While the 1984 mobile node is registered, the home agent SHOULD also proxy ARP for 1985 the mobile node as described in subsection 4.6. 1987 3.8.2.3. Denying an Invalid Request 1989 If the Registration Reply does not satisfy all of the validity checks 1990 in subsection 3.8.2.1, or the home agent is unable to accommodate the 1991 request, the home agent returns a Registration Reply to the mobile 1992 node with a Code that indicates the reason for the error. If a 1993 foreign agent was involved in relaying the request, this allows the 1994 foreign agent to delete its pending visitor list entry. Also, this 1995 informs the mobile node of the reason for the error such that it may 1996 attempt to fix the error and issue another request. 1998 This section lists a number of reasons the home agent might reject a 1999 request and provides the Code value it should use in each instance. 2000 See subsection 3.8.3 for additional details on building the 2001 Registration Reply message. 2003 Many reasons for rejecting a registration are administrative 2004 in nature. For example, a home agent can limit the number of 2005 simultaneous registrations for a mobile node, by rejecting any 2006 registrations that would cause its limit to be exceeded, and 2007 returning a Registration Reply with error code 135. Similarly, a 2008 home agent may refuse to grant service to mobile nodes which have 2009 entered unauthorized service areas by returning a Registration Reply 2010 with error code 129. 2012 3.8.3. Sending Registration Replies 2014 If the home agent is able to satisfy an incoming Registration 2015 Request, it then updates the mobile node's mobility binding(s) 2016 and issues a Registration Reply with a suitable Code. Otherwise, 2017 it denies the request by sending a Registration Reply with an 2018 appropriate Code specifying the reason the request was rejected. The 2019 following sections provide additional detail for the values the home 2020 agent MUST supply in the fields of Registration Reply messages. 2022 3.8.3.1. IP/UDP Fields 2024 This section provides the specific rules by which mobile nodes pick 2025 values for the IP and UPD header fields of a Registration Reply. 2027 IP Source Address Copied from the IP Destination Address of 2028 Registration Request, unless a multicast 2029 or broadcast address was used. In such a 2030 case, the home agent's address by which 2031 it is known to the requesting mobile node 2032 is used. 2034 IP Destination Address Copied from the IP Source Address of the 2035 Registration Request. 2037 UDP Source Port Copied from the UDP Destination Port of 2038 the Registration Request. 2040 UDP Destination Port Copied from the UDP Source Port of the 2041 Registration Request. 2043 3.8.3.2. Registration Reply Fields 2045 This section provides specific rules by which home agents pick values 2046 for the fields within the fixed portion of a Registration Reply. 2048 The Type field in a Registration Reply is always set to 3. The Code 2049 field is chosen according to the rules set forth in the previous 2050 sections. When responding to accepted registrations, a home agent 2051 SHOULD respond with Code 1 if it does not support simultaneous 2052 registrations. 2054 The Lifetime field is copied from the corresponding field in the 2055 Registration Request, unless the requested value is greater than 2056 the maximum length of time the home agent is willing to provide the 2057 requested service. In such a case, the Lifetime MUST be set to the 2058 length of time that service will actually be provided by the home 2059 agent. 2061 The Home Address field is copied from the corresponding field in the 2062 Registration Request. 2064 The Home Agent field is copied from the corresponding field in 2065 the Registration Request, unless the mobile node was performing 2066 home agent discovery. In this case, the mobile node supplied the 2067 subnet-directed broadcast address for the home network instead of the 2068 unicast address of a home agent (note that a home agent MUST reject 2069 this registration with a suitable code, e.g. Code 136). The home 2070 agent supplies its unicast address in the Home Agent field of the 2071 Registration Reply. 2073 The home agent chooses the Identification field in accordance with 2074 the style of replay protection it uses with its mobile node. This is 2075 part of the mobility security association the home agent shares with 2076 the mobile node. See section 5.6 on replay protection for the method 2077 by which the home agent computes the Identification field. 2079 3.8.3.3. Extensions 2081 This section describes the ordering of any mandatory and any optional 2082 extensions that a home agent appends to a Registration Reply. The 2083 following ordering MUST be followed: 2085 a) The IP header, followed by the UDP header, followed by the 2086 fixed-length portion of the Registration Reply, 2088 b) Any non-authentication extensions relevant to the mobile node 2089 (which may or may not also be relevant to the foreign agent), 2090 and 2092 c) The Mobile-Home Authentication Extension 2094 d) Any non-authentication extensions relevant only to the 2095 foreign agent. 2097 e) The Foreign-Home Authentication Extension 2099 Note that items (a) and (c) MUST appear in every Registration Reply 2100 sent by the home agent. Items (b), (d), and (e) are optional. 2101 However, item (e) MUST be included when the home agent and the 2102 foreign agent share a security association. 2104 4. Routing Considerations 2106 Mobile IP uses protocol tunneling to deliver packets to a mobile 2107 node that is connected to a foreign network. This section describes 2108 how packets are routed to/from a mobile node that has successfully 2109 registered one or more care-of addresses with its home agent, using 2110 the registration procedure described in section 3. 2112 4.1. Encapsulation Types 2114 Support for IP in IP encapsulation [15] is required in home 2115 agents and foreign agents, and any mobile node which can accept a 2116 dynamically assigned care-of address. Minimal encapsulation [16] 2117 and GRE encapsulation [10] are alternate encapsulation methods which 2118 MAY optionally be supported by mobility agents and mobile nodes. 2119 Minimal encapsulation MUST NOT be used when the original datagram is 2120 a fragment. The use of these alternative forms of encapsulation, 2121 when requested by the mobile node, is otherwise at the discretion of 2122 the home agent. 2124 4.2. Unicast Packet Routing 2126 The method by which a mobile node selects a default router when 2127 connected to its home network, or when away from home and using a 2128 dynamically assigned care-of address, is outside the scope of this 2129 document. ICMP Router Advertisement [7] is one such method. 2131 4.2.1. Mobile Node Considerations 2133 When connected to its home network, a mobile node operates without 2134 the support of mobility services. That is, it operates just like any 2135 other (fixed) host or router. 2137 When registered on a foreign network, the mobile node chooses a 2138 default router by examining the Agent Advertisements sent by its 2139 foreign agent. The default router is selected by the procedure 2140 described in RFC1256; that is, the mobile node SHOULD choose as its 2141 default router the highest preference router address listed in the 2142 ICMP Router Advertisement portion of the Agent Advertisement. The 2143 mobile node MAY, however, choose its foreign agent as its default 2144 router. Note that Van Jacobson header compression [11] will not 2145 function properly unless all TCP packets to and from the mobile node 2146 pass, respectively, through the same first and last-hop router. 2147 The mobile node, therefore, SHOULD select its foreign agent as its 2148 default router if it performs Van Jacobson header compression with 2149 its foreign agent. 2151 In order for a mobile node to be capable of operating with its own 2152 dynamically acquired care-of address, it MUST be able to detunnel 2153 packets sent to this address. The method by which the mobile 2154 node obtained its local care-of address SHOULD also be capable of 2155 supplying the mobile node with the address of a default router. 2157 4.2.2. Foreign Agent Considerations 2159 Upon receipt of an encapsulated packet sent to its advertised care-of 2160 address, a foreign agent MUST compare the inner destination address 2161 to those entries in its visitor list. When the destination does not 2162 match any node currently in the visitor list, the foreign agent MUST 2163 NOT forward the datagram without modifications to the original IP 2164 header, because otherwise a routing loop is likely to result. The 2165 datagram SHOULD be silently discarded. ICMP Destination Unreachable 2166 MUST NOT be sent when a foreign agent is unable to forward an 2167 incoming tunneled datagram. Otherwise, the foreign agent naturally 2168 forwards the decapsulated packet to the mobile node. 2170 The foreign agent MUST NOT advertise to other routers in its routing 2171 domain, nor to any other mobile node, the presence of a mobile router 2172 (see subsection 4.5). 2174 The foreign agent MUST minimally be able to serve as a default router 2175 for the mobile nodes that are currently registered with it. 2177 4.2.3. Home Agent Considerations 2179 Packets destined for a mobile node will arrive at a home agent that 2180 advertises connectivity to the home network indicated by the address 2181 of the mobile nodes. The home agent must examine the IP header of 2182 all arriving traffic to see if it contains a destination address 2183 equal to the home address of any of its mobile nodes. 2185 If so, the home agent tunnels the datagram to the mobile node's most 2186 recently registered care-of address. If the home agent supports the 2187 optional capability of multiple simultaneous mobility bindings, it 2188 tunnels a copy to each care-of address in the mobile node's mobility 2189 binding list. If the mobile node has no current mobility bindings, 2190 the home agent assumes the mobile node is at home and simply forwards 2191 the datagram directly to it. In this case, however, it is likely 2192 that the datagram will never be received by the home agent. 2194 See section 4.1 about methods of encapsulation that may be used for 2195 tunneling. Maintenance of "soft tunnel state" (described in [15]) 2196 effectively reduces transmission errors in the tunnel. 2198 If the lifetime for a given mobility binding expires before the home 2199 agent has received another Registration Request, then that binding is 2200 erased from the mobility binding list. No special Registration Reply 2201 is sent to the foreign agent. The entry in its visitor list will 2202 expire naturally, and probably at the same time. When a mobility 2203 binding's lifetime expires, the home agent drops it regardless of 2204 whether or not simultaneous bindings are supported. 2206 Suppose an encapsulated datagram arrives at the home agent, that is 2207 to be delivered to one of its mobile clients. If the destination 2208 of the inner header is not that same mobile client, the home agent 2209 may recursively encapsulate it for delivery to its care-of address. 2210 Otherwise, the home agent may simply alter the outer destination 2211 to the care-of address, unless the care-of address is the same as 2212 the origination point of the encapsulated datagram. In the latter 2213 case, if the home agent receives a datagram for one of its mobile 2214 clients, and the packet's IP source address is identical to the 2215 care-of address contained in the mobility binding list, the home 2216 agent MUST silently discard that packet. Otherwise, a routing loop 2217 is likely to result. 2219 4.3. Broadcast packets 2221 When a home agent receives a broadcast packet, it transmits the 2222 packet to only those mobile nodes on its mobility binding list that 2223 have requested broadcast service. Mobile nodes request encapsulated 2224 delivery of broadcast packets by setting the 'B' bit in their 2225 Registration Request packets (subsection 3.3). If the mobile node 2226 is using its own dynamically-assigned care-of address, as indicated 2227 by the 'D' bit in its Registration Request packet, the home agent 2228 simply tunnels each received broadcast IP datagram to this care-of 2229 address. Otherwise, when the mobile node registered through a 2230 foreign agent, the home agent first encapsulates the broadcast 2231 datagram in a unicast datagram addressed to the mobile node's home 2232 address, and then tunnels this encapsulated datagram to the foreign 2233 agent. This extra level of encapsulation is required so that foreign 2234 agent can determine which mobile node should receive the packet after 2235 it is decapsulated. When received by the foreign agent, the unicast 2236 encapsulated datagram is detunneled and delivered to the mobile 2237 node in the same way as any other datagram. In either case, the 2238 mobile node must decapsulate the datagram it receives to recover the 2239 original broadcast datagram. 2241 4.4. Multicast Packet Routing 2243 As mentioned previously, a mobile node that is connected to its home 2244 network functions just like any other (stationary) host or router. 2245 Thus, when it is at home, a mobile node functions identically to 2246 other multicast senders and receivers. This section therefore 2247 describes the behavior of a mobile node that is visiting a foreign 2248 network. 2250 In order receive multicasts, a mobile node must join the multicast 2251 group. Mobile nodes MAY join multicast groups in order to receive 2252 transmissions in one of two ways. First, they MAY join the group 2253 via a (local) multicast router on the visited subnet. This option 2254 assumes that there is a multicast router present on the visited 2255 subnet. The mobile node SHOULD use its dynamically acquired care-of 2256 address (if it has acquired one) as the source IP address of its 2257 IGMP [6] packets. Otherwise, it MAY use its home address. 2259 Alternatively, a mobile node which wishes to receive multicasts can 2260 join groups via a bi-directional tunnel to its home agent, assuming 2261 that its home agent is a multicast router. The mobile node tunnels 2262 IGMP packets to its home agent and the home agent forwards multicast 2263 packets down the tunnel to the mobile node. The rules for multicast 2264 packet delivery to mobile nodes in this case are identical to those 2265 for broadcast packets (see section 4.3). Namely, the home agent must 2266 tunnel the packet directly to the mobile node's dynamically acquired 2267 care-of address, or, the packet must be tunneled first to the mobile 2268 node's home address and then recursively tunneled to the foreign 2269 agent-provided care-of address. 2271 A mobile node which wishes to send packets to a multicast group 2272 also has two options: (1) send directly on the visited network; or 2273 (2) send via a tunnel to its home agent. Because multicast routing 2274 in general depends upon the IP source address, a mobile node which 2275 sends multicast packets directly on the visited network MUST use 2276 a dynamically acquired care-of address as the IP source address. 2277 Similarly, a mobile node which tunnels a multicast packet to its home 2278 agent MUST use its home address as the IP source address of both the 2279 (inner) multicast packet and the (outer) encapsulating packet. This 2280 second option assumes that the home agent is a multicast router. 2282 4.5. Mobile Routers 2284 A mobile node can be a router, which is responsible for the mobility 2285 of one or more entire networks moving together, perhaps on an 2286 airplane, a ship, a train, an automobile, a bicycle, or a kayak. 2287 The nodes connected to a network served by the mobile router may 2288 themselves be fixed nodes or mobile nodes or routers. In this 2289 subsection, such networks are called "mobile networks". 2291 A mobile router may provide a care-of address to mobile nodes 2292 connected to the mobile network. In this case, when a correspondent 2293 host sends a packet to the mobile node, the actions described in the 2294 next paragraph should occur. 2296 Normal IP procedures will route the packet addressed to the mobile 2297 node from the correspondent host to the mobile node's home agent. 2298 This home agent's binding for the mobile node causes it to tunnel the 2299 packet to the mobile router. Normal IP procedures will then route 2300 the packet from this home agent to the mobile router's home agent. 2301 That home agent's binding for the mobile router causes the packet 2302 to be doubly tunneled to the mobile router's care-of address. For 2303 the sake of discussion, assume there is a foreign agent available at 2304 that care-of address. The mobile router's foreign agent will then 2305 detunnel the packet and use its visitor list entry to deliver the 2306 packet to the mobile router. The mobile router will then detunnel 2307 the packet and use its visitor list entry to deliver the packet 2308 finally to the mobile node. 2310 If a fixed node is connected to a mobile network then either of two 2311 methods may be used to cause packets from correspondent hosts to be 2312 routed to the fixed node. 2314 A home agent may be configured that has a permanent registration for 2315 the fixed node that indicates the mobile router's address as the 2316 fixed host's care-of address. The mobile router's home agent will 2317 usually be used for this purpose. The home agent is then responsible 2318 for advertising connectivity using normal routing protocols to 2319 the fixed node. Any packets sent to the fixed node will thus use 2320 recursive tunneling as described above. 2322 Alternatively, the mobile router may advertise connectivity to the 2323 entire mobile network using normal IP routing protocols through a 2324 bi-directional tunnel to its own home agent. This method avoids the 2325 need for recursive tunneling of packets. 2327 4.6. Gratuitous and Proxy ARP 2329 Many people will use their computers for extended periods of time 2330 on a single link, whether or not it is at their home network. When 2331 doing so, they will expect the same level of service from their 2332 infrastructure as they receive today on the home network. 2334 Mobile nodes do not need a separate "virtual" IP address block; this 2335 would require a small network to have an extra router between the 2336 mobile and non-mobile nodes, which is an unacceptable expense. 2338 This section details the special care to be taken when nodes on the 2339 same link as a mobile node use ARP [17] to resolve its IP address. 2341 If a mobile node which has previously answered an ARP Request moves 2342 away from the link, it may leave behind a stale entry in another 2343 node's ARP cache. For example, if a router which forwards datagrams 2344 into the home network has a stale ARP cache entry for the mobile 2345 node, any datagrams arriving through that router for the mobile 2346 node will be lost. Thus, it is important that ARP caches of nodes 2347 populating the link be updated as soon as possible. 2349 A gratuitous ARP is an ARP Reply that is broadcast to all nodes on a 2350 link, but not in response to any ARP Request. When an ARP Reply is 2351 broadcast, all hosts are required to update their local ARP caches, 2352 whether or not the ARP Reply was in response to an ARP Request they 2353 had issued. With gratuitous ARP, the source IP address is the home 2354 address of the mobile node, the link-layer address is the source 2355 link-layer address for the interface used, the target IP address is 2356 the all-systems multicast address, and the target link-layer address 2357 is the general broadcast address. 2359 When there is a physical link which corresponds to the home network, 2360 a gratuitous ARP is issued by the home agent on behalf of a mobile 2361 node whenever the home agent receives a valid registration which 2362 causes the number of current bindings to change from zero to a 2363 positive number. That should cause the remaining nodes to associate 2364 the home address of the mobile node with the link-layer address of 2365 the home agent which is now serving the mobile node. 2367 While the mobile node is away from its home network, the home agent 2368 performs proxy ARP Replies for the mobile node. When a mobile node 2369 returns to its home network, it SHOULD issue a gratuitous ARP on its 2370 own behalf, immediately before sending its deregistration request to 2371 the home agent. 2373 Although the gratuitous ARP can be lost, this is not different from 2374 the usual ARP Reply problems, which are outside the scope of this 2375 document. A home agent or mobile node may repeat the gratuitous ARP 2376 a small number of times. 2378 5. Security Considerations 2380 The mobile computing environment is potentially very different from 2381 the ordinary computing environment. In many cases, mobile computers 2382 will be connected to the network via wireless links. Such links 2383 are particularly vulnerable to passive eavesdropping, active replay 2384 attacks, and other active attacks. 2386 5.1. Message Authentication Codes 2388 Home agents and mobile nodes MUST be able to perform authentication. 2389 The default algorithm is keyed MD5 [21], with a key size of 128 2390 bits. The default mode of operation is to both precede and follow 2391 the data to be hashed, by the 128-bit key; that is, MD5 is to be 2392 used in suffix+prefix mode. The foreign agent SHOULD also support 2393 authentication using keyed MD5 and key sizes of 128 bits or greater, 2394 with manual key distribution. More authentication algorithms, 2395 algorithm modes, key distribution methods, and key sizes MAY also be 2396 supported. 2398 5.2. Areas of security concern in this protocol 2400 The registration protocol described in this document will result 2401 in a mobile node's traffic being tunneled to its care-of address. 2402 This tunneling feature could be a significant vulnerability if the 2403 registration were not authentic. Such remote redirection, for 2404 instance as performed by the mobile registration protocol, is widely 2405 understood to be a security problem in the current Internet [3]. 2406 Moreover, the Address Resolution Protocol (ARP) is not authenticated, 2407 and can potentially be used to steal another host's traffic. The use 2408 of "Gratuitous ARP" (see subsection 4.6) brings with it all of the 2409 risks associated with the use of ARP. 2411 5.3. Key management 2413 This specification requires a strong authentication mechanism 2414 (keyed MD5) which precludes many potential attacks based on the 2415 Mobile IP registration protocol. However, because key distribution 2416 is difficult in the absence of a network key management protocol, 2417 messages with the foreign agent are not all required to be 2418 authenticated. In a commercial environment it might be important 2419 to authenticate all messages between the foreign agent and the home 2420 agent, so that billing is possible, and service providers don't 2421 provide service to users that are not legitimate customers of that 2422 service provider. 2424 5.4. Picking good random numbers 2426 The strength of any authentication mechanism is dependent on 2427 several factors, including the innate strength of the authentication 2428 algorithm, the secrecy of the key used, the strength of the key used, 2429 and the quality of the particular implementation. This specification 2430 requires implementation of keyed MD5 for authentication, but does not 2431 preclude the use of other authentication algorithms and modes. For 2432 keyed MD5 authentication to be useful, the 128-bit key must be both 2433 secret (that is, known only to authorized parties) and pseudo-random. 2434 If nonces are used in connection with replay protection, they must 2435 also be selected carefully. Eastlake, et.al. [9] provides more 2436 information on generating pseudo-random numbers. 2438 5.5. Privacy 2440 Users who have sensitive data that they do not wish others to see 2441 should use mechanisms outside the scope of this document (such as 2442 encryption) to provide appropriate protection. Users concerned about 2443 traffic analysis should consider appropriate use of link encryption. 2444 If absolute location privacy is desired, the Mobile Node can create a 2445 tunnel to its Home Agent. Then, packets destined for correspondent 2446 hosts will appear to emanate from the Home Network, and it may be 2447 more difficult to pinpoint the location of the mobile node. 2449 5.6. Replay Protection for Registration Requests 2451 The Identification field is used to let the home agent verify that a 2452 registration message has been freshly generated by the mobile node, 2453 not replayed by an attacker from some previous registration. The 2454 exact method of using the field depends upon the mobile security 2455 association defined between the mobile node and home agent. Two 2456 methods are described here: using random "nonce" values (preferred), 2457 and another method using timestamps. A mobile node and its home 2458 agent must agree on the use of replay protection, because if a home 2459 agent expects only a nonce, it is unlikely to accept the mobile 2460 node's time value. 2462 Whatever method is used, the low order 32 bits of the identification 2463 MUST be copied unchanged from the registration request to the reply. 2464 The foreign agent uses those bits to match registration requests with 2465 corresponding replies. The mobile node MUST verify that the low 2466 order 32 bits of any registration reply are identical to the bits it 2467 sent in the registration request. 2469 The Identification in a new registration request MUST NOT be the same 2470 as in an immediately preceding request, and SHOULD NOT repeat during 2471 the lifetime of the selected security context between the mobile 2472 node and the home agent. Retransmission as in subsection 3.6.3 is 2473 allowed. 2475 5.6.1. Replay Protection using Nonces 2477 The basic principle of nonce replay protection is that Node A 2478 includes a new random number in every message to node B, and checks 2479 that Node B returns that same number in its next message to node 2480 A. Both messages use a cryptographic checksum to protect against 2481 alteration by an attacker. At the same time Node B can send its own 2482 nonces in all messages to Node A (to be echoed by node A), so that it 2483 too can verify that it is receiving fresh messages. 2485 The home agent may be expected to have resources for computing 2486 pseudo-random numbers useful as nonces[9]. It inserts a new nonce 2487 as the high-order 32 bits of the identification field of every 2488 registration reply. The home agent copies the low-order 32 bits of 2489 the Identification from the registration request message. When the 2490 mobile node receives an authenticated registration reply from the 2491 home agent, it saves the high order 32 bits of the identification for 2492 use as the high-order 32 bits of its next registration request. 2494 The mobile node is responsible for generating the low order 32 2495 bits of the Identification in each registration request. Ideally 2496 it should generate its own random nonces. However it may use any 2497 expedient method, including duplication of the random value sent by 2498 the home agent. The method chosen is of concern only to the mobile 2499 node, because it is the node that checks for valid values in the 2500 registration reply. The high-order and low-order 32 bits of the 2501 identification chosen SHOULD both differ from their previous values. 2502 The home agent needs a new high order value and the mobile node needs 2503 a new low-order value for replay protection. The foreign agent uses 2504 the low-order value to correctly match registration replies with 2505 pending requests (see subsection 3.7.1). 2507 If a registration message is rejected because of an invalid nonce, 2508 the reply always provides the mobile node with a new nonce to 2509 be used in the next registration. Thus the nonce protocol is 2510 self-synchronizing. 2512 5.6.2. Replay Protection using Timestamps 2514 The basic principle of timestamp replay protection is that the node 2515 generating a message inserts the current time of day, and the node 2516 receiving the message checks that this timestamp is sufficiently 2517 close to its own time of day. Obviously the two nodes must have 2518 adequately synchronized time of day clocks. As usual all messages 2519 are protected against tampering by a cryptographic checksum. 2521 If timestamps are used, the mobile node sets the Identification 2522 field to a 64-bit value formatted as specified by the Network Time 2523 Protocol [14]. The low-order 32 bits of the NTP format represent 2524 fractional seconds, and those bits which are not available from a 2525 time source SHOULD be generated from a good source of randomness. 2527 If the timestamp in a Registration Request that has passed 2528 authentication is close enough to the home agent's time of day, the 2529 home agent copies the entire Identification into the Registration 2530 Reply. If the timestamp is unacceptable, the home agent copies only 2531 the low-order 32 bits into the Registration Reply, and supplies 2532 the high-order 32 bits from its own time of day. The Code in 2533 the Registration Reply indicates an identification mismatch (Code 2534 133). The mobile node MUST verify that the low-order 32 bits of the 2535 Identification in the Registration Reply are identical to those in 2536 the rejected registration attempt, before using the high-order bits 2537 for clock resynchronization. Time tolerances and resynchronization 2538 details are specific to a particular mobile security association. 2540 6. Acknowledgements 2542 Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp 2543 and John Ioannidis (JI) (Columbia), for forming the working group, 2544 chairing it, and putting so much effort into its early development. 2546 Thanks also to Kannan Alaggapan and Greg Minshall for their 2547 contributions to the group while performing the duties of 2548 chairperson. 2550 Thanks to the active members of the Mobile-IP working group, 2551 particularly those who contributed text, including (in alphabetical 2552 order) 2554 - Ran Atkinson (Naval Research Lab), 2555 - Dave Johnson (Carnegie Mellon University), 2556 - Frank Kastenholz (FTP Software) 2557 - Anders Klemets (KTH) 2558 - Chip Maguire (KTH - also, JI's advisor and early contributor) 2559 - Andrew Myles (Macquarie University), 2560 - Al Quirt (Bell Northern Research), 2561 - Yakov Rekhter (IBM), and 2562 - Fumio Teraoka (Sony). 2564 Thanks to Charlie Kunzinger and to Bill Simpson, the editors who 2565 produced the first drafts for of this document, reflecting the 2566 discussions of the Working Group. Much of the new text in this 2567 latest draft is due to Jim Solomon. 2569 Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), and Frank 2570 Kastenholz (FTP Software) for their generous support in hosting 2571 interim Working Group meetings. 2573 Implementors may note that Anders Klemets has an implementation 2574 of the protocol specified here for mobile nodes, foreign agents, 2575 and home agents running under SunOS v4.1.3. He is willing to 2576 provide it to people wishing to perform beta testing. Contact 2577 him at if you would like a copy. There 2578 is also a version of mobile-IP which was developed by Vipul 2579 Gupta at the State University of 2580 New York Binghamton. The software (along with supporting 2581 documentation) is available from the Linux Mobile-IP home page at 2582 http://anchor.cs.binghamton.edu/~mobileip. 2584 A. Link-Layer considerations 2586 The mobile node primarily uses link-layer mechanisms to decide that 2587 its point of attachment has changed. Such indications include 2588 the Down/Testing/Up interface status [12], and changes in cell or 2589 administration. The mechanisms will be specific to the particular 2590 link-layer technology, and are outside the scope of this document. 2592 A.1. Point-to-Point Link-Layers 2594 The Point-to-Point-Protocol (PPP) [22] and its Internet Protocol 2595 Control Protocol (IPCP) [13], negotiates the use of IP addresses. 2597 The mobile node SHOULD first attempt to specify its home address. 2598 This allows an unrouted link to function correctly. 2600 When the home address is not accepted by the peer, but a transient 2601 IP address is dynamically assigned, that address MAY be used as the 2602 care-of address for registration. When the peer specifies its own IP 2603 address, that address MUST NOT be assumed to be the care-of address 2604 of a foreign agent or the IP address of a home agent. 2606 When router advertisements are received which contain the Mobile 2607 Service Extension, registration with the agent SHOULD take place as 2608 usual. If the link is bandwidth limited, this method is preferred 2609 over use of the transient care-of address. The encapsulation will 2610 be removed by the peer, allowing header compression techniques to 2611 function correctly [11]. 2613 A.2. Multi-Point Link-Layers 2615 Another link establishment protocol, IEEE 802.11 [1], might yield the 2616 link address of an agent. This link-layer address SHOULD be used to 2617 attempt registration. 2619 The receipt of an agent's address via a router advertisement 2620 supersedes that obtained via IEEE 802.11. 2622 B. TCP Considerations 2624 B.1. TCP Timers 2626 Most hosts and routers which implement TCP/IP do not permit easy 2627 configuration of the TCP timer values. When high-delay (e.g. 2628 SATCOM) or low-bandwidth (e.g. High-Frequency Radio) links are 2629 in use, the default TCP timer values in many systems may cause 2630 retransmissions or timeouts, even when the link and network is 2631 actually operating properly with greater than usual delays because 2632 of the medium in use. This can cause an inability to create or 2633 maintain connections over such links, and can also cause unneeded 2634 retransmissions which consume already scarce bandwidth. Vendors are 2635 encouraged to make TCP timers more configurable. Vendors of systems 2636 designed for the mobile computing markets should pick default timer 2637 values more suited to low-bandwidth, high-delay links. Users of 2638 mobile nodes should be sensitive to the possibility of timer-related 2639 difficulties. 2641 B.2. TCP Congestion Management 2643 Mobility nodes are likely to use media which have low bandwidth and 2644 are more likely to introduce errors, effectively causing more packets 2645 to be dropped. This introduces a conflict with the mechanisms for 2646 congestion management found in modern versions of TCP. Now, when 2647 a packet is dropped, the correspondent's TCP implementation is 2648 likely to react as if there were a source of network congestion, 2649 and initiate the slow-start mechanisms [5] designed for controlling 2650 that problem. However, those mechanisms are inappropriate for 2651 overcoming errors introduced by the links themselves, and have the 2652 effect of magnifying the discontinuity introduced by the dropped 2653 packet. This problem has been analyzed by Caceres, et. al. [4]; 2654 there is no easy solution available, and certainly no solution likely 2655 to be installed soon on all correspondents. While this problem has 2656 nothing to do with any of the specifications in this document, it 2657 does illustrate that providing performance transparency to mobile 2658 nodes involves understanding mechanisms outside the network layer. 2659 It also indicates the need to avoid designs which systematically drop 2660 packets; such designs might otherwise be considered favorably when 2661 making engineering tradeoffs. 2663 C. Example Scenarios 2665 This section shows example Registration Requests for several common 2666 scenarios. 2668 C.1. Registering with a Foreign Agent's Care-of Address 2670 The mobile node receives an Agent Advertisement from a foreign agent 2671 and wishes to register with that agent. The mobile node wishes only 2672 standard encapsulation, does not want broadcasts, and does not want 2673 simultaneous mobility bindings: 2675 IP fields: 2676 Source Address = mobile node's home address 2677 Destination Address = copied from the IP source address of the 2678 Agent Advertisement 2679 Time to Live = 1 2680 UDP fields: 2681 Source Port = 2682 Destination Port = 434 2683 Registration Request fields: 2684 Type = 1 2685 S=0,B=0,D=0,M=0,G=0 2686 Lifetime = the Lifetime copied from the Mobile Service 2687 Extension of the Agent Advertisement 2688 Home Address = the mobile node's home address 2689 Home Agent = IP address of mobile node's home agent 2690 Care-of Address = the Care-of Address copied from the Mobile 2691 Service Extension of the Agent Advertisement 2692 Identification = Network Time Protocol timestamp or Nonce 2693 Extensions: 2694 The Mobile-Home Authentication Extension 2696 C.2. Registering with a Dynamic Care-of Address 2698 The mobile node enters a foreign network that contains no foreign 2699 agents. The mobile node obtains an address from a DHCP server for 2700 use as its care-of address. The mobile node supports all forms of 2701 encapsulation, desires a copy of all broadcasts on the home network, 2702 and does not want simultaneous mobility bindings: 2704 IP fields: 2705 Source Address = care-of address obtained from DHCP server 2706 Destination Address = IP address of home agent 2707 Time to Live = 64 2708 UDP fields: 2709 Source Port = 2710 Destination Port = 434 2711 Registration Request fields: 2712 Type = 1 2713 S=0,B=1,D=1,M=1,G=1 2714 Lifetime = 1800 (seconds) 2715 Home Address = the mobile node's home address 2716 Home Agent = IP address of mobile node's home agent 2717 Care-of Address = care-of address obtained from DHCP server 2718 Identification = Network Time Protocol timestamp or Nonce 2719 Extensions: 2720 The Mobile-Home Authentication Extension 2722 C.3. Deregistration 2724 The mobile node returns home and wishes to deregister all care-of 2725 addresses with its home agent. 2727 IP fields: 2728 Source Address = mobile node's home address 2729 Destination Address = IP address of home agent 2730 Time to Live = 1 2731 UDP fields: 2732 Source Port = 2733 Destination Port = 434 2734 Registration Request fields: 2735 Type = 1 2736 S=0,B=0,D=0,M=0,G=0 2737 Lifetime = 0 2738 Home Address = the mobile node's home address 2739 Home Agent = IP address of mobile node's home agent 2740 Care-of Address = the mobile node's home address 2741 Identification = Network Time Protocol timestamp or Nonce 2742 Extensions: 2743 The Mobile-Home Authentication Extension 2745 D. Applicability of Prefix Lengths Extension 2747 Caution is indicated with the use of the Prefix Lengths extension 2748 over wireless links, due to the irregular coverage areas provided 2749 by many wireless transmitters. As a result, it is possible 2750 that two foreign agents advertising the same prefix might indeed 2751 provide different connectivity to prospective mobile nodes. The 2752 Prefix-Lengths Extension SHOULD NOT be included in the advertisements 2753 sent by agents in such a configuration. 2755 In the case of wireless interfaces, two different foreign agents 2756 would have to cooperate using special protocols to provide identical 2757 coverage in space, and thus be able to claim to have wireless 2758 interfaces situated on the same subnetwork. In the case of wired 2759 interfaces, a mobile node disconnecting and subsequently connecting 2760 to a new point of attachment to another may well send in a new 2761 registration request no matter whether the new advertisement is on 2762 the same medium as the last recorded advertisement. And, finally, 2763 in areas with dense populations of foreign agents it would seem 2764 unwise to require the propagation via routing protocols of the subnet 2765 prefixes associated with each individual wireless foreign agent; 2766 such a strategy could lead to quick depletion of available space 2767 for routing tables, unwarranted increases in the time required for 2768 processing routing updates, and longer decision times for route 2769 selection if routes (which are almost always unnecessary) are stored 2770 for wireless "subnets". 2772 References 2774 [1] Draft Standard, Wireless LAN MAC and PHY Specifications, Rev. 2775 D1. IEEE Document P802.11/D1-94/12, Dec 1994. 2777 [2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 2779 [3] S.M. Bellovin. Security Problems in the TCP/IP Protocol Suite. 2780 ACM Computer Communications Review, 19(2), March 1989. 2782 [4] Ramon Caceres and Liviu Iftode. The Effects of Mobility on 2783 Reliable Transport Protocols. In Proceedings of the 14th 2784 International Conference on Distributed Computing Systems, June 2785 1994. 2787 [5] Douglas E. Comer. Principles, Protocols, and Architecture, 2788 volume 1 of Internetworking with TCP/IP. Prentice Hall, 2789 Englewood Cliffs, N.J., second edition, 1991. 2791 [6] S. Deering. Host Extensions for IP Multicasting. RFC 1112, 2792 August 1989. 2794 [7] S. Deering. Router Discovery. RFC 1256, September 1991. 2796 [8] R. Droms. Dynamic Host Configuration Protocol. RFC 1541, 2797 October 1993. 2799 [9] D.E. Eastlake, S.D. Crocker, and J.I. Schiller. Randomness 2800 Requirements for Security. RFC 1750, December 1994. 2802 [10] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 2803 Encapsulation (GRE). RFC 1701, October 1994. 2805 [11] V. Jacobson. Compressing TCP/IP Headers for Low-Speed Serial 2806 Links. RFC 1144, February 1990. 2808 [12] K. McCloghrie and F. Kastenholz. Evolution of the Interfaces 2809 Group MIP-II. RFC 1573, January 1994. 2811 [13] G. McGregor. The PPP Internet Procotol Control Protocol (IPCP). 2812 RFC 1332, May 1992. 2814 [14] D. Mills. Network Time Protocol (Version 3). RFC 1305, March 2815 1992. 2817 [15] C. Perkins. IP Encapsulation within IP. Internet Draft -- work 2818 in progress, October 1995. 2820 [16] C. Perkins. Minimal Encapsulation within IP. Internet Draft -- 2821 work in progress, July 1995. 2823 [17] D. Plummer. An Ethernet Address Resolution Protocol. RFC 826, 2824 November 1982. 2826 [18] J. Postel. User Datagram Protocol. RFC 768, August 1980. 2828 [19] J. Postel. Internet Protocol. RFC 791, September 1981. 2830 [20] J. Reynolds and J. Postel. Assigned Numbers. RFC 1700, October 2831 1994. 2833 [21] R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 2834 1992. 2836 [22] W. Simpson (Editor). The Point-to-Point Protocol (PPP). RFC 2837 1661, July 1994. 2839 Chair's Addresses 2841 The working group can be contacted via the current chairs: 2843 Jim Solomon Tony Li 2844 Motorola, Inc. cisco systems 2845 1301 E. Algonquin Rd. 170 W. Tasman Dr. 2846 Schaumburg, IL 60196 San Jose, CA 95134 2848 Work: +1-708-576-2753 Work: +1-408-526-8186 2849 E-mail: solomon@comm.mot.com E-mail: tli@cisco.com 2851 Editor's Address 2853 Questions about this memo can also be directed to: 2855 Charles Perkins 2856 Room J1-A25 2857 T. J. Watson Research Center 2858 IBM Corporation 2859 30 Saw Mill River Rd. 2860 Hawthorne, NY 10532 2862 Work: +1-914-784-7350 2863 Fax: +1-914-784-7007 2864 E-mail: perk@watson.ibm.com