idnits 2.17.1 draft-ietf-mobileip-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-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 340: '... reserved and MUST NOT be used in a...' RFC 2119 keyword, line 473: '... A home agent MUST be able to attrac...' RFC 2119 keyword, line 479: '...'s home location MAY also be possible ...' RFC 2119 keyword, line 484: '... MUST be able to exchange datagrams ...' RFC 2119 keyword, line 493: '... the mobile node MAY also be possible ...' (419 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The second method uses network prefixes. The Prefix-Lengths Extension MAY be used in some cases by a mobile node to determine whether or not a newly received Agent Advertisement was received on the same subnet as the mobile node's current care-of address. If the prefixes differ, the mobile node MAY assume that it has moved. If a mobile node is currently using a foreign agent care-of address, the mobile node SHOULD NOT use this method of move detection unless both the current agent and the new agent include the Prefix-Lengths Extension in their respective Agent Advertisements; if this Extension is missing from one or both of the advertisements, this method of move detection SHOULD NOT be used. Similarly, if a mobile node is using a co-located care-of address, it SHOULD not use this method of move detection unless the new agent includes the Prefix-Lengths Extension in its Advertisement and the mobile node knows the network prefix of its current co-located care-of address. On the expiration of its current registration, if this method indicates that the mobile node has moved, rather than re-registering with its current care-of address, a mobile node MAY choose instead to register with a the foreign agent sending the new Advertisement with the different network prefix. The Agent Advertisement on which the new registration is based MUST NOT have expired according to its Lifetime field. -- 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 (12 November 1997) is 9655 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) ** Obsolete normative reference: RFC 1826 (ref. '1') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1750 (ref. '7') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1573 (ref. '11') (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1305 (ref. '13') (Obsoleted by RFC 5905) ** Downref: Normative reference to an Unknown state RFC: RFC 925 (ref. '18') ** Obsolete normative reference: RFC 1700 (ref. '20') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '21') -- Possible downref: Non-RFC (?) normative reference: ref. '23' Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Perkins, editor 3 INTERNET DRAFT Sun Microsystems 4 12 November 1997 6 IP Mobility Support version 2 7 draft-ietf-mobileip-v2-00.txt 9 Status of This Memo 11 This document is a submission by the Mobile IP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the mobile-ip@SmallWorks.COM mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 30 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 31 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 This document specifies protocol enhancements that allow transparent 36 routing of IP datagrams to mobile nodes in the Internet. Each 37 mobile node is always identified by its home address, regardless of 38 its current point of attachment to the Internet. While situated 39 away from its home, a mobile node is also associated with a 40 care-of address, which provides information about its current 41 point of attachment to the Internet. The protocol provides for 42 registering the care-of address with a home agent. The home agent 43 sends datagrams destined for the mobile node through a tunnel to 44 the care-of address. After arriving at the end of the tunnel, each 45 datagram is then delivered to the mobile node. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 54 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 1 55 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 1 56 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 2 58 1.5. New Architectural Entities . . . . . . . . . . . . . . . 3 59 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 61 1.8. Specification Language . . . . . . . . . . . . . . . . . 9 62 1.9. Message Format and Protocol Extensibility . . . . . . . . 10 64 2. Agent Discovery 12 65 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 12 66 2.1.1. Mobility Agent Advertisement Extension . . . . . 14 67 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . 16 68 2.1.3. One-byte Padding Extension . . . . . . . . . . . 17 69 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 17 70 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 17 71 2.3.1. Advertised Router Addresses . . . . . . . . . . . 18 72 2.3.2. Sequence Numbers and Rollover Handling . . . . . 19 73 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 19 74 2.4.1. Registration Required . . . . . . . . . . . . . . 20 75 2.4.2. Move Detection . . . . . . . . . . . . . . . . . 20 76 2.4.3. Returning Home . . . . . . . . . . . . . . . . . 21 77 2.4.4. Sequence Numbers and Rollover Handling . . . . . 22 79 3. Registration 23 80 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 23 81 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 24 82 3.3. Registration Request . . . . . . . . . . . . . . . . . . 25 83 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 27 84 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 30 85 3.5.1. Computing Authentication Extension Values . . . . 30 86 3.5.2. Mobile-Home Authentication Extension . . . . . . 31 87 3.5.3. Mobile-Foreign Authentication Extension . . . . . 31 88 3.5.4. Foreign-Home Authentication Extension . . . . . . 32 89 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 32 90 3.6.1. Sending Registration Requests . . . . . . . . . . 34 91 3.6.2. Receiving Registration Replies . . . . . . . . . 38 92 3.6.3. Registration Retransmission . . . . . . . . . . . 40 93 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 41 94 3.7.1. Configuration and Registration Tables . . . . . . 41 95 3.7.2. Receiving Registration Requests . . . . . . . . . 42 96 3.7.3. Receiving Registration Replies . . . . . . . . . 45 97 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 47 98 3.8.1. Configuration and Registration Tables . . . . . . 47 99 3.8.2. Receiving Registration Requests . . . . . . . . . 48 100 3.8.3. Sending Registration Replies . . . . . . . . . . 52 102 4. Routing Considerations 54 103 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 54 104 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 55 105 4.2.1. Mobile Node Considerations . . . . . . . . . . . 55 106 4.2.2. Foreign Agent Considerations . . . . . . . . . . 56 107 4.2.3. Home Agent Considerations . . . . . . . . . . . . 56 108 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 58 109 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 59 110 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 59 111 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 61 113 5. Security Considerations 66 114 5.1. Message Authentication Codes . . . . . . . . . . . . . . 66 115 5.2. Areas of Security Concern in this Protocol . . . . . . . 66 116 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 66 117 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 67 118 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 67 119 5.6. Replay Protection for Registration Requests . . . . . . . 67 120 5.6.1. Replay Protection using Timestamps . . . . . . . 68 121 5.6.2. Replay Protection using Nonces . . . . . . . . . 69 123 6. Acknowledgments 70 125 A. Patent Issues 71 126 A.1. IBM Patent #5,159,592 . . . . . . . . . . . . . . . . . . 71 127 A.2. IBM Patent #5,148,479 . . . . . . . . . . . . . . . . . . 71 129 B. Link-Layer Considerations 72 131 C. TCP Considerations 73 132 C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 73 133 C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 73 135 D. Example Scenarios 74 136 D.1. Registering with a Foreign Agent Care-of Address . . . . 74 137 D.2. Registering with a Co-Located Care-of Address . . . . . . 74 138 D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 75 140 E. Applicability of Prefix Lengths Extension 75 142 1. Introduction 144 IP version 4 assumes that a node's IP address uniquely identifies the 145 node's point of attachment to the Internet. Therefore, a node must 146 be located on the network indicated by its IP address in order to 147 receive datagrams destined to it; otherwise, datagrams destined to 148 the node would be undeliverable. For a node to change its point of 149 attachment without losing its ability to communicate, currently one 150 of the two following mechanisms must 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 (mobile) computers. 164 A new, scalable, mechanism is required for accommodating node 165 mobility within the Internet. This document defines such a 166 mechanism, which enables nodes to change their point of attachment to 167 the Internet without changing their IP address. 169 1.1. Protocol Requirements 171 A mobile node must be able to communicate with other nodes after 172 changing its link-layer point of attachment to the Internet, yet 173 without changing its IP address. 175 A mobile node must be able to communicate with other nodes that do 176 not implement these mobility functions. No protocol enhancements are 177 required in hosts or routers that are not acting as any of the new 178 architectural entities introduced in Section 1.5. 180 All messages used to update another node as to the location of a 181 mobile node must be authenticated in order to protect against remote 182 redirection attacks. 184 1.2. Goals 186 The link by which a mobile node is directly attached to the 187 Internet may often be a wireless link. This link may thus have a 188 substantially lower bandwidth and higher error rate than traditional 189 wired networks. Moreover, mobile nodes are likely to be battery 190 powered, and minimizing power consumption is important. Therefore, 191 the number of administrative messages sent over the link by which a 192 mobile node is directly attached to the Internet should be minimized, 193 and the size of these messages should be kept as small as is 194 reasonably possible. 196 1.3. Assumptions 198 The protocols defined in this document place no additional 199 constraints on the assignment of IP addresses. That is, a mobile 200 node can be assigned an IP address by the organization that owns the 201 machine. 203 This protocol assumes that mobile nodes will generally not change 204 their point of attachment to the Internet more frequently than once 205 per second. 207 This protocol assumes that IP unicast datagrams are routed based on 208 the destination address in the datagram header (and not, for example, 209 by source address). 211 1.4. Applicability 213 Mobile IP is intended to enable nodes to move from one IP subnet to 214 another. It is just as suitable for mobility across homogeneous 215 media as it is for mobility across heterogeneous media. That is, 216 Mobile IP facilitates node movement from one Ethernet segment to 217 another as well as it accommodates node movement from an Ethernet 218 segment to a wireless LAN, as long as the mobile node's IP address 219 remains the same after such a movement. 221 One can think of Mobile IP as solving the "macro" mobility management 222 problem. It is less well suited for more "micro" mobility management 223 applications -- for example, handoff amongst wireless transceivers, 224 each of which covers only a very small geographic area. As long 225 as node movement does not occur between points of attachment on 226 different IP subnets, link-layer mechanisms for mobility (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 the following 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. A mobile node may change its 238 location without changing its IP address; it may continue to 239 communicate with other Internet nodes at any location using its 240 (constant) IP address, assuming link-layer connectivity to a 241 point of attachment is available. 243 Home Agent 245 A router on a mobile node's home network which tunnels 246 datagrams for delivery to the mobile node when it is away from 247 home, and maintains current location information for the mobile 248 node. 250 Foreign Agent 252 A router on a mobile node's visited network which provides 253 routing services to the mobile node while registered. The 254 foreign agent detunnels and delivers datagrams to the mobile 255 node that were tunneled by the mobile node's home agent. For 256 datagrams sent by a mobile node, the foreign agent may serve as 257 a default router for registered mobile nodes. 259 A mobile node is given a long-term IP address on a home network. 260 This home address is administered in the same way as a "permanent" IP 261 address is provided to a stationary host. When away from its home 262 network, a "care-of address" is associated with the mobile node and 263 reflects the mobile node's current point of attachment. The mobile 264 node uses its home address as the source address of all IP datagrams 265 that it sends, except where otherwise described in this document for 266 datagrams sent for certain mobility management functions (e.g., as in 267 Section 3.6.1.1). 269 1.6. Terminology 271 This document frequently uses the following terms: 273 Agent Advertisement 274 An advertisement message constructed by attaching a 275 special Extension to a router advertisement [5] message. 277 Care-of Address 278 The termination point of a tunnel toward a mobile node, 279 for datagrams forwarded to the mobile node while it is 280 away from home. The protocol can use two different types 281 of care-of address: a "foreign agent care-of address" is 282 an address of a foreign agent with which the mobile node 283 is registered, and a "co-located care-of address" is an 284 externally obtained local address which the mobile node 285 has associated with one of its own network interfaces. 287 Correspondent Node 288 A peer with which a mobile node is communicating. A 289 correspondent node may be either mobile or stationary. 291 Foreign Network 292 Any network other than the mobile node's Home Network. 294 Home Address 295 An IP address that is assigned for an extended period of 296 time to a mobile node. It remains unchanged regardless 297 of where the node is attached to the Internet. 299 Home Network 300 A network, possibly virtual, having a network prefix 301 matching that of a mobile node's home address. Note that 302 standard IP routing mechanisms will deliver datagrams 303 destined to a mobile node's Home Address to the mobile 304 node's Home Network. 306 Link A facility or medium over which nodes can communicate at 307 the link layer. A link underlies the network layer. 309 Link-Layer Address 310 The address used to identify an endpoint of some 311 communication over a physical link. Typically, the 312 Link-Layer address is an interface's Media Access Control 313 (MAC) address. 315 Mobility Agent 316 Either a home agent or a foreign agent. 318 Mobility Binding 319 The association of a home address with a care-of address, 320 along with the remaining lifetime of that association. 322 Mobility Security Association 323 A collection of security contexts, between a pair 324 of nodes, which may be applied to Mobile IP protocol 325 messages exchanged between them. Each context indicates 326 an authentication algorithm and mode (Section 5.1), a 327 secret (a shared key, or appropriate public/private 328 key pair), and a style of replay protection in use 329 (Section 5.6). 331 Node A host or a router. 333 Nonce A randomly chosen value, different from previous choices, 334 inserted in a message to protect against replays. 336 Security Parameter Index (SPI) 337 An index identifying a security context between a pair 338 of nodes among the contexts available in the Mobility 339 Security Association. SPI values 0 through 255 are 340 reserved and MUST NOT be used in any Mobility Security 341 Association. 343 Tunnel The path followed by a datagram while it is encapsulated. 344 The model is that, while it is encapsulated, a datagram 345 is routed to a knowledgeable decapsulating agent, which 346 decapsulates the datagram and then correctly delivers it 347 to its ultimate destination. 349 Virtual Network 350 A network with no physical instantiation beyond a router 351 (with a physical network interface on another network). 352 The router (e.g., a home agent) generally advertises 353 reachability to the virtual network using conventional 354 routing protocols. 356 Visited Network 357 A network other than a mobile node's Home Network, to 358 which the mobile node is currently connected. 360 Visitor List 361 The list of mobile nodes visiting a foreign agent. 363 1.7. Protocol Overview 365 The following support services are defined for Mobile IP: 367 Agent Discovery 368 Home agents and foreign agents may advertise their 369 availability on each link for which they provide service. 370 A newly arrived mobile node can send a solicitation on 371 the link to learn if any prospective agents are present. 373 Registration 374 When the mobile node is away from home, it registers 375 its care-of address with its home agent. Depending on 376 its method of attachment, the mobile node will register 377 either directly with its home agent, or through a foreign 378 agent which forwards the registration to the home agent. 380 The following steps provide a rough outline of operation of the 381 Mobile IP protocol: 383 - Mobility agents (i.e., foreign agents and home agents) advertise 384 their presence via Agent Advertisement messages (Section 2). A 385 mobile node may optionally solicit an Agent Advertisement message 386 from any locally attached mobility agents through an Agent 387 Solicitation message. 389 - A mobile node receives these Agent Advertisements and determines 390 whether it is on its home network or a foreign network. 392 - When the mobile node detects that it is located on its home 393 network, it operates without mobility services. If returning 394 to its home network from being registered elsewhere, the mobile 395 node deregisters with its home agent, through exchange of a 396 Registration Request and Registration Reply message with it. 398 - When a mobile node detects that it has moved to a foreign 399 network, it obtains a care-of address on the foreign network. 400 The care-of address can either be determined from a foreign 401 agent's advertisements (a foreign agent care-of address), or by 402 some external assignment mechanism such as DHCP [6] (a co-located 403 care-of address). 405 - The mobile node operating away from home then registers its 406 new care-of address with its home agent through exchange of a 407 Registration Request and Registration Reply message with it, 408 possibly via a foreign agent (Section 3). 410 - Datagrams sent to the mobile node's home address are intercepted 411 by its home agent, tunneled by the home agent to the mobile 412 node's care-of address, received at the tunnel endpoint (either 413 at a foreign agent or at the mobile node itself), and finally 414 delivered to the mobile node (Section 4.2.3). 416 - In the reverse direction, datagrams sent by the mobile node 417 are generally delivered to their destination using standard IP 418 routing mechanisms, not necessarily passing through the home 419 agent. 421 When away from home, Mobile IP uses protocol tunneling to hide a 422 mobile node's home address from intervening routers between its 423 home network and its current location. The tunnel terminates at 424 the mobile node's care-of address. The care-of address must be an 425 address to which datagrams can be delivered via conventional IP 426 routing. At the care-of address, the original datagram is removed 427 from the tunnel and delivered to the mobile node. 429 Mobile IP provides two alternative modes for the acquisition of a 430 care-of address: 432 - A "foreign agent care-of address" is a care-of address provided 433 by a foreign agent through its Agent Advertisement messages. In 434 this case, the care-of address is an IP address of the foreign 435 agent. In this mode, the foreign agent is the endpoint of the 436 tunnel and, upon receiving tunneled datagrams, decapsulates them 437 and delivers the inner datagram to the mobile node. This mode 438 of acquisition is preferred because it allows many mobile nodes 439 to share the same care-of address and therefore does not place 440 unnecessary demands on the already limited IPv4 address space. 442 - A "co-located care-of address" is a care-of address acquired 443 by the mobile node as a local IP address through some external 444 means, which the mobile node then associates with one of its own 445 network interfaces. The address may be dynamically acquired as 446 a temporary address by the mobile node such as through DHCP [6], 447 or may be owned by the mobile node as a long-term address for its 448 use only while visiting some foreign network. Specific external 449 methods of acquiring a local IP address for use as a co-located 450 care-of address are beyond the scope of this document. When 451 using a co-located care-of address, the mobile node serves as the 452 endpoint of the tunnel and itself performs decapsulation of the 453 datagrams tunneled to it. 455 The mode of using a co-located care-of address has the advantage 456 that it allows a mobile node to function without a foreign agent, 457 for example, in networks that have not yet deployed a foreign agent. 458 It does, however, place additional burden on the IPv4 address space 459 because it requires a pool of addresses within the foreign network 460 to be made available to visiting mobile nodes. It is difficult to 461 efficiently maintain pools of addresses for each subnet that may 462 permit mobile nodes to visit. 464 It is important to understand the distinction between the care-of 465 address and the foreign agent functions. The care-of address is 466 simply the endpoint of the tunnel. It might indeed be an address 467 of a foreign agent (a foreign agent care-of address), but it might 468 instead be an address temporarily acquired by the mobile node (a 469 co-located care-of address). A foreign agent, on the other hand, 470 is a mobility agent that provides services to mobile nodes. See 471 Sections 3.7 and 4.2.2 for additional details. 473 A home agent MUST be able to attract and intercept datagrams that 474 are destined to the home address of any of its registered mobile 475 nodes. Using the proxy and gratuitous ARP mechanisms described in 476 Section 4.6, this requirement can be satisfied if the home agent has 477 a network interface on the link indicated by the mobile node's home 478 address. Other placements of the home agent relative to the mobile 479 node's home location MAY also be possible using other mechanisms for 480 intercepting datagrams destined to the mobile node's home address. 481 Such placements are beyond the scope of this document. 483 Similarly, a mobile node and a prospective or current foreign agent 484 MUST be able to exchange datagrams without relying on standard IP 485 routing mechanisms; that is, those mechanisms which make forwarding 486 decisions based upon the network-prefix of the destination address 487 in the IP header. This requirement can be satisfied if the foreign 488 agent and the visiting mobile node have an interface on the same 489 link. In this case, the mobile node and foreign agent simply 490 bypass their normal IP routing mechanism when sending datagrams to 491 each other, addressing the underlying link-layer packets to their 492 respective link-layer addresses. Other placements of the foreign 493 agent relative to the mobile node MAY also be possible using other 494 mechanisms to exchange datagrams between these nodes, but such 495 placements are beyond the scope of this document. 497 If a mobile node is using a co-located care-of address (as described 498 in (b) above), the mobile node MUST be located on the link identified 499 by the network prefix of this care-of address. Otherwise, datagrams 500 destined to the care-of address would be undeliverable. 502 For example, the figure below illustrates the routing of datagrams 503 to and from a mobile node away from home, once the mobile node has 504 registered with its home agent. In the figure below, the mobile node 505 is using a foreign agent care-of address: 507 2) Datagram is intercepted 3) Datagram is 508 by home agent and detunneled and 509 is tunneled to the delivered to the 510 care-of address. mobile node. 512 +-----+ +-------+ +------+ 513 |home | =======> |foreign| ------> |mobile| 514 |agent| | agent | <------ | node | 515 +-----+ +-------+ +------+ 516 1) Datagram to /|\ / 517 mobile node | / 4) For datagrams sent by the 518 arrives on | / mobile node, standard IP 519 home network | / routing delivers each to its 520 via standard | |_ destination. In this figure, 521 IP routing. +----+ the foreign agent is the 522 |host| mobile node's default router. 523 +----+ 525 1.8. Specification Language 527 In this document, several words are used to signify the requirements 528 of the specification. These words are often capitalized. 530 MUST This word, or the adjective "required", means that 531 the definition is an absolute requirement of the 532 specification. 534 MUST NOT This phrase means that the definition is an absolute 535 prohibition of the specification. 537 SHOULD This word, or the adjective "recommended", means 538 that, in some circumstances, valid reasons may exist 539 to ignore this item, but the full implications must 540 be understood and carefully weighed before choosing 541 a different course. Unexpected results may result 542 otherwise. 544 MAY This word, or the adjective "optional", means that this 545 item is one of an allowed set of alternatives. An 546 implementation which does not include this option MUST 547 be prepared to interoperate with another implementation 548 which does include the option. 550 silently discard 551 The implementation discards the datagram without 552 further processing, and without indicating an error 553 to the sender. The implementation SHOULD provide the 554 capability of logging the error, including the contents 555 of the discarded datagram, and SHOULD record the event 556 in a statistics counter. 558 1.9. Message Format and Protocol Extensibility 560 Mobile IP defines a set of new control messages, sent with UDP [17] 561 using well-known port number 434. Currently, the following two 562 message types are defined: 564 1 Registration Request 565 3 Registration Reply 567 Up-to-date values for the message types for Mobile IP control 568 messages are specified in the most recent "Assigned Numbers" [20]. 570 In addition, for Agent Discovery, Mobile IP makes use of the existing 571 Router Advertisement and Router Solicitation messages defined for 572 ICMP Router Discovery [5]. 574 Mobile IP defines a general Extension mechanism to allow optional 575 information to be carried by Mobile IP control messages or by ICMP 576 Router Discovery messages. Each of these Extensions (with one 577 exception) is encoded in the following Type-Length-Value format: 579 0 1 2 580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 582 | Type | Length | Data ... 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 585 Type Indicates the particular type of Extension. 587 Length Indicates the length (in bytes) of the data field within 588 this Extension. The length does NOT include the Type and 589 Length bytes. 591 Data The particular data associated with this Extension. This 592 field may be zero or more bytes in length. The format 593 and length of the data field is determined by the type 594 and length fields. 596 Extensions allow variable amounts of information to be carried within 597 each datagram. The end of the list of Extensions is indicated by the 598 total length of the IP datagram. 600 Two separately maintained sets of numbering spaces, from which 601 Extension Type values are allocated, are used in Mobile IP: 603 - The first set consists of those Extensions which may appear only 604 in Mobile IP control messages (those sent to and from UDP port 605 number 434). Currently, the following Types are defined for 606 Extensions appearing in Mobile IP control messages: 608 32 Mobile-Home Authentication 609 33 Mobile-Foreign Authentication 610 34 Foreign-Home Authentication 612 - The second set consists of those extensions which may appear only 613 in ICMP Router Discovery messages [5]. Currently, Mobile IP 614 defines the following Types for Extensions appearing in ICMP 615 Router Discovery messages: 617 0 One-byte Padding (encoded with no Length nor Data field) 618 16 Mobility Agent Advertisement 619 19 Prefix-Lengths 621 Each individual Extension is described in detail in a separate 622 section later in this document. Up-to-date values for these 623 Extension Type numbers are specified in the most recent "Assigned 624 Numbers" [20]. 626 Due to the separation (orthogonality) of these sets, it is 627 conceivable that two Extensions that are defined at a later date 628 could have identical Type values, so long as one of the Extensions 629 may be used only in Mobile IP control messages and the other may be 630 used only in ICMP Router Discovery messages. 632 When an Extension numbered in either of these sets within the range 0 633 through 127 is encountered but not recognized, the message containing 634 that Extension MUST be silently discarded. When an Extension 635 numbered in the range 128 through 255 is encountered which is not 636 recognized, that particular Extension is ignored, but the rest of 637 the Extensions and message data MUST still be processed. The Length 638 field of the Extension is used to skip the Data field in searching 639 for the next Extension. 641 2. Agent Discovery 643 Agent Discovery is the method by which a mobile node determines 644 whether it is currently connected to its home network or to a foreign 645 network, and by which a mobile node can detect when it has moved 646 from one network to another. When connected to a foreign network, 647 the methods specified in this section also allow the mobile node to 648 determine the foreign agent care-of address being offered by each 649 foreign agent on that network. 651 Mobile IP extends ICMP Router Discovery [5] as its primary 652 mechanism for Agent Discovery. An Agent Advertisement is formed by 653 including a Mobility Agent Advertisement Extension in an ICMP Router 654 Advertisement message (Section 2.1). An Agent Solicitation message 655 is identical to an ICMP Router Solicitation, except that its IP TTL 656 MUST be set to 1 (Section 2.2). This section describes the message 657 formats and procedures by which mobile nodes, foreign agents, and 658 home agents cooperate to realize Agent Discovery. 660 Agent Advertisement and Agent Solicitation may not be necessary 661 for link layers that already provide this functionality. The 662 method by which mobile nodes establish link-layer connections 663 with prospective agents is outside the scope of this document (but 664 see Appendix B). The procedures described below assume that such 665 link-layer connectivity has already been established. 667 No authentication is required for Agent Advertisement and Agent 668 Solicitation messages. They MAY be authenticated using the IP 669 Authentication Header [1], which is unrelated to the messages 670 described in this document. Further specification of the way in 671 which Advertisement and Solicitation messages may be authenticated is 672 outside of the scope of this document. 674 2.1. Agent Advertisement 676 Agent Advertisements are transmitted by a mobility agent to advertise 677 its services on a link. Mobile nodes use these advertisements to 678 determine their current point of attachment to the Internet. An 679 Agent Advertisement is an ICMP Router Advertisement that has been 680 extended to also carry an Mobility Agent Advertisement Extension 681 (Section 2.1.1) and, optionally, a Prefix-Lengths Extension 682 (Section 2.1.2), One-byte Padding Extension (Section 2.1.3), or other 683 Extensions that might be defined in the future. 685 Within an Agent Advertisement message, ICMP Router Advertisement 686 fields of the message are required to conform to the following 687 additional specifications: 689 - Link-Layer Fields 691 Destination Address 692 The link-layer destination address of a unicast 693 Agent Advertisement MUST be the same as the source 694 link-layer address of the Agent Solicitation which 695 prompted the Advertisement. 697 - IP Fields 699 TTL The TTL for all Agent Advertisements MUST be set 700 to 1. 702 Destination Address 703 As specified for ICMP Router Discovery [5], the IP 704 destination address of an Agent Advertisement MUST 705 be either the "all systems on this link" multicast 706 address (224.0.0.1) [4] or the "limited broadcast" 707 address (255.255.255.255). The subnet-directed 708 broadcast address of the form .<-1> cannot be 709 used since mobile nodes will not generally know the 710 prefix of the foreign network. 712 - ICMP Fields 714 Code The Code field of the agent advertisement is 715 interpreted as follows: 717 0 The mobility agent handles common traffic -- that 718 is, it acts as a router for IP datagrams not 719 necessarily related to mobile nodes. 720 16 The mobility agent does not route common traffic. 721 However, all foreign agents MUST (minimally) 722 forward to a default router any datagrams received 723 from a registered mobile node (Section 4.2.2). 725 Lifetime 726 The maximum length of time that the Advertisement 727 is considered valid in the absence of further 728 Advertisements. 730 Router Address(es) 731 See Section 2.3.1 for a discussion of the addresses 732 that may appear in this portion of the Agent 733 Advertisement. 735 Num Addrs 736 The number of Router Addresses advertised in this 737 message. Note that in an Agent Advertisement 738 message, the number of router addresses specified in 739 the ICMP Router Advertisement portion of the message 740 MAY be set to 0. See Section 2.3.1 for details. 742 If sent periodically, the nominal interval at which Agent 743 Advertisements are sent SHOULD be 1/3 of the advertisement Lifetime 744 given in the ICMP header. This allows a mobile node to miss three 745 successive advertisements before deleting the agent from its list of 746 valid agents. The actual transmission time for each advertisement 747 SHOULD be slightly randomized [5] in order to avoid synchronization 748 and subsequent collisions with other Agent Advertisements that may 749 be sent by other agents (or with other Router Advertisements sent 750 by other routers). Note that this field has no relation to the 751 "Registration Lifetime" field within the Mobility Agent Advertisement 752 Extension defined below. 754 2.1.1. Mobility Agent Advertisement Extension 756 The Mobility Agent Advertisement Extension follows the ICMP Router 757 Advertisement fields. It is used to indicate that an ICMP Router 758 Advertisement message is also an Agent Advertisement being sent by 759 a mobility agent. The Mobility Agent Advertisement Extension is 760 defined as follows: 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Type | Length | Sequence Number | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Registration Lifetime |R|B|H|F|M|G|V| reserved | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | zero or more Care-of Addresses | 770 | ... | 772 Type 16 774 Length (6 + 4*N), where N is the number of care-of addresses 775 advertised. 777 Sequence Number 778 The count of Agent Advertisement messages sent since the 779 agent was initialized (Section 2.3.2). 781 Registration Lifetime 782 The longest lifetime (measured in seconds) that this 783 agent is willing to accept in any Registration Request. 784 A value of 0xffff indicates infinity. This field has no 785 relation to the "Lifetime" field within the ICMP Router 786 Advertisement portion of the Agent Advertisement. 788 R Registration required. Registration with this foreign 789 agent (or another foreign agent on this link) is required 790 even when using a co-located care-of address. 792 B Busy. The foreign agent will not accept registrations 793 from additional mobile nodes. 795 H Home agent. This agent offers service as a home agent 796 on the link on which this Agent Advertisement message is 797 sent. 799 F Foreign agent. This agent offers service as a foreign 800 agent on the link on which this Agent Advertisement 801 message is sent. 803 M Minimal encapsulation. This agent implements receiving 804 tunneled datagrams that use minimal encapsulation [15]. 806 G GRE encapsulation. This agent implements receiving 807 tunneled datagrams that use GRE encapsulation [8]. 809 V Van Jacobson header compression. This agent supports use 810 of Van Jacobson header compression [10] over the link 811 with any registered mobile node. 813 reserved 814 Sent as zero; ignored on reception. 816 Care-of Address(es) 817 The advertised foreign agent care-of address(es) provided 818 by this foreign agent. An Agent Advertisement MUST 819 include at least one care-of address if the 'F' bit 820 is set. The number of care-of addresses present is 821 determined by the Length field in the Extension. 823 A home agent MUST always be prepared to serve the mobile nodes for 824 which it is the home agent. A foreign agent may at times be too busy 825 to serve additional mobile nodes; even so, it must continue to send 826 Agent Advertisements, so that any mobile nodes already registered 827 with it will know that they have not moved out of range of the 828 foreign agent and that the foreign agent has not failed. A foreign 829 agent may indicate that it is "too busy" to allow new mobile nodes to 830 register with it, by setting the 'B' bit in its Agent Advertisements. 831 An Agent Advertisement message MUST NOT have the 'B' bit set if the 832 'F' bit is not also set, and at least one of the 'F' bit and the 'H' 833 bit MUST be set in any Agent Advertisement message sent. 835 When a foreign agent wishes to require registration even from those 836 mobile nodes which have acquired a co-located care-of address, it 837 sets the 'R' bit to one. Because this bit applies only to foreign 838 agents, an agent MUST NOT set the 'R' bit to one unless the 'F' bit 839 is also set to one. 841 2.1.2. Prefix-Lengths Extension 843 The Prefix-Lengths Extension MAY follow the Mobility Agent 844 Advertisement Extension. It is used to indicate the number of bits 845 of network prefix that applies to each Router Address listed in the 846 ICMP Router Advertisement portion of the Agent Advertisement. Note 847 that the prefix lengths given DO NOT apply to care-of address(es) 848 listed in the Mobility Agent Advertisement Extension. The 849 Prefix-Lengths Extension is defined as follows: 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Type | Length | Prefix Length | .... 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Type 19 (Prefix-Lengths Extension) 859 Length N, where N is the value (possibly zero) of the Num Addrs 860 field in the ICMP Router Advertisement portion of the 861 Agent Advertisement. 863 Prefix Length(s) 864 The number of leading bits that define the network number 865 of the corresponding Router Address listed in the ICMP 866 Router Advertisement portion of the message. The prefix 867 length for each Router Address is encoded as a separate 868 byte, in the order that the Router Addresses are listed 869 in the ICMP Router Advertisement portion of the message. 871 See Section 2.4.2 for information about how the Prefix Lengths 872 Extension MAY be used by a mobile node when determining whether it 873 has moved. See Appendix E for implementation details about the use 874 of this Extension. 876 2.1.3. One-byte Padding Extension 878 Some IP protocol implementations insist upon padding ICMP messages 879 to an even number of bytes. If the ICMP length of an Agent 880 Advertisement is odd, this Extension MAY be included in order to make 881 the ICMP length even. Note that this Extension is NOT intended to 882 be a general-purpose Extension to be included in order to word- or 883 long-align the various fields of the Agent Advertisement. An Agent 884 Advertisement SHOULD NOT include more than one One-byte Padding 885 Extension and if present, this Extension SHOULD be the last Extension 886 in the Agent Advertisement. 888 Note that unlike other Extensions used in Mobile IP, the One-byte 889 Padding Extension is encoded as a single byte, with no "Length" nor 890 "Data" field present. The One-byte Padding Extension is defined as 891 follows: 893 0 1 2 3 4 5 6 7 894 +-+-+-+-+-+-+-+-+ 895 | Type | 896 +-+-+-+-+-+-+-+-+ 898 Type 0 (One-byte Padding Extension) 900 2.2. Agent Solicitation 902 An Agent Solicitation is identical to an ICMP Router Solicitation 903 with the further restriction that the IP TTL Field MUST be set to 1. 905 2.3. Foreign Agent and Home Agent Considerations 907 Any mobility agent which cannot be discovered by a link-layer 908 protocol MUST send Agent Advertisements. An agent which can be 909 discovered by a link-layer protocol SHOULD also implement Agent 910 Advertisements. However, the Advertisements need not be sent, 911 except when the site policy requires registration with the agent 912 (i.e., when the 'R' bit is set), or as a response to a specific 913 Agent Solicitation. All mobility agents SHOULD respond to Agent 914 Solicitations. 916 The same procedures, defaults, and constants are used in Agent 917 Advertisement messages and Agent Solicitation messages as specified 918 for ICMP Router Discovery [5], except that: 920 - a mobility agent MUST limit the rate at which it sends broadcast 921 or multicast Agent Advertisements; a recommended maximum rate is 922 once per second, AND 924 - a mobility agent that receives a Router Solicitation MUST NOT 925 require that the IP Source Address is the address of a neighbor 926 (i.e., an address that matches one of the router's own addresses 927 on the arrival interface, under the subnet mask associated with 928 that address of the router). 930 - a mobility agent MAY be configured to send Agent Advertisements 931 only in response to an Agent Solicitation message. 933 If the home network is not a virtual network, then the home agent 934 for any mobile node SHOULD be located on the link identified by the 935 mobile node's home address, and Agent Advertisement messages sent by 936 the home agent on this link MUST have the 'H' bit set. In this way, 937 mobile nodes on their own home network will be able to determine that 938 they are indeed at home. Any Agent Advertisement messages sent by 939 the home agent on another link to which it may be attached (if it is 940 a mobility agent serving more than one link), MUST NOT have the 'H' 941 bit set, unless the home agent also serves as a home agent (to other 942 mobile nodes) on that other link. A mobility agent MAY use different 943 settings for each of the 'R', 'H', and 'F' bits on different network 944 interfaces. 946 If the home network is a virtual network, the home network has no 947 physical realization external to the home agent itself. In this 948 case, there is no physical network link on which to send Agent 949 Advertisement messages advertising the home agent. Mobile nodes for 950 which this is the home network are always treated as being away from 951 home. 953 On a particular subnet, either all mobility agents MUST include 954 the Prefix-Lengths Extension or all of them MUST NOT include this 955 Extension. Equivalently, it is prohibited for some agents on a given 956 subnet to include the Extension but for others not to include it. 957 Otherwise, one of the move detection algorithms designed for mobile 958 nodes will not function properly (Section 2.4.2). 960 2.3.1. Advertised Router Addresses 962 The ICMP Router Advertisement portion of the Agent Advertisement MAY 963 contain one or more router addresses. An agent SHOULD only put its 964 own addresses, if any, in the advertisement. Whether or not its own 965 address appears in the Router Addresses, a foreign agent MUST route 966 datagrams it receives from registered mobile nodes (Section 4.2.2). 968 2.3.2. Sequence Numbers and Rollover Handling 970 The sequence number in Agent Advertisements ranges from 0 to 971 0xffff. After booting, an agent MUST use the number 0 for its first 972 advertisement. Each subsequent advertisement MUST use the sequence 973 number one greater, with the exception that the sequence number 974 0xffff MUST be followed by sequence number 256. In this way, mobile 975 nodes can distinguish reductions in sequence numbers that result from 976 reboots, from reductions that result in rollover of the sequence 977 number after it attains the value 0xffff. 979 2.4. Mobile Node Considerations 981 Every mobile node MUST implement Agent Solicitation. Solicitations 982 SHOULD only be sent in the absence of Agent Advertisements and when a 983 care-of address has not been determined through a link-layer protocol 984 or other means. The mobile node uses the same procedures, defaults, 985 and constants for Agent Solicitation as specified for ICMP Router 986 Solicitation messages [5], except that the mobile node MAY solicit 987 more often than once every three seconds, and that a mobile node that 988 is currently not connected to any foreign agent MAY solicit more 989 times than MAX_SOLICITATIONS. 991 The rate at which a mobile node sends Solicitations MUST be 992 limited by the mobile node. The mobile node MAY send three initial 993 Solicitations at a maximum rate of one per second while searching for 994 an agent. After this, the rate at which Solicitations are sent MUST 995 be reduced so as to limit the overhead on the local link. Subsequent 996 Solicitations MUST be sent using a binary exponential backoff 997 mechanism, doubling the interval between consecutive Solicitations, 998 up to a maximum interval. The maximum interval SHOULD be chosen 999 appropriately based upon the characteristics of the media over which 1000 the mobile node is soliciting. This maximum interval SHOULD be at 1001 least one minute between Solicitations. 1003 While still searching for an agent, the mobile node MUST NOT increase 1004 the rate at which it sends Solicitations unless it has received 1005 a positive indication that it has moved to a new link. After 1006 successfully registering with an agent, the mobile node SHOULD 1007 also increase the rate at which it will send Solicitations when it 1008 next begins searching for a new agent with which to register. The 1009 increased solicitation rate MAY revert to the maximum rate, but then 1010 MUST be limited in the manner described above. In all cases, the 1011 recommended solicitation intervals are nominal values. Mobile nodes 1012 MUST randomize their solicitation times around these nominal values 1013 as specified for ICMP Router Discovery [5]. 1015 Mobile nodes MUST process received Agent Advertisements. A mobile 1016 node can distinguish an Agent Advertisement message from other uses 1017 of the ICMP Router Advertisement message by examining the number 1018 of advertised addresses and the IP Total Length field. When the 1019 IP total length indicates that the ICMP message is longer than 1020 needed for the number of advertised addresses, the remaining data is 1021 interpreted as one or more Extensions. The presence of a Mobility 1022 Agent Advertisement Extension identifies the advertisement as an 1023 Agent Advertisement. 1025 When multiple methods of agent discovery are in use, the mobile node 1026 SHOULD first attempt registration with agents including Mobility 1027 Agent Advertisement Extensions in their advertisements, in preference 1028 to those discovered by other means. This preference maximizes 1029 the likelihood that the registration will be recognized, thereby 1030 minimizing the number of registration attempts. 1032 A mobile node MUST ignore reserved bits in Agent Advertisements, as 1033 opposed to discarding such advertisements. In this way, new bits 1034 can be defined later, without affecting the ability for mobile nodes 1035 to use the advertisements even when the newly defined bits are not 1036 understood. 1038 2.4.1. Registration Required 1040 When the mobile node receives an Agent Advertisement with the 'R' 1041 bit set, the mobile node SHOULD register through the foreign agent, 1042 even when the mobile node might be able to acquire its own co-located 1043 care-of address. This feature is intended to allow sites to enforce 1044 visiting policies (such as accounting) which require exchanges of 1045 authorization. 1047 If formerly reserved bits require some kind of monitoring/enforcement 1048 at the foreign link, foreign agents implementing the new 1049 specification for the formerly reserved bits can set the 'R' bit. 1050 This has the effect of forcing the mobile node to register through 1051 the foreign agent, so the foreign agent could then monitor/enforce 1052 the policy. 1054 2.4.2. Move Detection 1056 Two primary mechanisms are provided for mobile nodes to detect when 1057 they have moved from one subnet to another. Other mechanisms MAY 1058 also be used. When the mobile node detects that it has moved, it 1059 SHOULD register (Section 3) with a suitable care-of address on the 1060 new foreign network. However, the mobile node MUST NOT register 1061 more frequently than once per second on average, as specified in 1062 Section 3.6.3. 1064 2.4.2.1. Algorithm 1 1066 The first method of move detection is based upon the Lifetime field 1067 within the main body of the ICMP Router Advertisement portion of 1068 the Agent Advertisement. A mobile node SHOULD record the Lifetime 1069 received in any Agent Advertisements, until that Lifetime expires. 1070 If the mobile node fails to receive another advertisement from the 1071 same agent within the specified Lifetime, it SHOULD assume that it 1072 has lost contact with that agent. If the mobile node has previously 1073 received an Agent Advertisement from another agent for which the 1074 Lifetime field has not yet expired, the mobile node MAY immediately 1075 attempt registration with that other agent. Otherwise, the mobile 1076 node SHOULD attempt to discover a new agent with which to register. 1078 2.4.2.2. Algorithm 2 1080 The second method uses network prefixes. The Prefix-Lengths 1081 Extension MAY be used in some cases by a mobile node to determine 1082 whether or not a newly received Agent Advertisement was received on 1083 the same subnet as the mobile node's current care-of address. If the 1084 prefixes differ, the mobile node MAY assume that it has moved. If 1085 a mobile node is currently using a foreign agent care-of address, 1086 the mobile node SHOULD NOT use this method of move detection unless 1087 both the current agent and the new agent include the Prefix-Lengths 1088 Extension in their respective Agent Advertisements; if this Extension 1089 is missing from one or both of the advertisements, this method of 1090 move detection SHOULD NOT be used. Similarly, if a mobile node is 1091 using a co-located care-of address, it SHOULD not use this method 1092 of move detection unless the new agent includes the Prefix-Lengths 1093 Extension in its Advertisement and the mobile node knows the network 1094 prefix of its current co-located care-of address. On the expiration 1095 of its current registration, if this method indicates that the 1096 mobile node has moved, rather than re-registering with its current 1097 care-of address, a mobile node MAY choose instead to register 1098 with a the foreign agent sending the new Advertisement with the 1099 different network prefix. The Agent Advertisement on which the new 1100 registration is based MUST NOT have expired according to its Lifetime 1101 field. 1103 2.4.3. Returning Home 1105 A mobile node can detect that it has returned to its home network 1106 when it receives an Agent Advertisement from its own home agent. If 1107 so, it SHOULD deregister with its home agent (Section 3). Before 1108 attempting to deregister, the mobile node SHOULD configure its 1109 routing table appropriately for its home network (Section 4.2.1). In 1110 addition, if the home network is using ARP [16], the mobile node MUST 1111 follow the procedures described in Section 4.6 with regard to ARP, 1112 proxy ARP, and gratuitous ARP. 1114 2.4.4. Sequence Numbers and Rollover Handling 1116 If a mobile node detects two successive values of the sequence number 1117 in the Agent Advertisements from the foreign agent with which it is 1118 registered, the second of which is less than the first and inside the 1119 range 0 to 255, the mobile node SHOULD register again. If the second 1120 value is less than the first but is greater than or equal to 256, 1121 the mobile node SHOULD assume that the sequence number has rolled 1122 over past its maximum value (0xffff), and that reregistration is not 1123 necessary (Section 2.3). 1125 3. Registration 1127 Mobile IP registration provides a flexible mechanism for mobile nodes 1128 to communicate their current reachability information to their home 1129 agent. It is the method by which mobile nodes: 1131 - request forwarding services when visiting a foreign network, 1133 - inform their home agent of their current care-of address, 1135 - renew a registration which is due to expire, and/or 1137 - deregister when they return home. 1139 Registration messages exchange information between a mobile node, 1140 (optionally) a foreign agent, and the home agent. Registration 1141 creates or modifies a mobility binding at the home agent, associating 1142 the mobile node's home address with its care-of address for the 1143 specified Lifetime. 1145 Several other (optional) capabilities are available through the 1146 registration procedure, which enable a mobile node to: 1148 - maintain multiple simultaneous registrations, so that a copy of 1149 each datagram will be tunneled to each active care-of address 1151 - deregister specific care-of addresses while retaining other 1152 mobility bindings, and 1154 - discover the address of a home agent if the mobile node is not 1155 configured with this information. 1157 3.1. Registration Overview 1159 Mobile IP defines two different registration procedures, one via 1160 a foreign agent that relays the registration to the mobile node's 1161 home agent, and one directly with the mobile node's home agent. The 1162 following rules determine which of these two registration procedures 1163 to use in any particular circumstance: 1165 - If a mobile node is registering a foreign agent care-of address, 1166 the mobile node MUST register via that foreign agent. 1168 - If a mobile node is using a co-located care-of address, and 1169 receives an Agent Advertisement from a foreign agent on the 1170 link on which it is using this care-of address, the mobile node 1171 SHOULD register via that foreign agent (or via another foreign 1172 agent on this link) if the 'R' bit is set in the received Agent 1173 Advertisement message. 1175 - If a mobile node is otherwise using a co-located care-of address, 1176 the mobile node MUST register directly with its home agent. 1178 - If a mobile node has returned to its home network and is 1179 (de)registering with its home agent, the mobile node MUST 1180 register directly with its home agent. 1182 Both registration procedures involve the exchange of Registration 1183 Request and Registration Reply messages (Sections 3.3 and 3.4). When 1184 registering via a foreign agent, the registration procedure requires 1185 the following four messages: 1187 a) The mobile node sends a Registration Request to the 1188 prospective foreign agent to begin the registration process. 1190 b) The foreign agent processes the Registration Request and then 1191 relays it to the home agent. 1193 c) The home agent sends a Registration Reply to the foreign 1194 agent to grant or deny the Request. 1196 d) The foreign agent processes the Registration Reply and then 1197 relays it to the mobile node to inform it of the disposition 1198 of its Request. 1200 When the mobile node instead registers directly with its home agent, 1201 the registration procedure requires only the following two messages: 1203 a) The mobile node sends a Registration Request to the home 1204 agent. 1206 b) The home agent sends a Registration Reply to the mobile node, 1207 granting or denying the Request. 1209 The registration messages defined in Sections 3.3 and 3.4 use the 1210 User Datagram Protocol (UDP) [17]. A nonzero UDP checksum SHOULD be 1211 included in the header, and MUST be checked by the recipient. 1213 3.2. Authentication 1215 Each mobile node, foreign agent, and home agent MUST be able to 1216 support a mobility security association for mobile entities, indexed 1217 by their SPI and IP address. In the case of the mobile node, this 1218 must be its Home Address. See Section 5.1 for requirements for 1219 support of authentication algorithms. Registration messages between 1220 a mobile node and its home agent MUST be authenticated with the 1221 Mobile-Home Authentication Extension (Section 3.5.2). This Extension 1222 immediately follows all non-authentication Extensions, except those 1223 foreign agent-specific Extensions which may be added to the message 1224 after the mobile node computes the authentication. 1226 3.3. Registration Request 1228 A mobile node registers with its home agent using a Registration 1229 Request message so that its home agent can create or modify a 1230 mobility binding for that mobile node (e.g., with a new lifetime). 1231 The Request may be relayed to the home agent by the foreign agent 1232 through which the mobile node is registering, or it may be sent 1233 directly to the home agent in the case in which the mobile node is 1234 registering a co-located care-of address. 1236 IP fields: 1238 Source Address Typically the interface address from which the 1239 message is sent. 1241 Destination Address Typically that of the foreign agent or the 1242 home agent. 1244 See Sections 3.6.1.1 and 3.7.2.2 for details. 1246 UDP fields: 1248 Source Port variable 1250 Destination Port 434 1252 The UDP header is followed by the Mobile IP fields shown below: 1254 0 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Type |S|B|D|M|G|V|rsv| Lifetime | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Home Address | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Home Agent | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Care-of Address | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | | 1266 + Identification + 1267 | | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Extensions ... 1270 +-+-+-+-+-+-+-+- 1272 Type 1 (Registration Request) 1274 S Simultaneous bindings. If the 'S' bit is set, the mobile 1275 node is requesting that the home agent retain its prior 1276 mobility bindings, as described in Section 3.6.1.2. 1278 B Broadcast datagrams. If the 'B' bit is set, the mobile 1279 node requests that the home agent tunnel to it any 1280 broadcast datagrams that it receives on the home network, 1281 as described in Section 4.3. 1283 D Decapsulation by mobile node. If the 'D' bit is set, the 1284 mobile node will itself decapsulate datagrams which are 1285 sent to the care-of address. That is, the mobile node is 1286 using a co-located care-of address. 1288 M Minimal encapsulation. If the 'M' bit is set, the 1289 mobile node requests that its home agent use minimal 1290 encapsulation [15] for datagrams tunneled to the mobile 1291 node. 1293 G GRE encapsulation. If the 'G' bit is set, the 1294 mobile node requests that its home agent use GRE 1295 encapsulation [8] for datagrams tunneled to the mobile 1296 node. 1298 V The mobile node requests that its mobility agent use Van 1299 Jacobson header compression [10] over its link with the 1300 mobile node. 1302 rsv Reserved bits; sent as zero 1304 Lifetime 1305 The number of seconds remaining before the registration 1306 is considered expired. A value of zero indicates a 1307 request for deregistration. A value of 0xffff indicates 1308 infinity. 1310 Home Address 1311 The IP address of the mobile node. 1313 Home Agent 1314 The IP address of the mobile node's home agent. 1316 Care-of Address 1317 The IP address for the end of the tunnel. 1319 Identification 1320 A 64-bit number, constructed by the mobile node, used for 1321 matching Registration Requests with Registration Replies, 1322 and for protecting against replay attacks of registration 1323 messages. See Sections 5.4 and 5.6. 1325 Extensions 1326 The fixed portion of the Registration Request is followed 1327 by one or more of the Extensions listed in Section 3.5. 1328 The Mobile-Home Authentication Extension MUST be included 1329 in all Registration Requests. See Sections 3.6.1.3 1330 and 3.7.2.2 for information on the relative order in 1331 which different extensions, when present, MUST be placed 1332 in a Registration Request message. 1334 3.4. Registration Reply 1336 A mobility agent returns a Registration Reply message to a mobile 1337 node which has sent a Registration Request (Section 3.3) message. 1338 If the mobile node is requesting service from a foreign agent, 1339 that foreign agent will receive the Reply from the home agent and 1340 subsequently relay it to the mobile node. The Reply message contains 1341 the necessary codes to inform the mobile node about the status of its 1342 Request, along with the lifetime granted by the home agent, which MAY 1343 be smaller than the original Request. 1345 The foreign agent MUST NOT increase the Lifetime selected by the 1346 mobile node in the Registration Request, since the Lifetime is 1347 covered by the Mobile-Home Authentication Extension, which cannot 1348 be correctly (re)computed by the foreign agent. The home agent 1349 MUST NOT increase the Lifetime selected by the mobile node in the 1350 Registration Request, since doing so could increase it beyond the 1351 maximum Registration Lifetime allowed by the foreign agent. If the 1352 Lifetime received in the Registration Reply is greater than that in 1353 the Registration Request, the Lifetime in the Request MUST be used. 1354 When the Lifetime received in the Registration Reply is less than 1355 that in the Registration Request, the Lifetime in the Reply MUST be 1356 used. 1358 IP fields: 1360 Source Address Typically copied from the destination 1361 address of the Registration Request to which 1362 the agent is replying. See Sections 3.7.2.3 1363 and 3.8.3.1 for complete details. 1365 Destination Address Copied from the source address of the 1366 Registration Request to which the agent is 1367 replying 1369 UDP fields: 1371 Source Port 1373 Destination Port Copied from the source port of the 1374 corresponding Registration Request 1375 (Section 3.7.1). 1377 The UDP header is followed by the Mobile IP fields shown below: 1379 0 1 2 3 1380 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 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Type | Code | Lifetime | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Home Address | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Home Agent | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | | 1389 + Identification + 1390 | | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Extensions ... 1393 +-+-+-+-+-+-+-+- 1395 Type 3 (Registration Reply) 1397 Code A value indicating the result of the Registration 1398 Request. See below for a list of currently defined Code 1399 values. 1401 Lifetime 1402 If the Code field indicates that the registration was 1403 accepted, the Lifetime field is set to the number of 1404 seconds remaining before the registration is considered 1405 expired. A value of zero indicates that the mobile node 1406 has been deregistered. A value of 0xffff indicates 1407 infinity. If the Code field indicates that the 1408 registration was denied, the contents of the Lifetime 1409 field are unspecified and MUST be ignored on reception. 1411 Home Address 1412 The IP address of the mobile node. 1414 Home Agent 1415 The IP address of the mobile node's home agent. 1417 Identification 1418 A 64-bit number used for matching Registration Requests 1419 with Registration Replies, and for protecting against 1420 replay attacks of registration messages. The value is 1421 based on the Identification field from the Registration 1422 Request message from the mobile node, and on the style of 1423 replay protection used in the security context between 1424 the mobile node and its home agent (defined by the 1425 mobility security association between them, and SPI 1426 value in the Mobile-Home Authentication Extension). See 1427 Sections 5.4 and 5.6. 1429 Extensions 1430 The fixed portion of the Registration Reply is followed 1431 by one or more of the Extensions listed in Section 3.5. 1432 The Mobile-Home Authentication Extension MUST be included 1433 in all Registration Replies returned by the home agent. 1434 See Sections 3.7.2.2 and 3.8.3.3 for rules on placement 1435 of extensions to Reply messages. 1437 The following values are defined for use within the Code field. 1438 Registration successful: 1440 0 registration accepted 1441 1 registration accepted, but simultaneous mobility 1442 bindings unsupported 1444 Registration denied by the foreign agent: 1446 64 reason unspecified 1447 65 administratively prohibited 1448 66 insufficient resources 1449 67 mobile node failed authentication 1450 68 home agent failed authentication 1451 69 requested Lifetime too long 1452 70 poorly formed Request 1453 71 poorly formed Reply 1454 72 requested encapsulation unavailable 1455 73 requested Van Jacobson compression unavailable 1456 74 invalid care-of address 1457 75 registration timeout 1458 80 home network unreachable (ICMP error received) 1459 81 home agent host unreachable (ICMP error received) 1460 82 home agent port unreachable (ICMP error received) 1461 88 home agent unreachable (other ICMP error received) 1463 Registration denied by the home agent: 1465 128 reason unspecified 1466 129 administratively prohibited 1467 130 insufficient resources 1468 131 mobile node failed authentication 1469 132 foreign agent failed authentication 1470 133 registration Identification mismatch 1471 134 poorly formed Request 1472 135 too many simultaneous mobility bindings 1473 136 unknown home agent address 1475 Up-to-date values of the Code field are specified in the most recent 1476 "Assigned Numbers" [20]. 1478 3.5. Registration Extensions 1480 3.5.1. Computing Authentication Extension Values 1482 The Authenticator value computed for each authentication Extension 1483 MUST protect the following fields from the registration message: 1485 - the UDP payload (that is, the Registration Request or 1486 Registration Reply data), 1488 - all prior Extensions in their entirety, and 1490 - the Type, Length, and SPI of this Extension. 1492 The default authentication algorithm uses keyed-MD5 [21] in 1493 "prefix+suffix" mode to compute a 128-bit "message digest" of the 1494 registration message. The default authenticator is a 128-bit value 1495 computed as the MD5 checksum over the the following stream of bytes: 1497 - the shared secret defined by the mobility security association 1498 between the nodes and by the SPI value specified in the 1499 authentication Extension, followed by 1501 - the protected fields from the registration message, in the order 1502 specified above, followed by 1504 - the shared secret again. 1506 Note that the Authenticator field itself and the UDP header are NOT 1507 included in the computation of the default Authenticator value. 1508 See Section 5.1 for information about support requirements for 1509 message authentication codes, which are to be used with the various 1510 authentication Extensions. 1512 The Security Parameter Index (SPI) within any of the authentication 1513 Extensions defines the security context which is used to compute 1514 the Authenticator value and which MUST be used by the receiver to 1515 check that value. In particular, the SPI selects the authentication 1516 algorithm and mode (Section 5.1) and secret (a shared key, or 1517 appropriate public/private key pair) used in computing the 1518 Authenticator. In order to ensure interoperability between different 1519 implementations of the Mobile IP protocol, an implementation MUST be 1520 able to associate any SPI value with any authentication algorithm 1521 and mode which it implements. In addition, all implementations 1522 of Mobile IP MUST implement the default authentication algorithm 1523 (keyed-MD5) and mode ("prefix+suffix") defined above. 1525 3.5.2. Mobile-Home Authentication Extension 1527 Exactly one Mobile-Home Authentication Extension MUST be present 1528 in all Registration Requests and Registration Replies, and is 1529 intended to eliminate problems [2] which result from the uncontrolled 1530 propagation of remote redirects in the Internet. The location of the 1531 extension marks the end of the authenticated data. 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Type | Length | SPI .... 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 ... SPI (cont.) | Authenticator ... 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 Type 32 1543 Length 4 plus the number of bytes in the Authenticator. 1545 SPI Security Parameter Index (4 bytes). An opaque 1546 identifier (see Section 1.6). 1548 Authenticator (variable length) (See Section 3.5.1.) 1550 3.5.3. Mobile-Foreign Authentication Extension 1552 This Extension MAY be included in Registration Requests and Replies 1553 in cases in which a mobility security association exists between the 1554 mobile node and the foreign agent. See Section 5.1 for information 1555 about support requirements for message authentication codes. 1557 0 1 2 3 1558 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 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | Type | Length | SPI .... 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 ... SPI (cont.) | Authenticator ... 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Type 33 1568 Length 4 plus the number of bytes in the Authenticator. 1570 SPI Security Parameter Index (4 bytes). An opaque 1571 identifier (see Section 1.6). 1573 Authenticator (variable length) (See Section 3.5.1.) 1575 3.5.4. Foreign-Home Authentication Extension 1577 This Extension MAY be included in Registration Requests and Replies 1578 in cases in which a mobility security association exists between the 1579 foreign agent and the home agent. See Section 5.1 for information 1580 about support requirements for message authentication codes. 1582 0 1 2 3 1583 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 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Type | Length | SPI .... 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 ... SPI (cont.) | Authenticator ... 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 Type 34 1592 Length 4 plus the number of bytes in the Authenticator. 1594 SPI Security Parameter Index (4 bytes). An opaque 1595 identifier (see Section 1.6). 1597 Authenticator (variable length) (See Section 3.5.1.) 1599 3.6. Mobile Node Considerations 1601 A mobile node MUST be configured with its home address, a netmask, 1602 and a mobility security association for each home agent. In 1603 addition, a mobile node MAY be configured with the IP address of one 1604 or more of its home agents; otherwise, the mobile node MAY discover a 1605 home agent using the procedures described in Section 3.6.1.2. 1607 For each pending registration, the mobile node maintains the 1608 following information: 1610 - the link-layer address of the foreign agent to which the 1611 Registration Request was sent, if applicable, 1612 - the IP destination address of the Registration Request, 1613 - the care-of address used in the registration, 1614 - the Identification value sent in the registration, 1615 - the originally requested Lifetime, and 1616 - the remaining Lifetime of the pending registration. 1618 A mobile node SHOULD initiate a registration whenever it detects a 1619 change in its network connectivity. See Section 2.4.2 for methods by 1620 which mobile nodes MAY make such a determination. When it is away 1621 from home, the mobile node's Registration Request allows its home 1622 agent to create or modify a mobility binding for it. When it is at 1623 home, the mobile node's (de)Registration Request allows its home 1624 agent to delete any previous mobility binding(s) for it. A mobile 1625 node operates without the support of mobility functions when it is at 1626 home. 1628 There are other conditions under which the mobile node SHOULD 1629 (re)register with its foreign agent, such as when the mobile 1630 node detects that the foreign agent has rebooted (as specified in 1631 Section 2.4.4) and when the current registration's Lifetime is near 1632 expiration. 1634 In the absence of link-layer indications of changes in point 1635 of attachment, Agent Advertisements from new agents SHOULD NOT 1636 cause a mobile node to attempt a new registration, if its current 1637 registration has not expired and it is still also receiving Agent 1638 Advertisements from the foreign agent with which it is currently 1639 registered. In the absence of link-layer indications, a mobile node 1640 MUST NOT attempt to register more often than once per second. 1642 A mobile node MAY register with a different agent when 1643 transport-layer protocols indicate excessive retransmissions. 1644 A mobile node MUST NOT consider reception of an ICMP Redirect from 1645 a foreign agent that is currently providing service to it as reason 1646 to register with a new foreign agent. Within these constraints, the 1647 mobile node MAY register again at any time. 1649 Appendix D shows some examples of how the fields in registration 1650 messages would be set up in some typical registration scenarios. 1652 3.6.1. Sending Registration Requests 1654 The following sections specify details for the values the mobile node 1655 MUST supply in the fields of Registration Request messages. 1657 3.6.1.1. IP Fields 1659 This section provides the specific rules by which mobile nodes pick 1660 values for the IP header fields of a Registration Request. 1662 IP Source Address: 1664 - When registering on a foreign network with a co-located care-of 1665 address, the IP source address MUST be the care-of address. 1667 - In all other circumstances, the IP source address MUST be the 1668 mobile node's home address. 1670 IP Destination Address: 1672 - When the mobile node has discovered the agent with which it is 1673 registering, through some means (e.g., link-layer) that does not 1674 provide the IP address of the agent (the IP address of the agent 1675 is unknown to the mobile node), then the "All Mobility Agents" 1676 multicast address (224.0.0.11) MUST be used. In this case, the 1677 mobile node MUST use the agent's link-layer unicast address in 1678 order to deliver the datagram to the correct agent. 1680 - When registering with a foreign agent, the address of the agent 1681 as learned from the IP source address of the corresponding Agent 1682 Advertisement MUST be used. In addition, when transmitting 1683 this Registration Request message, the mobile node MUST use a 1684 link-layer destination address copied from the link-layer source 1685 address of the Agent Advertisement message in which it learned 1686 this foreign agent's IP address. 1688 - When the mobile node is registering directly with its home 1689 agent and knows the (unicast) IP address of its home agent, the 1690 destination address MUST be set to this address. 1692 - If the mobile node is registering directly with its home 1693 agent, but does not know the IP address of its home agent, 1694 the mobile node may use dynamic home agent address resolution 1695 to automatically determine the IP address of its home agent 1696 (Section 3.6.1.2). In this case, the IP destination address is 1697 set to the subnet-directed broadcast address of the mobile node's 1698 home network. This address MUST NOT be used as the destination 1699 IP address if the mobile node is registering via a foreign agent, 1700 although it MAY be used as the Home Agent address in the body of 1701 the Registration Request when registering via a foreign agent. 1703 IP Time to Live: 1705 - The IP TTL field MUST be set to 1 if the IP destination address 1706 is set to the "All Mobility Agents" multicast address as 1707 described above. Otherwise a suitable value should be chosen in 1708 accordance with standard IP practice [19]. 1710 3.6.1.2. Registration Request Fields 1712 This section provides specific rules by which mobile nodes pick 1713 values for the fields within the fixed portion of a Registration 1714 Request. 1716 A mobile node MAY set the 'S' bit in order to request that the 1717 home agent maintain prior mobility binding(s). Otherwise, the 1718 home agent deletes any previous binding(s) and replaces them with 1719 the new binding specified in the Registration Request. Multiple 1720 simultaneous mobility bindings are likely to be useful when a mobile 1721 node using at least one wireless network interface moves within 1722 wireless transmission range of more than one foreign agent. IP 1723 explicitly allows duplication of datagrams. When the home agent 1724 allows simultaneous bindings, it will tunnel a separate copy of each 1725 arriving datagram to each care-of address, and the mobile node will 1726 receive multiple copies of datagrams destined to it. 1728 The mobile node SHOULD set the 'D' bit if it is registering with a 1729 co-located care-of address. Otherwise, the 'D' bit MUST NOT be set. 1731 A mobile node MAY set the 'B' bit to request its home agent to 1732 forward to it, a copy of broadcast datagrams received by its home 1733 agent from the home network. The method used by the home agent to 1734 forward broadcast datagrams depends on the type of care-of address 1735 registered by the mobile node, as determined by the 'D' bit in the 1736 mobile node's Registration Request: 1738 - If the 'D' bit is set, then the mobile node has indicated that it 1739 will decapsulate any datagrams tunneled to this care-of address 1740 itself (the mobile node is using a co-located care-of address). 1741 In this case, to forward such a received broadcast datagram to 1742 the mobile node, the home agent MUST tunnel it to this care-of 1743 address. The mobile node de-tunnels the received datagram in the 1744 same way as any other datagram tunneled directly to it. 1746 - If the 'D' bit is NOT set, then the mobile node has indicated 1747 that it is using a foreign agent care-of address, and that the 1748 foreign agent will thus decapsulate arriving datagrams before 1749 forwarding them to the mobile node. In this case, to forward 1750 such a received broadcast datagram to the mobile node, the home 1751 agent MUST first encapsulate the broadcast datagram in a unicast 1752 datagram addressed to the mobile node's home address, and then 1753 MUST tunnel this resulting datagram to the mobile node's care-of 1754 address. 1756 When decapsulated by the foreign agent, the inner datagram will 1757 thus be a unicast IP datagram addressed to the mobile node, 1758 identifying to the foreign agent the intended destination of the 1759 encapsulated broadcast datagram, and will be delivered to the 1760 mobile node in the same way as any tunneled datagram arriving 1761 for the mobile node. The foreign agent MUST NOT decapsulate the 1762 encapsulated broadcast datagram and MUST NOT use a local network 1763 broadcast to transmit it to the mobile node. The mobile node 1764 thus MUST decapsulate the encapsulated broadcast datagram itself, 1765 and thus MUST NOT set the 'B' bit in its Registration Request in 1766 this case unless it is capable of decapsulating datagrams. 1768 The mobile node MAY request alternative forms of encapsulation by 1769 setting the 'M' bit and/or the 'G' bit, but only if the mobile node 1770 is decapsulating its own datagrams (the mobile node is using a 1771 co-located care-of address) or if its foreign agent has indicated 1772 support for these forms of encapsulation by setting the corresponding 1773 bits in the Mobility Agent Advertisement Extension of an Agent 1774 Advertisement received by the mobile node. Otherwise, the mobile 1775 node MUST NOT set these bits. 1777 The Lifetime field is chosen as follows: 1779 - If the mobile node is registering with a foreign agent, the 1780 Lifetime SHOULD NOT exceed the value in the Registration Lifetime 1781 field of the Agent Advertisement message received from the 1782 foreign agent. When the method by which the care-of address is 1783 learned does not include a Lifetime, the default ICMP Router 1784 Advertisement Lifetime (1800 seconds) MAY be used. 1786 - The mobile node MAY ask a home agent to delete a particular 1787 mobility binding, by sending a Registration Request with the 1788 care-of address for this binding, with the Lifetime field set to 1789 zero (Section 3.8.2). 1791 - Similarly, a Lifetime of zero is used when the mobile node 1792 deregisters all care-of addresses, such as upon returning home. 1794 The Home Agent field MUST be set to the address of the mobile node's 1795 home agent, if the mobile node knows this address. Otherwise, the 1796 mobile node MAY use dynamic home agent address resolution to learn 1797 the address of its home agent. In this case, the mobile node MUST 1798 set the Home Agent field to the subnet-directed broadcast address 1799 of the mobile node's home network. Each home agent receiving such 1800 a Registration Request with a broadcast destination address MUST 1801 reject the mobile node's registration and SHOULD return a rejection 1802 Registration Reply indicating its unicast IP address for use by the 1803 mobile node in a future registration attempt. 1805 The Care-of Address field MUST be set to the value of the particular 1806 care-of address that the mobile node wishes to (de)register. In the 1807 special case in which a mobile node wishes to deregister all care-of 1808 addresses, it MUST set this field to its home address. 1810 The mobile node chooses the Identification field in accordance with 1811 the style of replay protection it uses with its home agent. This is 1812 part of the mobility security association the mobile node shares with 1813 its home agent. See Section 5.6 for the method by which the mobile 1814 node computes the Identification field. 1816 3.6.1.3. Extensions 1818 This section describes the ordering of any mandatory and any optional 1819 Extensions that a mobile node appends to a Registration Request. 1820 This following ordering MUST be followed: 1822 a) The IP header, followed by the UDP header, followed by the 1823 fixed-length portion of the Registration Request, followed by 1825 b) If present, any non-authentication Extensions expected to be 1826 used by the home agent (which may or may not also be used by 1827 the foreign agent), followed by 1829 c) The Mobile-Home Authentication Extension, followed by 1831 d) If present, any non-authentication Extensions used only by 1832 the foreign agent, followed by 1834 e) The Mobile-Foreign Authentication Extension, if present. 1836 Note that items (a) and (c) MUST appear in every Registration Request 1837 sent by the mobile node. Items (b), (d), and (e) are optional. 1838 However, item (e) MUST be included when the mobile node and the 1839 foreign agent share a mobility security association. 1841 3.6.2. Receiving Registration Replies 1843 Registration Replies will be received by the mobile node in response 1844 to its Registration Requests. Registration Replies generally fall 1845 into three categories: 1847 - the registration was accepted, 1848 - the registration was denied by the foreign agent, or 1849 - the registration was denied by the home agent. 1851 The remainder of this section describes the Registration Reply 1852 handling by a mobile node in each of these three categories. 1854 3.6.2.1. Validity Checks 1856 Registration Replies with an invalid, non-zero UDP checksum MUST be 1857 silently discarded. 1859 In addition, the low-order 32 bits of the Identification field in the 1860 Registration Reply MUST be compared to the low-order 32 bits of the 1861 Identification field in the most recent Registration Request sent to 1862 the replying agent. If they do not match, the Reply MUST be silently 1863 discarded. 1865 Also, the authentication in the Registration Reply MUST be checked. 1866 That is, the mobile node MUST check for the presence of a valid 1867 authentication Extension, acting in accordance with the Code field in 1868 the Reply. The rules are as follows: 1870 a) If the mobile node and the foreign agent share a 1871 mobility security association, exactly one Mobile-Foreign 1872 Authentication Extension MUST be present in the Registration 1873 Reply, and the mobile node MUST check the Authenticator 1874 value in the Extension. If no Mobile-Foreign Authentication 1875 Extension is found, or if more than one Mobile-Foreign 1876 Authentication Extension is found, or if the Authenticator is 1877 invalid, the mobile node MUST silently discard the Reply and 1878 SHOULD log the event as a security exception. 1880 b) If the Code field indicates that service is denied by 1881 the home agent, or if the Code field indicates that the 1882 registration was accepted by the home agent, exactly one 1883 Mobile-Home Authentication Extension MUST be present in 1884 the Registration Reply, and the mobile node MUST check the 1885 Authenticator value in the Extension. If no Mobile-Home 1886 Authentication Extension is found, or if more than one 1887 Mobile-Home Authentication Extension is found, or if the 1888 Authenticator is invalid, the mobile node MUST silently 1889 discard the Reply and SHOULD log the event as a security 1890 exception. 1892 If the Code field indicates an authentication failure, either at the 1893 foreign agent or the home agent, then it is quite possible that any 1894 authenticators in the Registration Reply will also be in error. This 1895 could happen, for example, if the shared secret between the mobile 1896 node and home agent was erroneously configured. The mobile node 1897 SHOULD log such errors as security exceptions. 1899 3.6.2.2. Registration Request Accepted 1901 If the Code field indicates that the request has been accepted, the 1902 mobile node SHOULD configure its routing table appropriately for its 1903 current point of attachment (Section 4.2.1). 1905 If the mobile node is returning to its home network and that 1906 network is one which implements ARP, the mobile node MUST follow the 1907 procedures described in Section 4.6 with regard to ARP, proxy ARP, 1908 and gratuitous ARP. 1910 If the mobile node has registered on a foreign network, it 1911 SHOULD re-register before the expiration of the Lifetime of its 1912 registration. As described in Section 3.6, for each pending 1913 Registration Request, the mobile node MUST maintain the remaining 1914 lifetime of this pending registration, as well as the original 1915 Lifetime from the Registration Request. When the mobile node 1916 receives a valid Registration Reply, the mobile node MUST decrease 1917 its view of the remaining lifetime of the registration by the amount 1918 by which the home agent decreased the originally requested Lifetime. 1919 This procedure is equivalent to the mobile node starting a timer for 1920 the granted Lifetime at the time it sent the Registration Request, 1921 even though the granted Lifetime is not known to the mobile node 1922 until the Registration Reply is received. Since the Registration 1923 Request is certainly sent before the home agent begins timing the 1924 registration Lifetime (also based on the granted Lifetime), this 1925 procedure ensures that the mobile node will re-register before the 1926 home agent expires and deletes the registration, in spite of possibly 1927 non-negligible transmission delays for the original Registration 1928 Request and Reply that started the timing of the Lifetime at the 1929 mobile node and its home agent. 1931 3.6.2.3. Registration Request Denied 1933 If the Code field indicates that service is being denied, the mobile 1934 node SHOULD log the error. In certain cases the mobile node may be 1935 able to "repair" the error. These include: 1937 Code 69: (Denied by foreign agent, Lifetime too long) 1939 In this case, the Lifetime field in the Registration Reply will 1940 contain the maximum Lifetime value which that foreign agent is 1941 willing to accept in any Registration Request. The mobile node 1942 MAY attempt to register with this same agent, using a Lifetime 1943 in the Registration Request that MUST be less than or equal to 1944 the value specified in the Reply. 1946 Code 133: (Denied by home agent, Identification mismatch) 1948 In this case, the Identification field in the Registration 1949 Reply will contain a value that allows the mobile node to 1950 synchronize with the home agent, based upon the style of replay 1951 protection in effect (Section 5.6). The mobile node MUST 1952 adjust the parameters it uses to compute the Identification 1953 field based upon the information in the Registration Reply, 1954 before issuing any future Registration Requests. 1956 Code 136: (Denied by home agent, Unknown home agent address) 1958 This code is returned by a home agent when the mobile node is 1959 performing dynamic home agent address resolution as described 1960 in Sections 3.6.1.1 and 3.6.1.2. In this case, the Home Agent 1961 field within the Reply will contain the unicast IP address of 1962 the home agent returning the Reply. The mobile node MAY then 1963 attempt to register with this home agent in future Registration 1964 Requests. In addition, the mobile node SHOULD adjust the 1965 parameters it uses to compute the Identification field based 1966 upon the corresponding field in the Registration Reply, before 1967 issuing any future Registration Requests. 1969 3.6.3. Registration Retransmission 1971 When no Registration Reply has been received within a reasonable 1972 time, another Registration Request MAY be transmitted. When 1973 timestamps are used, a new registration Identification is chosen for 1974 each retransmission; thus it counts as a new registration. When 1975 nonces are used, the unanswered Request is retransmitted unchanged; 1976 thus the retransmission does not count as a new registration 1977 (Section 5.6). In this way a retransmission will not require the 1978 home agent to resynchronize with the mobile node by issuing another 1979 nonce in the case in which the original Registration Request (rather 1980 than its Registration Reply) was lost by the network. 1982 The maximum time until a new Registration Request is sent SHOULD be 1983 no greater than the requested Lifetime of the Registration Request. 1984 The minimum value SHOULD be large enough to account for the size 1985 of the messages, twice the round trip time for transmission to the 1986 home agent, and at least an additional 100 milliseconds to allow for 1987 processing the messages before responding. The round trip time for 1988 transmission to the home agent will be at least as large as the time 1989 required to transmit the messages at the link speed of the mobile 1990 node's current point of attachment. Some circuits add another 200 1991 milliseconds of satellite delay in the total round trip time to the 1992 home agent. The minimum time between Registration Requests MUST NOT 1993 be less than 1 second. Each successive retransmission timeout period 1994 SHOULD be at least twice the previous period, as long as that is less 1995 than the maximum as specified above. 1997 3.7. Foreign Agent Considerations 1999 The foreign agent plays a mostly passive role in Mobile IP 2000 registration. It relays Registration Requests between mobile 2001 nodes and home agents, and, when it provides the care-of address, 2002 decapsulates datagrams for delivery to the mobile node. It SHOULD 2003 also send periodic Agent Advertisement messages to advertise its 2004 presence as described in Section 2.3, if not detectable by link-layer 2005 means. 2007 A foreign agent MUST NOT transmit a Registration Request except when 2008 relaying a Registration Request received from a mobile node, to 2009 the mobile node's home agent. A foreign agent MUST NOT transmit a 2010 Registration Reply except when relaying a Registration Reply received 2011 from a mobile node's home agent, or when replying to a Registration 2012 Request received from a mobile node in the case in which the foreign 2013 agent is denying service to the mobile node. In particular, a 2014 foreign agent MUST NOT generate a Registration Request or Reply 2015 because a mobile node's registration Lifetime has expired. A foreign 2016 agent also MUST NOT originate a Registration Request message that 2017 asks for deregistration of a mobile node; however, it MUST relay 2018 valid (de)Registration Requests originated by a mobile node. 2020 3.7.1. Configuration and Registration Tables 2022 Each foreign agent MUST be configured with a care-of address. In 2023 addition, for each pending or current registration the foreign 2024 agent MUST maintain a visitor list entry containing the following 2025 information obtained from the mobile node's Registration Request: 2027 - the link-layer source address of the mobile node 2028 - the IP Source Address (the mobile node's Home Address) or its 2029 co-located care-of address (see description of the 'R' bit in 2030 section 2.1.1) 2031 - the IP Destination Address (as specified in 3.6.2.3) 2032 - the UDP Source Port 2033 - the Home Agent address 2034 - the Identification field 2035 - the requested registration Lifetime, and 2036 - the remaining Lifetime of the pending or current registration. 2038 The foreign agent MAY configure a maximum number of pending 2039 registrations that it is willing to maintain (typically 5). 2040 Additional registrations SHOULD then be rejected by the foreign agent 2041 with code 66. The foreign agent MAY delete any pending Registration 2042 Request after the request has been pending for more than 7 seconds; 2043 in this case, the foreign agent SHOULD reject the Request with code 2044 75 (registration timeout). 2046 As with any node on the Internet, a foreign agent MAY also share 2047 mobility security associations with any other nodes. When relaying 2048 a Registration Request from a mobile node to its home agent, if the 2049 foreign agent shares a mobility security association with the home 2050 agent, it MUST add a Foreign-Home Authentication Extension to the 2051 Request and MUST check the required Foreign-Home Authentication 2052 Extension in the Registration Reply from the home agent (Sections 3.3 2053 and 3.4). Similarly, when receiving a Registration Request from 2054 a mobile node, if the foreign agent shares a mobility security 2055 association with the mobile node, it MUST check the required 2056 Mobile-Foreign Authentication Extension in the Request and MUST add a 2057 Mobile-Foreign Authentication Extension to the Registration Reply to 2058 the mobile node. 2060 3.7.2. Receiving Registration Requests 2062 If the foreign agent accepts a Registration Request from a mobile 2063 node, it checks to make sure that the indicated home agent address 2064 does not belong to any network interface of the foreign agent. If 2065 not, the foreign agent then MUST relay the Request to the indicated 2066 home agent. Otherwise, if the foreign agent denies the Request, it 2067 MUST send a Registration Reply to the mobile node with an appropriate 2068 denial Code, except in cases where the foreign agent would be 2069 required to send out more than one such denial per second to the same 2070 mobile node. The following sections describe this behavior in more 2071 detail. 2073 If the foreign agent has configured one of its network interfaces 2074 with the IP address specified by the mobile node as its home agent 2075 address, the foreign agent MUST NOT forward the request again. If 2076 the foreign agent serves the mobile node as a home agent, the foreign 2077 agent follows the procedures specified in section 3.8.2. Otherwise, 2078 if the foreign agent does not serve the mobile node as a home agent, 2079 the foreign agent rejects the Registration Request with code 136 2080 (unknown home agent address). 2082 If a foreign agent receives a Registration Request from a mobile 2083 node in its visitor list, the existing visitor list entry for the 2084 mobile node SHOULD NOT be deleted or modified until the foreign 2085 agent receives a valid Registration Reply from the home agent 2086 with a Code indicating success. The foreign agent MUST record 2087 the new pending Request separately from the existing visitor list 2088 entry for the mobile node. If the Registration Request requests 2089 deregistration, the existing visitor list entry for the mobile 2090 node SHOULD NOT be deleted until the foreign agent has received a 2091 successful Registration Reply. If the Registration Reply indicates 2092 that the Request (for registration or deregistration) was denied by 2093 the home agent, the existing visitor list entry for the mobile node 2094 MUST NOT be modified as a result of receiving the Registration Reply. 2096 3.7.2.1. Validity Checks 2098 Registration Requests with an invalid, non-zero UDP checksum MUST be 2099 silently discarded. Requests with non-zero bits in reserved fields 2100 MUST be rejected with code 70 (poorly formed request). Requests with 2101 the 'D' bit set to 0, and specifying a care-of address not offered 2102 by the foreign agent, MUST be rejected with code 74 (invalid care-of 2103 address). 2105 Also, the authentication in the Registration Request MUST be checked. 2106 If the foreign agent and the mobile node share a mobility security 2107 association, exactly one Mobile-Foreign Authentication Extension MUST 2108 be present in the Registration Request, and the foreign agent MUST 2109 check the Authenticator value in the Extension. If no Mobile-Foreign 2110 Authentication Extension is found, or if more than one Mobile-Foreign 2111 Authentication Extension is found, or if the Authenticator is 2112 invalid, the foreign agent MUST silently discard the Request and 2113 SHOULD log the event as a security exception. The foreign agent also 2114 SHOULD send a Registration Reply to the mobile node with Code 67. 2116 3.7.2.2. Forwarding a Valid Request to the Home Agent 2118 If the foreign agent accepts the mobile node's Registration Request, 2119 it MUST relay the Request to the mobile node's home agent as 2120 specified in the Home Agent field of the Registration Request. 2121 The foreign agent MUST NOT modify any of the fields beginning 2122 with the fixed portion of the Registration Request up through and 2123 including the Mobile-Home Authentication Extension. Otherwise, an 2124 authentication failure is very likely to occur at the home agent. In 2125 addition, the foreign agent proceeds as follows: 2127 - It MUST process and remove any Extensions following the 2128 Mobile-Home Authentication Extension, 2129 - It MAY append any of its own non-authentication Extensions of 2130 relevance to the home agent, if applicable, and 2131 - It MUST append the Foreign-Home Authentication Extension, if the 2132 foreign agent shares a mobility security association with the home 2133 agent. 2135 Specific fields within the IP header and the UDP header of the 2136 relayed Registration Request MUST be set as follows: 2138 IP Source Address 2139 The foreign agent's address on the interface from which 2140 the message will be sent. 2142 IP Destination Address 2143 Copied from the Home Agent field within the Registration 2144 Request. 2146 UDP Source Port 2147 2149 UDP Destination Port 2150 434 2152 After forwarding a valid Registration Request to the home agent, the 2153 foreign agent MUST begin timing the remaining lifetime of the pending 2154 registration based on the Lifetime in the Registration Request. If 2155 this lifetime expires before receiving a valid Registration Reply, 2156 the foreign agent MUST delete its visitor list entry for this pending 2157 registration. 2159 3.7.2.3. Denying Invalid Requests 2161 If the foreign agent denies the mobile node's Registration Request 2162 for any reason, it SHOULD send the mobile node a Registration Reply 2163 with a suitable denial Code. In such a case, the Home Address, Home 2164 Agent, and Identification fields within the Registration Reply are 2165 copied from the corresponding fields of the Registration Request. 2167 If the Reserved field is nonzero, the foreign agent MUST deny the 2168 Request and SHOULD return a Registration Reply with status code 70 2169 to the mobile node. If the Request is being denied because the 2170 requested Lifetime is too long, the foreign agent sets the Lifetime 2171 in the Reply to the maximum Lifetime value it is willing to accept in 2172 any Registration Request, and sets the Code field to 69. Otherwise, 2173 the Lifetime SHOULD be copied from the Lifetime field in the Request. 2175 Specific fields within the IP header and the UDP header of the 2176 Registration Reply MUST be set as follows: 2178 IP Source Address 2179 Copied from the IP Destination Address of Registration 2180 Request, unless the "All Agents Multicast" address was 2181 used. In this case, the foreign agent's address (on the 2182 interface from which the message will be sent) MUST be 2183 used. 2185 IP Destination Address 2186 Copied from the IP Source Address of the Registration 2187 Request. 2189 UDP Source Port 2190 434 2192 UDP Destination Port 2193 Copied from the UDP Source Port of the Registration 2194 Request. 2196 3.7.3. Receiving Registration Replies 2198 The foreign agent updates its visitor list when it receives a 2199 valid Registration Reply from a home agent. It then relays the 2200 Registration Reply to the mobile node. The following sections 2201 describe this behavior in more detail. 2203 If upon relaying a Registration Request to a home agent, the foreign 2204 agent receives an ICMP error message instead of a Registration Reply, 2205 then the foreign agent SHOULD send to the mobile node a Registration 2206 Reply with an appropriate "Home Agent Unreachable" failure Code 2207 (within the range 80-95, inclusive). See Section 3.7.2.3 for details 2208 on building the Registration Reply. 2210 3.7.3.1. Validity Checks 2212 Registration Replies with an invalid, non-zero UDP checksum MUST be 2213 silently discarded. 2215 When a foreign agent receives a Registration Reply message, it MUST 2216 search its visitor list for a pending Registration Request with the 2217 same mobile node home address as indicated in the Reply. If no 2218 pending Request is found, the foreign agent MUST silently discard the 2219 Reply. The foreign agent MUST also silently discard the Reply if the 2220 low-order 32 bits of the Identification field in the Reply do not 2221 match those in the Request. 2223 Also, the authentication in the Registration Reply MUST be checked. 2224 If the foreign agent and the home agent share a mobility security 2225 association, exactly one Foreign-Home Authentication Extension MUST 2226 be present in the Registration Reply, and the foreign agent MUST 2227 check the Authenticator value in the Extension. If no Foreign-Home 2228 Authentication Extension is found, or if more than one Foreign-Home 2229 Authentication Extension is found, or if the Authenticator is 2230 invalid, the foreign agent MUST silently discard the Reply and SHOULD 2231 log the event as a security exception. The foreign agent also MUST 2232 reject the mobile node's registration and SHOULD send a Registration 2233 Reply to the mobile node with Code 68. 2235 3.7.3.2. Forwarding Replies to the Mobile Node 2237 A Registration Reply which satisfies the validity checks of 2238 Section 3.8.2.1 is relayed to the mobile node. The foreign agent 2239 MUST also update its visitor list entry for the mobile node to 2240 reflect the results of the Registration Request, as indicated by the 2241 Code field in the Reply. If the Code indicates that the home agent 2242 has accepted the registration and the Lifetime field is nonzero, the 2243 foreign agent SHOULD set the Lifetime in the visitor list entry to 2244 the minumum of the following two values: 2246 - the value specified in the Lifetime field of the Registration 2247 Reply, and 2249 - the foreign agent's own maximum value for allowable registration 2250 lifetime. 2252 If, instead, the Code indicates that the Lifetime field is zero, 2253 the foreign agent MUST delete its visitor list entry for the mobile 2254 node. Finally, if the Code indicates that the registration was 2255 denied by the home agent, the foreign agent MUST delete its pending 2256 registration list entry, but not its visitor list entry, for the 2257 mobile node. 2259 The foreign agent MUST NOT modify any of the fields beginning 2260 with the fixed portion of the Registration Reply up through and 2261 including the Mobile-Home Authentication Extension. Otherwise, 2262 an authentication failure is very likely to occur at the mobile 2263 node. In addition, the foreign agent SHOULD perform the following 2264 additional procedures: 2266 - It MUST process and remove any Extensions following the 2267 Mobile-Home Authentication Extension, 2268 - It MAY append its own non-authentication Extensions of relevance 2269 to the mobile node, if applicable, and 2271 - It MUST append the Mobile-Foreign Authentication Extension, if 2272 the foreign agent shares a mobility security association with the 2273 mobile node. 2275 Specific fields within the IP header and the UDP header of the 2276 relayed Registration Reply are set according to the same rules 2277 specified in Section 3.7.2.3. 2279 After forwarding a valid Registration Reply to the mobile node, 2280 the foreign agent MUST update its visitor list entry for this 2281 registration as follows. If the Registration Reply indicates that 2282 the registration was accepted by the home agent, the foreign agent 2283 resets its timer of the lifetime of the registration to the Lifetime 2284 granted in the Registration Reply; unlike the mobile node's timing 2285 of the registration lifetime as described in Section 3.6.2.2, the 2286 foreign agent considers this lifetime to begin when it forwards the 2287 Registration Reply message, ensuring that the foreign agent will not 2288 expire the registration before the mobile node does. On the other 2289 hand, if the Registration Reply indicates that the registration was 2290 rejected by the home agent, the foreign agent deletes its visitor 2291 list entry for this attempted registration. 2293 3.8. Home Agent Considerations 2295 Home agents play a reactive role in the registration process. The 2296 home agent receives Registration Requests from the mobile node 2297 (perhaps relayed by a foreign agent), updates its record of the 2298 mobility bindings for this mobile node, and issues a suitable 2299 Registration Reply in response to each. 2301 A home agent MUST NOT transmit a Registration Reply except when 2302 replying to a Registration Request received from a mobile node. In 2303 particular, the home agent MUST NOT generate a Registration Reply to 2304 indicate that the Lifetime has expired. 2306 3.8.1. Configuration and Registration Tables 2308 Each home agent MUST be configured with an IP address and with the 2309 prefix size for the home network. The home agent MUST be configured 2310 with the home address and mobility security association of each 2311 authorized mobile node that it is serving as a home agent. When 2312 the home agent accepts a valid Registration Request from a mobile 2313 node that it serves as a home agent, the home agent MUST create or 2314 modify the entry for this mobile node in its mobility binding list 2315 containing: 2317 - the mobile node's care-of address 2318 - the Identification field from the Registration Reply 2319 - the remaining Lifetime of the registration 2321 The home agent MAY also maintain mobility security associations 2322 with various foreign agents. When receiving a Registration Request 2323 from a foreign agent, if the home agent shares a mobility security 2324 association with the foreign agent, the home agent MUST check the 2325 Authenticator in the required Foreign-Home Authentication Extension 2326 in the message, based on this mobility security association. 2327 Similarly, when sending a Registration Reply to a foreign agent, 2328 if the home agent shares a mobility security association with 2329 the foreign agent, the home agent MUST include a Foreign-Home 2330 Authentication Extension in the message, based on this mobility 2331 security association. 2333 3.8.2. Receiving Registration Requests 2335 If the home agent accepts an incoming Registration Request, it MUST 2336 update its record of the the mobile node's mobility binding(s) and 2337 SHOULD send a Registration Reply with a suitable Code. Otherwise 2338 (the home agent denies the Request), it SHOULD send a Registration 2339 Reply with an appropriate Code specifying the reason the Request 2340 was denied. The following sections describe this behavior in more 2341 detail. The home agent MUST ignore the setting of the 'V' bit in any 2342 Registration Request, since it is only relevant to the foreign agent. 2343 If the home agent does not support broadcasts (see section 4.3), it 2344 MUST ignore the 'B' bit (as opposed to rejecting the Registration 2345 Request). 2347 3.8.2.1. Validity Checks 2349 Registration Requests with an invalid, non-zero UDP checksum MUST be 2350 silently discarded by the home agent. 2352 The authentication in the Registration Request MUST be checked. This 2353 involves the following operations: 2355 a) The home agent MUST check for the presence of a valid 2356 Mobile-Home Authentication Extension, and perform the 2357 indicated authentication. Exactly one Mobile-Home 2358 Authentication Extension MUST be present in the Registration 2359 Request, and the home agent MUST check the Authenticator 2360 value in the Extension. If no Mobile-Home Authentication 2361 Extension is found, or if more than one Mobile-Home 2362 Authentication Extension is found, or if the Authenticator 2363 is invalid, the home agent MUST reject the mobile node's 2364 registration and SHOULD send a Registration Reply to the 2365 mobile node with Code 131. The home agent MUST then discard 2366 the Request and SHOULD log the error as a security exception. 2368 b) The home agent MUST check that the registration 2369 Identification field is correct using the context selected by 2370 the SPI within the Mobile-Home Authentication Extension. See 2371 Section 5.6 for a description of how this is performed. If 2372 incorrect, the home agent MUST reject the Request and SHOULD 2373 send a Registration Reply to the mobile node with Code 133, 2374 including an Identification field computed in accordance with 2375 the rules specified in Section 5.6. The home agent MUST do 2376 no further processing with such a Request, though it SHOULD 2377 log the error as a security exception. 2379 c) If the home agent shares a mobility security association with 2380 the foreign agent, the home agent MUST check for the presence 2381 of a valid Foreign-Home Authentication Extension. Exactly 2382 one Foreign-Home Authentication Extension MUST be present in 2383 the Registration Request in this case, and the home agent 2384 MUST check the Authenticator value in the Extension. If no 2385 Foreign-Home Authentication Extension is found, or if more 2386 than one Foreign-Home Authentication Extension is found, or 2387 if the Authenticator is invalid, the home agent MUST reject 2388 the mobile node's registration and SHOULD send a Registration 2389 Reply to the mobile node with Code 132. The home agent 2390 MUST then discard the Request and SHOULD log the error as a 2391 security exception. 2393 In addition to checking the authentication in the Registration 2394 Request, home agents MUST deny Registration Requests that are sent to 2395 the subnet-directed broadcast address of the home network (as opposed 2396 to being unicast to the home agent). The home agent MUST discard 2397 the Request and SHOULD returning a Registration Reply with a Code 2398 of 136. In this case, the Registration Reply will contain the home 2399 agent's unicast address, so that the mobile node can re-issue the 2400 Registration Request with the correct home agent address. 2402 Note that some routers change the IP destination address of a 2403 datagram from a subnet-directed broadcast address to 255.255.255.255 2404 before injecting it into the destination subnet. In this case, home 2405 agents that attempt to pick up dynamic home agent discovery requests 2406 by binding a socket explicitly to the subnet-directed broadcast 2407 address will not see such packets. Home agent implementors should 2408 be prepared for both the subnet-directed broadcast address and 2409 255.255.255.255 if they wish to support dynamic home agent discovery. 2411 3.8.2.2. Accepting a Valid Request 2413 If the Registration Request satisfies the validity checks in 2414 Section 3.8.2.1, and the home agent is able to accommodate the 2415 Request, the home agent MUST update its mobility binding list for 2416 the requesting mobile node and MUST return a Registration Reply to 2417 the mobile node. In this case, the Reply Code will be either 0 if 2418 the home agent supports simultaneous mobility bindings, or 1 if it 2419 does not. See Section 3.8.3 for details on building the Registration 2420 Reply message. 2422 The home agent updates its record of the mobile node's mobility 2423 bindings as follows, based on the fields in the Registration Request: 2425 - If the Lifetime is zero and the Care-of Address equals the mobile 2426 node's home address, the home agent deletes all of the entries in 2427 the mobility binding list for the requesting mobile node. This 2428 is how a mobile node requests that its home agent cease providing 2429 mobility services. 2431 - If the Lifetime is zero and the Care-of Address does not equal 2432 the mobile node's home address, the home agent deletes only the 2433 entry containing the specified Care-of Address from the mobility 2434 binding list for the requesting mobile node. Any other active 2435 entries containing other care-of addresses will remain active. 2437 - If the Lifetime is nonzero, the home agent adds an entry 2438 containing the requested Care-of Address to the mobility binding 2439 list for the mobile node. If the 'S' bit is set and the home 2440 agent supports simultaneous mobility bindings, the previous 2441 mobility binding entries are retained. Otherwise, the home agent 2442 removes all previous entries in the mobility binding list for the 2443 mobile node. 2445 In all cases, the home agent MUST send a Registration Reply to 2446 the source of the Registration Request, which might indeed be a 2447 different foreign agent than that whose care-of address is being 2448 (de)registered. If the home agent shares a mobility security 2449 association with the foreign agent whose care-of address is being 2450 deregistered, and that foreign agent is different from the one which 2451 relayed the Registration Request, the home agent MAY additionally 2452 send a Registration Reply to the foreign agent whose care-of address 2453 is being deregistered. The home agent MUST NOT send such a Reply if 2454 it does not share a mobility security association with the foreign 2455 agent. If no Reply is sent, the foreign agent's visitor list will 2456 expire naturally when the original Lifetime expires. 2458 The home agent MUST NOT increase the Lifetime above that specified 2459 by the mobile node in the Registration Request. However, it is not 2460 an error for the mobile node to request a Lifetime longer than the 2461 home agent is willing to accept. In this case, the home agent simply 2462 reduces the Lifetime to a permissible value and returns this value in 2463 the Registration Reply. The Lifetime value in the Registration Reply 2464 informs the mobile node of the granted lifetime of the registration, 2465 indicating when it SHOULD re-register in order to maintain continued 2466 service. After the expiration of this registration lifetime, 2467 the home agent MUST delete its entry for this registration in its 2468 mobility binding list. 2470 If the Registration Request duplicates an accepted current 2471 Registration Request, the new Lifetime MUST NOT extend beyond the 2472 Lifetime originally granted. A Registration Request is a duplicate 2473 if the home address, care-of address, and Identification fields all 2474 equal those of an accepted current registration. 2476 In addition, if the home network implements ARP [16], and the 2477 Registration Request asks the home agent to create a mobility binding 2478 for a mobile node which previously had no binding (the mobile node 2479 was previously assumed to be at home), then the home agent MUST 2480 follow the procedures described in Section 4.6 with regard to ARP, 2481 proxy ARP, and gratuitous ARP. If the mobile node already had a 2482 previous mobility binding, the home agent MUST continue to follow the 2483 rules for proxy ARP described in Section 4.6. 2485 3.8.2.3. Denying an Invalid Request 2487 If the Registration Reply does not satisfy all of the validity checks 2488 in Section 3.8.2.1, or the home agent is unable to accommodate the 2489 Request, the home agent SHOULD return a Registration Reply to the 2490 mobile node with a Code that indicates the reason for the error. If 2491 a foreign agent was involved in relaying the Request, this allows the 2492 foreign agent to delete its pending visitor list entry. Also, this 2493 informs the mobile node of the reason for the error such that it may 2494 attempt to fix the error and issue another Request. 2496 This section lists a number of reasons the home agent might reject a 2497 Request, and provides the Code value it should use in each instance. 2498 See Section 3.8.3 for additional details on building the Registration 2499 Reply message. 2501 Many reasons for rejecting a registration are administrative 2502 in nature. For example, a home agent can limit the number of 2503 simultaneous registrations for a mobile node, by rejecting any 2504 registrations that would cause its limit to be exceeded, and 2505 returning a Registration Reply with error code 135. Similarly, a 2506 home agent may refuse to grant service to mobile nodes which have 2507 entered unauthorized service areas by returning a Registration Reply 2508 with a Code of 129. 2510 Requests with non-zero bits in reserved fields MUST be rejected with 2511 code 134 (poorly formed request). 2513 3.8.3. Sending Registration Replies 2515 If the home agent accepts a Registration Request, it then MUST update 2516 its record of the mobile node's mobility binding(s) and SHOULD send a 2517 Registration Reply with a suitable Code. Otherwise (the home agent 2518 has denied the Request), it SHOULD send a Registration Reply with an 2519 appropriate Code specifying the reason the Request was denied. The 2520 following sections provide additional detail for the values the home 2521 agent MUST supply in the fields of Registration Reply messages. 2523 3.8.3.1. IP/UDP Fields 2525 This section provides the specific rules by which mobile nodes pick 2526 values for the IP and UDP header fields of a Registration Reply. 2528 IP Source Address 2529 Copied from the IP Destination Address of Registration 2530 Request, unless a multicast or broadcast address was 2531 used. If the IP Destination Address of the Registration 2532 Request was a broadcast or multicast address, the IP 2533 Source Address of the Registration Reply MUST be set to 2534 the home agent's (unicast) IP address. 2536 IP Destination Address 2537 Copied from the IP Source Address of the Registration 2538 Request. 2540 UDP Source Port 2541 Copied from the UDP Destination Port of the Registration 2542 Request. 2544 UDP Destination Port 2545 Copied from the UDP Source Port of the Registration 2546 Request. 2548 When sending a Registration Reply in response to a Registration 2549 Request that requested deregistration of the mobile node (the 2550 Lifetime is zero and the Care-of Address equals the mobile node's 2551 home address) and in which the IP Source Address was also set to 2552 the mobile node's home address (this is the normal method used by a 2553 mobile node to deregister when it returns to its home network), the 2554 IP Destination Address in the Registration Reply will be set to the 2555 mobile node's home address, as copied from the IP Source Address of 2556 the Request. 2558 In this case, when transmitting the Registration Reply, the home 2559 agent MUST transmit the Reply directly onto the home network as if 2560 the mobile node were at home, bypassing any mobility binding list 2561 entry that may still exist at the home agent for the destination 2562 mobile node. In particular, for a mobile node returning home 2563 after being registered with a care-of address, if the mobile node's 2564 new Registration Request is not accepted by the home agent, the 2565 mobility binding list entry for the mobile node will still indicate 2566 that datagrams addressed to the mobile node should be tunneled to 2567 the mobile node's registered care-of address; when sending the 2568 Registration Reply indicating the rejection of this Request, this 2569 existing binding list entry MUST be ignored, and the home agent MUST 2570 transmit this Reply as if the mobile node were at home. 2572 3.8.3.2. Registration Reply Fields 2574 This section provides specific rules by which home agents pick values 2575 for the fields within the fixed portion of a Registration Reply. 2577 The Code field of the Registration Reply is chosen in accordance with 2578 the rules specified in the previous sections. When replying to an 2579 accepted registration, a home agent SHOULD respond with Code 1 if it 2580 does not support simultaneous registrations. 2582 The Lifetime field MUST be copied from the corresponding field in 2583 the Registration Request, unless the requested value is greater than 2584 the maximum length of time the home agent is willing to provide the 2585 requested service. In such a case, the Lifetime MUST be set to the 2586 length of time that service will actually be provided by the home 2587 agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed 2588 by the home agent (for this mobile node and care-of address). 2590 The Home Address field MUST be copied from the corresponding field in 2591 the Registration Request. 2593 If the Home Agent field in the Registration Request contains a 2594 unicast address of this home agent, then that field MUST be copied 2595 into the Home Agent field of the Registration Reply. Otherwise, the 2596 home agent MUST set the Home Agent field in the Registration Reply to 2597 its unicast address. In this latter case, the home agent MUST reject 2598 the registration with a suitable code (e.g., Code 136) to prevent the 2599 mobile node from possibly being simultaneously registered with two or 2600 more home agents. 2602 3.8.3.3. Extensions 2604 This section describes the ordering of any required and any optional 2605 Mobile IP Extensions that a home agent appends to a Registration 2606 Reply. The following ordering MUST be followed: 2608 a) The IP header, followed by the UDP header, followed by the 2609 fixed-length portion of the Registration Reply, 2611 b) If present, any non-authentication Extensions used by the 2612 mobile node (which may or may not also be used by the foreign 2613 agent), 2615 c) The Mobile-Home Authentication Extension, 2617 d) If present, any non-authentication Extensions used only by 2618 the foreign agent, and 2620 e) The Foreign-Home Authentication Extension, if present. 2622 Note that items (a) and (c) MUST appear in every Registration Reply 2623 sent by the home agent. Items (b), (d), and (e) are optional. 2624 However, item (e) MUST be included when the home agent and the 2625 foreign agent share a mobility security association. 2627 4. Routing Considerations 2629 This section describes how mobile nodes, home agents, and (possibly) 2630 foreign agents cooperate to route datagrams to/from mobile nodes that 2631 are connected to a foreign network. The mobile node informs its 2632 home agent of its current location using the registration procedure 2633 described in Section 3. See the protocol overview in Section 1.7 for 2634 the relative locations of the mobile node's home address with respect 2635 to its home agent, and the mobile node itself with respect to any 2636 foreign agent with which it might attempt to register. 2638 4.1. Encapsulation Types 2640 Home agents and foreign agents MUST support tunneling datagrams 2641 using IP in IP encapsulation [14]. Any mobile node that uses a 2642 co-located care-of address MUST support receiving datagrams tunneled 2643 using IP in IP encapsulation. Minimal encapsulation [15] and GRE 2644 encapsulation [8] are alternate encapsulation methods which MAY 2645 optionally be supported by mobility agents and mobile nodes. The use 2646 of these alternative forms of encapsulation, when requested by the 2647 mobile node, is otherwise at the discretion of the home agent. 2649 4.2. Unicast Datagram Routing 2651 4.2.1. Mobile Node Considerations 2653 When connected to its home network, a mobile node operates without 2654 the support of mobility services. That is, it operates in the same 2655 way as any other (fixed) host or router. The method by which a 2656 mobile node selects a default router when connected to its home 2657 network, or when away from home and using a co-located care-of 2658 address, is outside the scope of this document. ICMP Router 2659 Advertisement [5] is one such method. 2661 When registered on a foreign network, the mobile node chooses a 2662 default router by the following rules: 2664 - If the mobile node is registered using a foreign agent care-of 2665 address, it MAY use its foreign agent as a first-hop router. 2666 The foreign agent's MAC address can be learned from Agent 2667 Advertisement. Otherwise, the mobile node MUST choose its 2668 default router from among the Router Addresses advertised in the 2669 ICMP Router Advertisement portion of that Agent Advertisement 2670 message. 2672 - If the mobile node is registered directly with its home agent 2673 using a co-located care-of address, then the mobile node SHOULD 2674 choose its default router from among those advertised in any 2675 ICMP Router Advertisement message that it receives for which 2676 its externally obtained care-of address and the Router Address 2677 match under the network prefix. If the mobile node's externally 2678 obtained care-of address matches the IP source address of the 2679 Agent Advertisement under the network prefix, the mobile node MAY 2680 also consider that IP source address as another possible choice 2681 for the IP address of a default router. The network prefix MAY 2682 be obtained from the Prefix-Lengths Extension in the Router 2683 Advertisement, if present. The prefix MAY also be obtained 2684 through other mechanisms beyond the scope of this document. 2686 While they are away from the home network, mobile nodes MUST NOT 2687 broadcast ARP packets to find the MAC address of another Internet 2688 node. Thus, the (possibly empty) list of Router Addresses from the 2689 ICMP Router Advertisement portion of the message is not useful for 2690 selecting a default router, unless the mobile node has some means 2691 not involving broadcast ARP and not specified within this document 2692 for obtaining the MAC address of one of the routers in the list. 2693 Similarly, in the absence of unspecified mechanisms for obtaining MAC 2694 addresses on foreign networks, the mobile node MUST ignore redirects 2695 to other routers on foreign networks. 2697 Note that Van Jacobson header compression [10] will not function 2698 properly unless all TCP IP datagrams to and from the mobile node 2699 pass, respectively, through the same first and last-hop router. 2700 The mobile node, therefore, MUST select its foreign agent as its 2701 default router if it performs Van Jacobson header compression with 2702 its foreign agent. 2704 4.2.2. Foreign Agent Considerations 2706 Upon receipt of an encapsulated datagram sent to its advertised 2707 care-of address, a foreign agent MUST compare the inner destination 2708 address to those entries in its visitor list. When the destination 2709 does not match the address of any mobile node currently in the 2710 visitor list, the foreign agent MUST NOT forward the datagram without 2711 modifications to the original IP header, because otherwise a routing 2712 loop is likely to result. The datagram SHOULD be silently discarded. 2713 ICMP Destination Unreachable MUST NOT be sent when a foreign agent 2714 is unable to forward an incoming tunneled datagram. Otherwise, the 2715 foreign agent forwards the decapsulated datagram to the mobile node. 2717 The foreign agent MUST NOT advertise to other routers in its routing 2718 domain, nor to any other mobile node, the presence of a mobile router 2719 (Section 4.5). 2721 The foreign agent MUST route datagrams it receives from registered 2722 mobile nodes. At a minimum, this means that the foreign agent 2723 must verify the IP Header Checksum, decrement the IP Time To Live, 2724 recompute the IP Header Checksum, and forward such datagrams to a 2725 default router. 2727 A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC 2728 address on a foreign network. It may obtain the MAC address by 2729 copying the information from an Agent Solicitation or a Registration 2730 Request transmitted from a mobile node. A foreign agent's ARP cache 2731 for the mobile node's IP address MUST NOT be allowed to expire before 2732 the mobile node's visitor list entry expires, unless the foreign 2733 agent has some way other than broadcast ARP to refresh its MAC 2734 address associated to the mobile node's IP address. 2736 4.2.3. Home Agent Considerations 2738 The home agent MUST be able to intercept any datagrams on the 2739 home network addressed to the mobile node while the mobile node is 2740 registered away from home. Proxy and gratuitous ARP MAY be used in 2741 enabling this interception, as specified in Section 4.6. 2743 The home agent must examine the IP Destination Address of all 2744 arriving datagrams to see if it is equal to the home address of any 2745 of its mobile nodes registered away from home. If so, the home 2746 agent tunnels the datagram to the mobile node's currently registered 2747 care-of address or addresses. If the home agent supports the 2748 optional capability of multiple simultaneous mobility bindings, it 2749 tunnels a copy to each care-of address in the mobile node's mobility 2750 binding list. If the mobile node has no current mobility bindings, 2751 the home agent MUST NOT attempt to intercept datagrams destined for 2752 the mobile node, and thus will not in general receive such datagrams. 2753 However, if the home agent is also a router handling common IP 2754 traffic, it is possible that it will receive such datagrams for 2755 forwarding onto the home network. In this case, the home agent MUST 2756 assume the mobile node is at home and simply forward the datagram 2757 directly onto the home network. 2759 See Section 4.1 regarding methods of encapsulation that may be used 2760 for tunneling. Nodes implementing tunneling SHOULD also implement 2761 the "tunnel soft state" mechanism [14], which allows ICMP error 2762 messages returned from the tunnel to correctly be reflected back to 2763 the original senders of the tunneled datagrams. 2765 Home agents SHOULD be able to decapsulate and further deliver packets 2766 addressed to themselves, sent by a mobile node for the purpose of 2767 maintaining location privacy, as described in Section 5.5. 2769 If the Lifetime for a given mobility binding expires before the 2770 home agent has received another valid Registration Request for that 2771 mobile node, then that binding is deleted from the mobility binding 2772 list. The home agent MUST NOT send any Registration Reply message 2773 simply because the mobile node's binding has expired. The entry in 2774 the visitor list of the mobile node's current foreign agent will 2775 expire naturally, probably at the same time as the binding expired 2776 at the home agent. When a mobility binding's lifetime expires, the 2777 home agent MUST delete the binding, but it MUST retain any other 2778 (non-expired) simultaneous mobility bindings that it holds for the 2779 mobile node. 2781 When a home agent receives a datagram, intercepted for one of its 2782 mobile nodes registered away from home, the home agent MUST examine 2783 the datagram to check if it is already encapsulated. If so, special 2784 rules apply in the forwarding of that datagram to the mobile node: 2786 - If the inner (encapsulated) Destination Address is the same 2787 as the outer Destination Address (the mobile node), then the 2788 home agent MUST also examine the outer Source Address of the 2789 encapsulated datagram (the source address of the tunnel). If 2790 this outer Source Address is the same as the mobile node's 2791 current care-of address, the home agent MUST silently discard 2792 that datagram in order to prevent a likely routing loop. If, 2793 instead, the outer Source Address is NOT the same as the mobile 2794 node's current care-of address, then the home agent SHOULD 2795 forward the datagram to the mobile node. In order to forward 2796 the datagram in this case, the home agent MAY simply alter the 2797 outer Destination Address to the care-of address, rather than 2798 re-encapsulating the datagram. 2800 - Otherwise (the inner Destination Address is NOT the same as the 2801 outer Destination Address), the home agent SHOULD encapsulate 2802 the datagram again (nested encapsulation), with the new outer 2803 Destination Address set equal to the mobile node's care-of 2804 address. That is, the home agent forwards the entire datagram 2805 to the mobile node in the same way as any other datagram 2806 (encapsulated already or not). 2808 4.3. Broadcast Datagrams 2810 When a home agent receives a broadcast datagram, it MUST NOT forward 2811 the datagram to any mobile nodes in its mobility binding list other 2812 than those that have requested forwarding of broadcast datagrams. A 2813 mobile node MAY request forwarding of broadcast datagrams by setting 2814 the 'B' bit in its Registration Request message (Section 3.3). For 2815 each such registered mobile node, the home agent SHOULD forward 2816 received broadcast datagrams to the mobile node, although it is 2817 a matter of configuration at the home agent as to which specific 2818 categories of broadcast datagrams will be forwarded to such mobile 2819 nodes. 2821 If the 'D' bit was set in the mobile node's Registration Request 2822 message, indicating that the mobile node is using a co-located 2823 care-of address, the home agent simply tunnels appropriate broadcast 2824 IP datagrams to the mobile node's care-of address. Otherwise (the 2825 'D' bit was NOT set), the home agent first encapsulates the broadcast 2826 datagram in a unicast datagram addressed to the mobile node's home 2827 address, and then tunnels this encapsulated datagram to the foreign 2828 agent. This extra level of encapsulation is required so that the 2829 foreign agent can determine which mobile node should receive the 2830 datagram after it is decapsulated. When received by the foreign 2831 agent, the unicast encapsulated datagram is detunneled and delivered 2832 to the mobile node in the same way as any other datagram. In either 2833 case, the mobile node must decapsulate the datagram it receives in 2834 order to recover the original broadcast datagram. 2836 4.4. Multicast Datagram Routing 2838 As mentioned previously, a mobile node that is connected to its 2839 home network functions in the same way as any other (fixed) host 2840 or router. Thus, when it is at home, a mobile node functions 2841 identically to other multicast senders and receivers. This section 2842 therefore describes the behavior of a mobile node that is visiting a 2843 foreign network. 2845 In order receive multicasts, a mobile node MUST join the multicast 2846 group in one of two ways. First, a mobile node MAY join the group 2847 via a (local) multicast router on the visited subnet. This option 2848 assumes that there is a multicast router present on the visited 2849 subnet. If the mobile node is using a co-located care-of address, 2850 it SHOULD use this address as the source IP address of its IGMP [4] 2851 messages. Otherwise, it MAY use its home address. 2853 Alternatively, a mobile node which wishes to receive multicasts 2854 MAY join groups via a bi-directional tunnel to its home agent, 2855 assuming that its home agent is a multicast router. The mobile node 2856 tunnels IGMP messages to its home agent and the home agent forwards 2857 multicast datagrams down the tunnel to the mobile node. The rules 2858 for multicast datagram delivery to mobile nodes in this case are 2859 identical to those for broadcast datagrams (Section 4.3). Namely, if 2860 the mobile node is using a co-located care-of address (the 'D' bit 2861 was set in the mobile node's Registration Request), then the home 2862 agent SHOULD tunnel the datagram to this care-of address; otherwise, 2863 the home agent MUST first encapsulate the datagram in a unicast 2864 datagram addressed to the mobile node's home address and then MUST 2865 tunnel the resulting datagram (nested tunneling) to the mobile node's 2866 care-of address. 2868 A mobile node that wishes to send datagrams to a multicast group 2869 also has two options: (1) send directly on the visited network; or 2870 (2) send via a tunnel to its home agent. Because multicast routing 2871 in general depends upon the IP source address, a mobile node which 2872 sends multicast datagrams directly on the visited network MUST use a 2873 co-located care-of address as the IP source address. Similarly, a 2874 mobile node which tunnels a multicast datagram to its home agent MUST 2875 use its home address as the IP source address of both the (inner) 2876 multicast datagram and the (outer) encapsulating datagram. This 2877 second option assumes that the home agent is a multicast router. 2879 4.5. Mobile Routers 2881 A mobile node can be a router, which is responsible for the mobility 2882 of one or more entire networks moving together, perhaps on an 2883 airplane, a ship, a train, an automobile, a bicycle, or a kayak. 2885 The nodes connected to a network served by the mobile router may 2886 themselves be fixed nodes or mobile nodes or routers. In this 2887 document, such networks are called "mobile networks". 2889 A mobile router MAY act as a foreign agent and provide a foreign 2890 agent care-of address to mobile nodes connected to the mobile 2891 network. Typical routing to a mobile node via a mobile router in 2892 this case is illustrated by the following example: 2894 a) A laptop computer is disconnected from its home network and 2895 later attached to a network port in the seat back of an 2896 aircraft. The laptop computer uses Mobile IP to register on 2897 this foreign network, using a foreign agent care-of address 2898 discovered through an Agent Advertisement from the aircraft's 2899 foreign agent. 2901 b) The aircraft network is itself mobile. Suppose the node 2902 serving as the foreign agent on the aircraft also serves as 2903 the default router that connects the aircraft network to the 2904 rest of the Internet. When the aircraft is at home, this 2905 router is attached to some fixed network at the airline's 2906 headquarters, which is the router's home network. While 2907 the aircraft is in flight, this router registers from time 2908 to time over its radio link with a series of foreign agents 2909 below it on the ground. This router's home agent is a node 2910 on the fixed network at the airline's headquarters. 2912 c) Some correspondent node sends a datagram to the laptop 2913 computer, addressing the datagram to the laptop's home 2914 address. This datagram is initially routed to the laptop's 2915 home network. 2917 d) The laptop's home agent intercepts the datagram on the home 2918 network and tunnels it to the laptop's care-of address, which 2919 in this example is an address of the node serving as router 2920 and foreign agent on the aircraft. Normal IP routing will 2921 route the datagram to the fixed network at the airline's 2922 headquarters. 2924 e) The aircraft router and foreign agent's home agent there 2925 intercepts the datagram and tunnels it to its current care-of 2926 address, which in this example is some foreign agent on the 2927 ground below the aircraft. The original datagram from the 2928 correspondent node has now been encapsulated twice: once 2929 by the laptop's home agent and again by the aircraft's home 2930 agent. 2932 f) The foreign agent on the ground decapsulates the datagram, 2933 yielding a datagram still encapsulated by the laptop's home 2934 agent, with a destination address of the laptop's care-of 2935 address. The ground foreign agent sends the resulting 2936 datagram over its radio link to the aircraft. 2938 g) The foreign agent on the aircraft decapsulates the datagram, 2939 yielding the original datagram from the correspondent node, 2940 with a destination address of the laptop's home address. 2941 The aircraft foreign agent delivers the datagram over the 2942 aircraft network to the laptop's link-layer address. 2944 This example illustrated the case in which a mobile node is attached 2945 to a mobile network. That is, the mobile node is mobile with respect 2946 to the network, which itself is also mobile (here with respect to 2947 the ground). If, instead, the node is fixed with respect to the 2948 mobile network (the mobile network is the fixed node's home network), 2949 then either of two methods may be used to cause datagrams from 2950 correspondent nodes to be routed to the fixed node. 2952 A home agent MAY be configured to have a permanent registration for 2953 the fixed node, that indicates the mobile router's address as the 2954 fixed host's care-of address. The mobile router's home agent will 2955 usually be used for this purpose. The home agent is then responsible 2956 for advertising connectivity using normal routing protocols to the 2957 fixed node. Any datagrams sent to the fixed node will thus use 2958 nested tunneling as described above. 2960 Alternatively, the mobile router MAY advertise connectivity to the 2961 entire mobile network using normal IP routing protocols through a 2962 bi-directional tunnel to its own home agent. This method avoids the 2963 need for nested tunneling of datagrams. 2965 4.6. ARP, Proxy ARP, and Gratuitous ARP 2967 The use of ARP [16] requires special rules for correct operation when 2968 wireless or mobile nodes are involved. The requirements specified 2969 in this section apply to all home networks in which ARP is used for 2970 address resolution. 2972 In addition to the normal use of ARP for resolving a target node's 2973 link-layer address from its IP address, this document distinguishes 2974 two special uses of ARP: 2976 - A Proxy ARP [18] is an ARP Reply sent by one node on behalf 2977 of another node which is either unable or unwilling to answer 2978 its own ARP Requests. The sender of a Proxy ARP reverses the 2979 Sender and Target Protocol Address fields as described in [16], 2980 but supplies some configured link-layer address (generally, its 2981 own) in the Sender Hardware Address field. The node receiving 2982 the Reply will then associate this link-layer address with the 2983 IP address of the original target node, causing it to transmit 2984 future datagrams for this target node to the node with that 2985 link-layer address. 2987 - A Gratuitous ARP [23] is an ARP packet sent by a node in order to 2988 spontaneously cause other nodes to update an entry in their ARP 2989 cache. A gratuitous ARP MAY use either an ARP Request or an ARP 2990 Reply packet. In either case, the ARP Sender Protocol Address 2991 and ARP Target Protocol Address are both set to the IP address 2992 of the cache entry to be updated, and the ARP Sender Hardware 2993 Address is set to the link-layer address to which this cache 2994 entry should be updated. When using an ARP Reply packet, the 2995 Target Hardware Address is also set to the link-layer address to 2996 which this cache entry should be updated (this field is not used 2997 in an ARP Request packet). 2999 In either case, for a gratuitous ARP, the ARP packet MUST be 3000 transmitted as a local broadcast packet on the local link. As 3001 specified in [16], any node receiving any ARP packet (Request or 3002 Reply) MUST update its local ARP cache with the Sender Protocol 3003 and Hardware Addresses in the ARP packet, if the receiving node 3004 has an entry for that IP address already in its ARP cache. This 3005 requirement in the ARP protocol applies even for ARP Request 3006 packets, and for ARP Reply packets that do not match any ARP 3007 Request transmitted by the receiving node [16]. 3009 While a mobile node is registered on a foreign network, its home 3010 agent uses proxy ARP [18] to reply to ARP Requests it receives that 3011 seek the mobile node's link-layer address. When receiving an ARP 3012 Request, the home agent MUST examine the target IP address of the 3013 Request, and if this IP address matches the home address of any 3014 mobile node for which it has a registered mobility binding, the home 3015 agent MUST transmit an ARP Reply on behalf of the mobile node. After 3016 exchanging the sender and target addresses in the packet [18], the 3017 home agent MUST set the sender link-layer address in the packet to 3018 the link-layer address of its own interface over which the Reply will 3019 be sent. 3021 When a mobile node leaves its home network and registers a binding on 3022 a foreign network, its home agent uses gratuitous ARP to update the 3023 ARP caches of nodes on the home network. This causes such nodes to 3024 associate the link-layer address of the home agent with the mobile 3025 node's home (IP) address. When registering a binding for a mobile 3026 node for which the home agent previously had no binding (the mobile 3027 node was assumed to be at home), the home agent MUST transmit a 3028 gratuitous ARP on behalf of the mobile node. This gratuitous ARP 3029 packet MUST be transmitted as a broadcast packet on the link on which 3030 the mobile node's home address is located. Since broadcasts on the 3031 local link (such as Ethernet) are typically not guaranteed to be 3032 reliable, the gratuitous ARP packet SHOULD be retransmitted a small 3033 number of times to increase its reliability. 3035 When a mobile node returns to its home network, the mobile node 3036 and its home agent use gratuitous ARP to cause all nodes on the 3037 mobile node's home network to update their ARP caches to once again 3038 associate the mobile node's own link-layer address with the mobile 3039 node's home (IP) address. Before transmitting the (de)Registration 3040 Request message to its home agent, the mobile node MUST transmit this 3041 gratuitous ARP on its home network as a local broadcast on this link. 3042 The gratuitous ARP packet SHOULD be retransmitted a small number of 3043 times to increase its reliability, but these retransmissions SHOULD 3044 proceed in parallel with the transmission and processing of its 3045 (de)Registration Request. 3047 When the mobile node's home agent receives and accepts this 3048 (de)Registration Request, the home agent MUST also transmit a 3049 gratuitous ARP on the mobile node's home network. This gratuitous 3050 ARP also is used to associate the mobile node's home address with 3051 the mobile node's own link-layer address. A gratuitous ARP is 3052 transmitted by both the mobile node and its home agent, since in the 3053 case of wireless network interfaces, the area within transmission 3054 range of the mobile node will likely differ from that within range 3055 of its its home agent. Th ARP packet from the home agent MUST be 3056 transmitted as a local broadcast on the mobile node's home link, 3057 and SHOULD be retransmitted a small number of times to increase 3058 its reliability; these retransmissions, however, SHOULD proceed in 3059 parallel with the transmission and processing of its (de)Registration 3060 Reply. 3062 While the mobile node is away from home, it MUST NOT transmit any 3063 broadcast ARP Request or ARP Reply messages. Finally, while the 3064 mobile node is away from home, it MUST NOT reply to ARP Requests 3065 in which the target IP address is its own home address, unless the 3066 ARP Request is sent by a foreign agent with which the mobile node 3067 is attempting to register or a foreign agent with which the mobile 3068 node has an unexpired registration. In the latter case, the mobile 3069 node MUST use a unicast ARP Reply to respond to the foreign agent. 3070 Note that if the mobile node is using a co-located care-of address 3071 and receives an ARP Request in which the target IP address is this 3072 care-of address, then the mobile node SHOULD reply to this ARP 3073 Request. Note also that, when transmitting a Registration Request on 3074 a foreign network, a mobile node may discover the link-layer address 3075 of a foreign agent by storing the address as it is received from the 3076 Agent Advertisement from that foreign agent, but not by transmitting 3077 a broadcast ARP Request message. 3079 The specific order in which each of the above requirements for the 3080 use of ARP, proxy ARP, and gratuitous ARP are applied, relative to 3081 the transmission and processing of the mobile node's Registration 3082 Request and Registration Reply messages when leaving home or 3083 returning home, are important to the correct operation of the 3084 protocol. 3086 To summarize the above requirements, when a mobile node leaves its 3087 home network, the following steps, in this order, MUST be performed: 3089 - The mobile node decides to register away from home, perhaps 3090 because it has received an Agent Advertisement from a foreign 3091 agent and has not recently received one from its home agent. 3093 - Before transmitting the Registration Request, the mobile node 3094 disables its own future processing of any ARP Requests it 3095 may subsequently receive requesting the link-layer address 3096 corresponding to its home address, except insofar as necessary to 3097 communicate with foreign agents on visited networks. 3099 - The mobile node transmits its Registration Request. 3101 - When the mobile node's home agent receives and accepts the 3102 Registration Request, it performs a gratuitous ARP on behalf 3103 of the mobile node, and begins using proxy ARP to reply to ARP 3104 Requests that it receives requesting the mobile node's link-layer 3105 address. If, instead, the home agent rejects the Registration 3106 Request, no ARP processing (gratuitous nor proxy) is performed by 3107 the home agent. 3109 When a mobile node later returns to its home network, the following 3110 steps, in this order, MUST be performed: 3112 - The mobile node decides to register at home, perhaps because it 3113 has received an Agent Advertisement from its home agent. 3115 - Before transmitting the Registration Request, the mobile node 3116 re-enables its own future processing of any ARP Requests it may 3117 subsequently receive requesting its link-layer address. 3119 - The mobile node performs a gratuitous ARP for itself. 3121 - The mobile node transmits its Registration Request. 3123 - When the mobile node's home agent receives and accepts the 3124 Registration Request, it stops using proxy ARP to reply to 3125 ARP Requests that it receives requesting the mobile node's 3126 link-layer address, and then performs a gratuitous ARP on behalf 3127 of the mobile node. If, instead, the home agent rejects the 3128 Registration Request, no ARP processing (gratuitous nor proxy) is 3129 performed by the home agent. 3131 5. Security Considerations 3133 The mobile computing environment is potentially very different from 3134 the ordinary computing environment. In many cases, mobile computers 3135 will be connected to the network via wireless links. Such links 3136 are particularly vulnerable to passive eavesdropping, active replay 3137 attacks, and other active attacks. 3139 5.1. Message Authentication Codes 3141 Home agents and mobile nodes MUST be able to perform authentication. 3142 The default algorithm is keyed MD5 [21], with a key size of 128 3143 bits. The default mode of operation is to both precede and follow 3144 the data to be hashed, by the 128-bit key; that is, MD5 is to be 3145 used in "prefix+suffix" mode. The foreign agent MUST also support 3146 authentication using keyed MD5 and key sizes of 128 bits or greater, 3147 with manual key distribution. Keys with arbitrary binary values MUST 3148 be supported. More authentication algorithms, algorithm modes, key 3149 distribution methods, and key sizes MAY also be supported. 3151 5.2. Areas of Security Concern in this Protocol 3153 The registration protocol described in this document will result 3154 in a mobile node's traffic being tunneled to its care-of address. 3155 This tunneling feature could be a significant vulnerability if the 3156 registration were not authenticated. Such remote redirection, for 3157 instance as performed by the mobile registration protocol, is widely 3158 understood to be a security problem in the current Internet if not 3159 authenticated [2]. Moreover, the Address Resolution Protocol (ARP) 3160 is not authenticated, and can potentially be used to steal another 3161 host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings 3162 with it all of the risks associated with the use of ARP. 3164 5.3. Key Management 3166 This specification requires a strong authentication mechanism 3167 (keyed MD5) which precludes many potential attacks based on the 3168 Mobile IP registration protocol. However, because key distribution 3169 is difficult in the absence of a network key management protocol, 3170 messages with the foreign agent are not all required to be 3171 authenticated. In a commercial environment it might be important 3172 to authenticate all messages between the foreign agent and the home 3173 agent, so that billing is possible, and service providers do not 3174 provide service to users that are not legitimate customers of that 3175 service provider. 3177 5.4. Picking Good Random Numbers 3179 The strength of any authentication mechanism depends on several 3180 factors, including the innate strength of the authentication 3181 algorithm, the secrecy of the key used, the strength of the key used, 3182 and the quality of the particular implementation. This specification 3183 requires implementation of keyed MD5 for authentication, but does not 3184 preclude the use of other authentication algorithms and modes. For 3185 keyed MD5 authentication to be useful, the 128-bit key must be both 3186 secret (that is, known only to authorized parties) and pseudo-random. 3187 If nonces are used in connection with replay protection, they must 3188 also be selected carefully. Eastlake, et al. [7] provides more 3189 information on generating pseudo-random numbers. 3191 5.5. Privacy 3193 Users who have sensitive data that they do not wish others to see 3194 should use mechanisms outside the scope of this document (such as 3195 encryption) to provide appropriate protection. Users concerned about 3196 traffic analysis should consider appropriate use of link encryption. 3197 If absolute location privacy is desired, the mobile node can create a 3198 tunnel to its home agent. Then, datagrams destined for correspondent 3199 nodes will appear to emanate from the home network, and it may be 3200 more difficult to pinpoint the location of the mobile node. Such 3201 mechanisms are all beyond the scope of this document. 3203 5.6. Replay Protection for Registration Requests 3205 The Identification field is used to let the home agent verify that a 3206 registration message has been freshly generated by the mobile node, 3207 not replayed by an attacker from some previous registration. Two 3208 methods are described in this section: timestamps (mandatory) and 3209 "nonces" (optional). All mobile nodes and home agents MUST implement 3210 timestamp-based replay protection. These nodes MAY also implement 3211 nonce-based replay protection (but see Appendix A.2 for a patent that 3212 may apply to nonce-based replay protection). 3214 The style of replay protection in effect between a mobile node 3215 and its home agent is part of the mobile security association. A 3216 mobile node and its home agent MUST agree on which method of replay 3217 protection will be used. The interpretation of the Identification 3218 field depends on the method of replay protection as described in the 3219 subsequent subsections. 3221 Whatever method is used, the low-order 32 bits of the Identification 3222 MUST be copied unchanged from the Registration Request to the 3223 Reply. The foreign agent uses those bits (and the mobile node's 3224 home address) to match Registration Requests with corresponding 3225 replies. The mobile node MUST verify that the low-order 32 bits 3226 of any Registration Reply are identical to the bits it sent in the 3227 Registration Request. 3229 The Identification in a new Registration Request MUST NOT be the same 3230 as in an immediately preceding Request, and SHOULD NOT repeat while 3231 the same security context is being used between the mobile node and 3232 the home agent. Retransmission as in Section 3.6.3 is allowed. 3234 5.6.1. Replay Protection using Timestamps 3236 The basic principle of timestamp replay protection is that the node 3237 generating a message inserts the current time of day, and the node 3238 receiving the message checks that this timestamp is sufficiently 3239 close to its own time of day. Unless specified differently in the 3240 security association between the nodes, a value of 7 seconds may be 3241 used to limit the time difference. Obviously the two nodes must have 3242 adequately synchronized time-of-day clocks. As with any messages, 3243 time synchronization messages may be protected against tampering 3244 by an authentication mechanism determined by the security context 3245 between the two nodes. 3247 If timestamps are used, the mobile node MUST set the Identification 3248 field to a 64-bit value formatted as specified by the Network Time 3249 Protocol [13]. The low-order 32 bits of the NTP format represent 3250 fractional seconds, and those bits which are not available from a 3251 time source SHOULD be generated from a good source of randomness. 3252 Note, however, that when using timestamps, the 64-bit Identification 3253 used in a Registration Request from the mobile node MUST be greater 3254 than that used in any previous Registration Request, as the home 3255 agent uses this field also as a sequence number. Without such a 3256 sequence number, it would be possible for a delayed duplicate of an 3257 earlier Registration Request to arrive at the home agent (within 3258 the clock synchronization required by the home agent), and thus be 3259 applied out of order, mistakenly altering the mobile node's current 3260 registered care-of address. 3262 Upon receipt of a Registration Request with a valid Mobile-Home 3263 Authentication Extension, the home agent MUST check the 3264 Identification field for validity. In order to be valid, the 3265 timestamp contained in the Identification field MUST be close enough 3266 to the home agent's time of day clock and the timestamp MUST be 3267 greater than all previously accepted timestamps for the requesting 3268 mobile node. Time tolerances and resynchronization details are 3269 specific to a particular mobility security association. 3271 If the timestamp is valid, the home agent copies the entire 3272 Identification field into the Registration Reply it returns the Reply 3273 to the mobile node. If the timestamp is not valid, the home agent 3274 copies only the low-order 32 bits into the Registration Reply, and 3275 supplies the high-order 32 bits from its own time of day. In this 3276 latter case, the home agent MUST reject the registration by returning 3277 Code 133 (identification mismatch) in the Registration Reply. 3279 As described in Section 3.6.2.1, the mobile node MUST verify that the 3280 low-order 32 bits of the Identification in the Registration Reply are 3281 identical to those in the rejected registration attempt, before using 3282 the high-order bits for clock resynchronization. 3284 5.6.2. Replay Protection using Nonces 3286 Implementors of this optional mechanism should examine Appendix A.2 3287 for a patent that may be applicable to nonce-based replay protection. 3289 The basic principle of nonce replay protection is that node A 3290 includes a new random number in every message to node B, and 3291 checks that node B returns that same number in its next message to 3292 node A. Both messages use an authentication code to protect against 3293 alteration by an attacker. At the same time node B can send its own 3294 nonces in all messages to node A (to be echoed by node A), so that it 3295 too can verify that it is receiving fresh messages. 3297 The home agent may be expected to have resources for computing 3298 pseudo-random numbers useful as nonces [7]. It inserts a new nonce 3299 as the high-order 32 bits of the identification field of every 3300 Registration Reply. The home agent copies the low-order 32 bits 3301 of the Identification from the Registration Request message into 3302 the low-order 32 bits of the Identification in the Registration 3303 Reply. When the mobile node receives an authenticated Registration 3304 Reply from the home agent, it saves the high-order 32 bits of 3305 the identification for use as the high-order 32 bits of its next 3306 Registration Request. 3308 The mobile node is responsible for generating the low-order 32 bits 3309 of the Identification in each Registration Request. Ideally it 3310 should generate its own random nonces. However it may use any 3311 expedient method, including duplication of the random value sent by 3312 the home agent. The method chosen is of concern only to the mobile 3313 node, because it is the node that checks for valid values in the 3314 Registration Reply. The high-order and low-order 32 bits of the 3315 identification chosen SHOULD both differ from their previous values. 3316 The home agent uses a new high-order value and the mobile node uses 3317 a new low-order value for each registration message. The foreign 3318 agent uses the low-order value (and the mobile host's home address) 3319 to correctly match registration replies with pending Requests 3320 (Section 3.7.1). 3322 If a registration message is rejected because of an invalid nonce, 3323 the Reply always provides the mobile node with a new nonce to 3324 be used in the next registration. Thus the nonce protocol is 3325 self-synchronizing. 3327 6. Acknowledgments 3329 Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp 3330 and John Ioannidis (JI) (Columbia), for forming the working group, 3331 chairing it, and putting so much effort into its early development. 3333 Thanks also to Kannan Alaggapan, Greg Minshall, and Tony Li for 3334 their contributions to the group while performing the duties of 3335 chairperson, as well as for their many useful comments. 3337 Thanks to the active members of the Mobile IP Working Group, 3338 particularly those who contributed text, including (in alphabetical 3339 order) 3341 - Ran Atkinson (Naval Research Lab), 3342 - Dave Johnson (Carnegie Mellon University), 3343 - Frank Kastenholz (FTP Software), 3344 - Anders Klemets (KTH), 3345 - Chip Maguire (KTH), 3346 - Andrew Myles (Macquarie University), 3347 - Al Quirt (Bell Northern Research), 3348 - Yakov Rekhter (IBM), and 3349 - Fumio Teraoka (Sony). 3351 Thanks to Charlie Kunzinger and to Bill Simpson, the editors who 3352 produced the first drafts for of this document, reflecting the 3353 discussions of the Working Group. Much of the new text in the latest 3354 drafts is due to Jim Solomon and Dave Johnson. 3356 Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), and Frank 3357 Kastenholz (FTP Software) for their generous support in hosting 3358 interim Working Group meetings. 3360 A. Patent Issues 3362 As of the time of publication, the IETF had been made aware of 3363 two patents that may be relevant to implementors of the protocol 3364 described in this technical specification. 3366 A.1. IBM Patent #5,159,592 3368 Charles Perkins, editor of this draft, is sole inventor of 3369 U.S. Patent No. 5,159,592, assigned to IBM. In a letter dated 3370 May 30, 1995, IBM brought this patent to the attention of the IETF, 3371 stating that this patent "relates to the Mobile IP." We understand 3372 that IBM did not intend to assert that any particular implementation 3373 of Mobile IP would or would not infringe the patent, but rather that 3374 IBM was meeting what it viewed as a duty to disclose information that 3375 could be relevant to the process of adopting a standard. 3377 Based on a review of the claims of the patent, IETF believes that 3378 a system of registering an address obtained from a foreign agent, 3379 as described in the draft, would not necessarily infringe any of 3380 the claims of the patent; and that a system in which an address is 3381 obtained elsewhere and then registered can be implemented without 3382 necessarily infringing any claims of the patent. Accordingly, 3383 our view is that the proposed protocol can be implemented without 3384 necessarily infringing the Perkins Patent. 3386 Parties considering adopting this protocol must be aware that 3387 some specific implementations, or features added to otherwise 3388 non-infringing implementations, may raise an issue of infringement 3389 with respect to this patent or to some other patent. 3391 This statement is for the IETF's assistance in its standard-setting 3392 procedure, and should not be relied upon by any party as an opinion 3393 or guarantee that any implementation it might make or use would 3394 not be covered by the Perkins Patent and any other patents. In 3395 particular, IBM might disagree with the interpretation of this patent 3396 described herein. 3398 A.2. IBM Patent #5,148,479 3400 This patent, also assigned to IBM, may be relevant to those 3401 who implement nonce-based replay protection as described in 3402 Section 5.6.2. Note that nonce-based replay protection is an 3403 optional feature of this specification. Timestamp-based replay 3404 protection, on the other hand, (Section 5.6.1) is a requirement of 3405 this specification. 3407 B. Link-Layer Considerations 3409 The mobile node MAY use link-layer mechanisms to decide that its 3410 point of attachment has changed. Such indications include the 3411 Down/Testing/Up interface status [11], and changes in cell or 3412 administration. The mechanisms will be specific to the particular 3413 link-layer technology, and are outside the scope of this document. 3415 The Point-to-Point-Protocol (PPP) [22] and its Internet Protocol 3416 Control Protocol (IPCP) [12], negotiates the use of IP addresses. 3418 The mobile node SHOULD first attempt to specify its home address, 3419 so that if the mobile node is attaching to its home network, the 3420 unrouted link will function correctly. When the home address is 3421 not accepted by the peer, but a transient IP address is dynamically 3422 assigned to the mobile node, and the mobile node is capable of 3423 supporting a co-located care-of address, the mobile node MAY 3424 register that address as a co-located care-of address. When the peer 3425 specifies its own IP address, that address MUST NOT be assumed to be 3426 a foreign agent care-of address or the IP address of a home agent. 3428 C. TCP Considerations 3430 C.1. TCP Timers 3432 Most hosts and routers which implement TCP/IP do not permit easy 3433 configuration of the TCP timer values. When high-delay (e.g., 3434 SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are 3435 in use, the default TCP timer values in many systems may cause 3436 retransmissions or timeouts, even when the link and network are 3437 actually operating properly with greater than usual delays because 3438 of the medium in use. This can cause an inability to create or 3439 maintain TCP connections over such links, and can also cause unneeded 3440 retransmissions which consume already scarce bandwidth. Vendors are 3441 encouraged to make TCP timers more configurable. Vendors of systems 3442 designed for the mobile computing markets should pick default timer 3443 values more suited to low-bandwidth, high-delay links. Users of 3444 mobile nodes should be sensitive to the possibility of timer-related 3445 difficulties. 3447 C.2. TCP Congestion Management 3449 Mobile nodes often use media which are more likely to introduce 3450 errors, effectively causing more packets to be dropped. This 3451 introduces a conflict with the mechanisms for congestion management 3452 found in modern versions of TCP [9]. Now, when a packet is dropped, 3453 the correspondent node's TCP implementation is likely to react as 3454 if there were a source of network congestion, and initiate the 3455 slow-start mechanisms [9] designed for controlling that problem. 3456 However, those mechanisms are inappropriate for overcoming errors 3457 introduced by the links themselves, and have the effect of magnifying 3458 the discontinuity introduced by the dropped packet. This problem 3459 has been analyzed by Caceres, et al. [3]; there is no easy solution 3460 available, and certainly no solution likely to be installed soon on 3461 all correspondent nodes. While this problem is beyond the scope 3462 of this document, it does illustrate that providing performance 3463 transparency to mobile nodes involves understanding mechanisms 3464 outside the network layer. It also indicates the need to avoid 3465 designs which systematically drop packets; such designs might 3466 otherwise be considered favorably when making engineering tradeoffs. 3468 D. Example Scenarios 3470 This section shows example Registration Requests for several common 3471 scenarios. 3473 D.1. Registering with a Foreign Agent Care-of Address 3475 The mobile node receives an Agent Advertisement from a foreign 3476 agent and wishes to register with that agent using the advertised 3477 foreign agent care-of address. The mobile node wishes only 3478 IP-in-IP encapsulation, does not want broadcasts, and does not want 3479 simultaneous mobility bindings: 3481 IP fields: 3482 Source Address = mobile node's home address 3483 Destination Address = copied from the IP source address of the 3484 Agent Advertisement 3485 Time to Live = 1 3486 UDP fields: 3487 Source Port = 3488 Destination Port = 434 3489 Registration Request fields: 3490 Type = 1 3491 S=0,B=0,D=0,M=0,G=0 3492 Lifetime = the Registration Lifetime copied from the 3493 Mobility Agent Advertisement Extension of the 3494 Router Advertisement message 3495 Home Address = the mobile node's home address 3496 Home Agent = IP address of mobile node's home agent 3497 Care-of Address = the Care-of Address copied from the 3498 Mobility Agent Advertisement Extension of the 3499 Router Advertisement message 3500 Identification = Network Time Protocol timestamp or Nonce 3501 Extensions: 3502 The Mobile-Home Authentication Extension 3504 D.2. Registering with a Co-Located Care-of Address 3506 The mobile node enters a foreign network that contains no foreign 3507 agents. The mobile node obtains an address from a DHCP server [6] 3508 for use as a co-located care-of address. The mobile node supports 3509 all forms of encapsulation (IP-in-IP, minimal encapsulation, and 3510 GRE), desires a copy of broadcast datagrams on the home network, and 3511 does not want simultaneous mobility bindings: 3513 IP fields: 3514 Source Address = care-of address obtained from DHCP server 3515 Destination Address = IP address of home agent 3516 Time to Live = 64 3517 UDP fields: 3518 Source Port = 3519 Destination Port = 434 3520 Registration Request fields: 3521 Type = 1 3522 S=0,B=1,D=1,M=1,G=1 3523 Lifetime = 1800 (seconds) 3524 Home Address = the mobile node's home address 3525 Home Agent = IP address of mobile node's home agent 3526 Care-of Address = care-of address obtained from DHCP server 3527 Identification = Network Time Protocol timestamp or Nonce 3528 Extensions: 3529 The Mobile-Home Authentication Extension 3531 D.3. Deregistration 3533 The mobile node returns home and wishes to deregister all care-of 3534 addresses with its home agent. 3536 IP fields: 3537 Source Address = mobile node's home address 3538 Destination Address = IP address of home agent 3539 Time to Live = 1 3540 UDP fields: 3541 Source Port = 3542 Destination Port = 434 3543 Registration Request fields: 3544 Type = 1 3545 S=0,B=0,D=0,M=0,G=0 3546 Lifetime = 0 3547 Home Address = the mobile node's home address 3548 Home Agent = IP address of mobile node's home agent 3549 Care-of Address = the mobile node's home address 3550 Identification = Network Time Protocol timestamp or Nonce 3551 Extensions: 3552 The Mobile-Home Authentication Extension 3554 E. Applicability of Prefix Lengths Extension 3556 Caution is indicated with the use of the Prefix Lengths Extension 3557 over wireless links, due to the irregular coverage areas provided by 3558 wireless transmitters. As a result, it is possible that two foreign 3559 agents advertising the same prefix might indeed provide different 3560 connectivity to prospective mobile nodes. The Prefix-Lengths 3561 Extension SHOULD NOT be included in the advertisements sent by agents 3562 in such a configuration. 3564 Foreign agents using different wireless interfaces would have to 3565 cooperate using special protocols to provide identical coverage 3566 in space, and thus be able to claim to have wireless interfaces 3567 situated on the same subnetwork. In the case of wired interfaces, 3568 a mobile node disconnecting and subsequently connecting to a new 3569 point of attachment, may well send in a new Registration Request 3570 no matter whether the new advertisement is on the same medium as 3571 the last recorded advertisement. And, finally, in areas with dense 3572 populations of foreign agents it would seem unwise to require the 3573 propagation via routing protocols of the subnet prefixes associated 3574 with each individual wireless foreign agent; such a strategy could 3575 lead to quick depletion of available space for routing tables, 3576 unwarranted increases in the time required for processing routing 3577 updates, and longer decision times for route selection if routes 3578 (which are almost always unnecessary) are stored for wireless 3579 "subnets". 3581 References 3583 [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 3585 [2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. 3586 ACM Computer Communications Review, 19(2), March 1989. 3588 [3] Ramon Caceres and Liviu Iftode. Improving the Performance 3589 of Reliable Transport Protocols in Mobile Computing 3590 Environments. IEEE Journal on Selected Areas in Communications, 3591 13(5):850--857, June 1995. 3593 [4] Steve Deering. Host Extensions for IP Multicasting. RFC 1112, 3594 August 1989. 3596 [5] Stephen E. Deering, Editor. ICMP Router Discovery Messages. 3597 RFC 1256, September 1991. 3599 [6] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 3600 1997. 3602 [7] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. 3603 Randomness Recommendations for Security. RFC 1750, December 3604 1994. 3606 [8] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 3607 Routing Encapsulation (GRE). RFC 1701, October 1994. 3609 [9] Van Jacobson. Congestion Avoidance and Control. In 3610 Proceedings, SIGCOMM '88 Workshop, pages 314--329. ACM Press, 3611 August 1988. Stanford, CA. 3613 [10] Van Jacobson. Compressing TCP/IP Headers for Low-Speed Serial 3614 Links. RFC 1144, February 1990. 3616 [11] Keith McCloghrie and Frank Kastenholz. Evolution of the 3617 Interfaces Group of MIB-II. RFC 1573, January 1994. 3619 [12] Glenn McGregor. The PPP Internet Protocol Control Protocol 3620 (IPCP). RFC 1332, May 1992. 3622 [13] David L. Mills. Network Time Protocol (Version 3): 3623 Specification, Implementation and Analysis. RFC 1305, March 3624 1992. 3626 [14] Charles Perkins. IP Encapsulation within IP. RFC 2003, May 3627 1996. 3629 [15] Charles Perkins. Minimal Encapsulation within IP. RFC 2004, 3630 May 1996. 3632 [16] David C. Plummer. An Ethernet Address Resolution Protocol: 3633 Or Converting Network Protocol Addresses to 48.bit Ethernet 3634 Addresses for Transmission on Ethernet Hardware. RFC 826, 3635 November 1982. 3637 [17] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 3639 [18] J. B. Postel. Multi-LAN Address Resolution. RFC 925, October 3640 1984. 3642 [19] J. B. Postel, Editor. Internet Protocol. RFC 791, September 3643 1981. 3645 [20] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, 3646 October 1994. 3648 [21] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 3649 April 1992. 3651 [22] William Allen Simpson, editor. The Point-to-Point Protocol 3652 (PPP). RFC 1661, July 1994. 3654 [23] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The 3655 Protocols. Addison-Wesley, Reading, Massachusetts, 1994. 3657 Editor's Address 3659 Questions about this memo can also be directed to the editor: 3661 Charles Perkins 3662 Room H3-D34 3663 T. J. Watson Research Center 3664 IBM Corporation 3665 30 Saw Mill River Rd. 3666 Hawthorne, NY 10532 3668 Work: +1-914-784-7350 3669 Fax: +1-914-784-6205 3670 E-mail: perk@watson.ibm.com 3672 The working group can be contacted via the current chair: 3674 Jim Solomon 3675 Motorola, Inc. 3676 1301 E. Algonquin Rd. 3677 Schaumburg, IL 60196 3679 Work: +1-847-576-2753 3680 E-mail: solomon@comm.mot.com