idnits 2.17.1 draft-ietf-mobileip-protocol-17.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-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 474: '... A home agent MUST be able to attrac...' RFC 2119 keyword, line 480: '...'s home location MAY also be possible ...' RFC 2119 keyword, line 485: '... MUST be able to exchange datagrams ...' RFC 2119 keyword, line 494: '... the mobile node MAY also be possible ...' (408 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 (31 May 1996) is 10186 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 1541 (ref. '6') (Obsoleted by RFC 2131) ** 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) == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-ip4inip4-02 ** 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: 19 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins, editor 2 INTERNET DRAFT IBM 3 31 May 1996 5 IP Mobility Support 6 draft-ietf-mobileip-protocol-17.txt 8 Status of This Memo 10 This document is a submission by the Mobile IP Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the mobile-ip@SmallWorks.COM mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 This document specifies protocol enhancements that allow transparent 35 routing of IP datagrams to mobile nodes in the Internet. Each 36 mobile node is always identified by its home address, regardless of 37 its current point of attachment to the Internet. While situated 38 away from its home, a mobile node is also associated with a 39 care-of address, which provides information about its current 40 point of attachment to the Internet. The protocol provides for 41 registering the care-of address with a home agent. The home agent 42 sends datagrams destined for the mobile node through a tunnel to 43 the care-of address. After arriving at the end of the tunnel, each 44 datagram is then delivered to the mobile node. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 53 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 1 54 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 1 55 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 2 57 1.5. New Architectural Entities . . . . . . . . . . . . . . . 3 58 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 60 1.8. Specification Language . . . . . . . . . . . . . . . . . 9 61 1.9. Message Format and Protocol Extensibility . . . . . . . . 10 63 2. Agent Discovery 12 64 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 12 65 2.1.1. Mobility Agent Advertisement Extension . . . . . 14 66 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . 16 67 2.1.3. One-byte Padding Extension . . . . . . . . . . . 17 68 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 18 69 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 18 70 2.3.1. Advertised Router Addresses . . . . . . . . . . . 19 71 2.3.2. Sequence Numbers and Rollover Handling . . . . . 19 72 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 20 73 2.4.1. Registration Required . . . . . . . . . . . . . . 21 74 2.4.2. Move Detection . . . . . . . . . . . . . . . . . 21 75 2.4.3. Returning Home . . . . . . . . . . . . . . . . . 22 76 2.4.4. Sequence Numbers and Rollover Handling . . . . . 22 78 3. Registration 23 79 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 23 80 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 24 81 3.3. Registration Request . . . . . . . . . . . . . . . . . . 25 82 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 27 83 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 31 84 3.5.1. Computing Authentication Extension Values . . . . 31 85 3.5.2. Mobile-Home Authentication Extension . . . . . . 32 86 3.5.3. Mobile-Foreign Authentication Extension . . . . . 32 87 3.5.4. Foreign-Home Authentication Extension . . . . . . 33 88 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 34 89 3.6.1. Sending Registration Requests . . . . . . . . . . 35 90 3.6.2. Receiving Registration Replies . . . . . . . . . 39 91 3.6.3. Registration Retransmission . . . . . . . . . . . 41 92 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 42 93 3.7.1. Configuration and Registration Tables . . . . . . 43 94 3.7.2. Receiving Registration Requests . . . . . . . . . 43 95 3.7.3. Receiving Registration Replies . . . . . . . . . 46 96 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 48 97 3.8.1. Configuration and Registration Tables . . . . . . 48 98 3.8.2. Receiving Registration Requests . . . . . . . . . 49 99 3.8.3. Sending Registration Replies . . . . . . . . . . 52 101 4. Routing Considerations 55 102 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 55 103 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 55 104 4.2.1. Mobile Node Considerations . . . . . . . . . . . 55 105 4.2.2. Foreign Agent Considerations . . . . . . . . . . 56 106 4.2.3. Home Agent Considerations . . . . . . . . . . . . 57 107 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 58 108 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 59 109 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 60 110 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 62 112 5. Security Considerations 66 113 5.1. Message Authentication Codes . . . . . . . . . . . . . . 66 114 5.2. Areas of Security Concern in this Protocol . . . . . . . 66 115 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 66 116 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 67 117 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 67 118 5.6. Replay Protection for Registration Requests . . . . . . . 67 119 5.6.1. Replay Protection using Timestamps . . . . . . . 68 120 5.6.2. Replay Protection using Nonces . . . . . . . . . 69 122 6. Acknowledgments 70 124 A. Patent Issues 71 125 A.1. IBM Patent #5,159,592 . . . . . . . . . . . . . . . . . . 71 126 A.2. IBM Patent #5,148,479 . . . . . . . . . . . . . . . . . . 71 128 B. Link-Layer Considerations 72 130 C. TCP Considerations 73 131 C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 73 132 C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 73 134 D. Example Scenarios 74 135 D.1. Registering with a Foreign Agent Care-of Address . . . . 74 136 D.2. Registering with a Co-Located Care-of Address . . . . . . 74 137 D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 75 139 E. Applicability of Prefix Lengths Extension 76 141 Editor's Address 79 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 [4] 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. 459 It does, however, place additional burden on the IPv4 address space 460 because it requires a pool of addresses within the foreign network 461 to be made available to visiting mobile nodes. It is difficult to 462 efficiently maintain pools of addresses for each subnet that may 463 permit mobile nodes to visit. 465 It is important to understand the distinction between the care-of 466 address and the foreign agent functions. The care-of address is 467 simply the endpoint of the tunnel. It might indeed be an address 468 of a foreign agent (a foreign agent care-of address), but it might 469 instead be an address temporarily acquired by the mobile node (a 470 co-located care-of address). A foreign agent, on the other hand, 471 is a mobility agent that provides services to mobile nodes. See 472 Sections 3.7 and 4.2.2 for additional details. 474 A home agent MUST be able to attract and intercept datagrams that 475 are destined to the home address of any of its registered mobile 476 nodes. Using the proxy and gratuitous ARP mechanisms described in 477 Section 4.6, this requirement can be satisfied if the home agent has 478 a network interface on the link indicated by the mobile node's home 479 address. Other placements of the home agent relative to the mobile 480 node's home location MAY also be possible using other mechanisms for 481 intercepting datagrams destined to the mobile node's home address. 482 Such placements are beyond the scope of this document. 484 Similarly, a mobile node and a prospective or current foreign agent 485 MUST be able to exchange datagrams without relying on standard IP 486 routing mechanisms; that is, those mechanisms which make forwarding 487 decisions based upon the network-prefix of the destination address 488 in the IP header. This requirement can be satisfied if the foreign 489 agent and the visiting mobile node have an interface on the same 490 link. In this case, the mobile node and foreign agent simply 491 bypass their normal IP routing mechanism when sending datagrams to 492 each other, addressing the underlying link-layer packets to their 493 respective link-layer addresses. Other placements of the foreign 494 agent relative to the mobile node MAY also be possible using other 495 mechanisms to exchange datagrams between these nodes, but such 496 placements are beyond the scope of this document. 498 If a mobile node is using a co-located care-of address (as described 499 in (b) above), the mobile node MUST be located on the link identified 500 by the network prefix of this care-of address. Otherwise, datagrams 501 destined to the care-of address would be undeliverable. 503 For example, the figure below illustrates the routing of datagrams 504 to and from a mobile node away from home, once the mobile node has 505 registered with its home agent. In the figure below, the mobile node 506 is using a foreign agent care-of address: 508 2) Datagram is intercepted 3) Datagram is 509 by home agent and detunneled and 510 is tunneled to the delivered to the 511 care-of address. mobile node. 513 +-----+ +-------+ +------+ 514 |home | =======> |foreign| ------> |mobile| 515 |agent| | agent | <------ | node | 516 +-----+ +-------+ +------+ 517 1) Datagram to /|\ / 518 mobile node | / 4) For datagrams sent by the 519 arrives on | / mobile node, standard IP 520 home network | / routing delivers each to its 521 via standard | |_ destination. In this figure, 522 IP routing. +----+ the foreign agent is the 523 |host| mobile node's default router. 524 +----+ 526 1.8. Specification Language 528 In this document, several words are used to signify the requirements 529 of the specification. These words are often capitalized. 531 MUST This word, or the adjective "required", means that 532 the definition is an absolute requirement of the 533 specification. 535 MUST NOT This phrase means that the definition is an absolute 536 prohibition of the specification. 538 SHOULD This word, or the adjective "recommended", means 539 that, in some circumstances, valid reasons may exist 540 to ignore this item, but the full implications must 541 be understood and carefully weighed before choosing 542 a different course. Unexpected results may result 543 otherwise. 545 MAY This word, or the adjective "optional", means that this 546 item is one of an allowed set of alternatives. An 547 implementation which does not include this option MUST 548 be prepared to interoperate with another implementation 549 which does include the option. 551 silently discard 552 The implementation discards the datagram without 553 further processing, and without indicating an error 554 to the sender. The implementation SHOULD provide the 555 capability of logging the error, including the contents 556 of the discarded datagram, and SHOULD record the event 557 in a statistics counter. 559 1.9. Message Format and Protocol Extensibility 561 Mobile IP defines a set of new control messages, sent with UDP [17] 562 using well-known port number 434. Currently, the following two 563 message types are defined: 565 1 Registration Request 566 3 Registration Reply 568 Up-to-date values for the message types for Mobile IP control 569 messages are specified in the most recent "Assigned Numbers" [20]. 571 In addition, for Agent Discovery, Mobile IP makes use of the existing 572 Router Advertisement and Router Solicitation messages defined for 573 ICMP Router Discovery [4]. 575 Mobile IP defines a general Extension mechanism to allow optional 576 information to be carried by Mobile IP control messages or by ICMP 577 Router Discovery messages. Each of these Extensions (with one 578 exception) is encoded in the following Type-Length-Value format: 580 0 1 2 581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 583 | Type | Length | Data ... 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 586 Type Indicates the particular type of Extension. 588 Length Indicates the length (in bytes) of the data field within 589 this Extension. The length does NOT include the Type and 590 Length bytes. 592 Data The particular data associated with this Extension. This 593 field may be zero or more bytes in length. The format 594 and length of the data field is determined by the type 595 and length fields. 597 Extensions allow variable amounts of information to be carried within 598 each datagram. The end of the list of Extensions is indicated by the 599 total length of the IP datagram. 601 Two separately maintained sets of numbering spaces, from which 602 Extension Type values are allocated, are used in Mobile IP: 604 - The first set consists of those Extensions which may appear only 605 in Mobile IP control messages (those sent to and from UDP port 606 number 434). Currently, the following Types are defined for 607 Extensions appearing in Mobile IP control messages: 609 32 Mobile-Home Authentication 610 33 Mobile-Foreign Authentication 611 34 Foreign-Home Authentication 613 - The second set consists of those extensions which may appear only 614 in ICMP Router Discovery messages [4]. Currently, Mobile IP 615 defines the following Types for Extensions appearing in ICMP 616 Router Discovery messages: 618 0 One-byte Padding (encoded with no Length nor Data field) 619 16 Mobility Agent Advertisement 620 19 Prefix-Lengths 622 Each individual Extension is described in detail in a separate 623 section later in this document. Up-to-date values for these 624 Extension Type numbers are specified in the most recent "Assigned 625 Numbers" [20]. 627 Due to the separation (orthogonality) of these sets, it is 628 conceivable that two Extensions that are defined at a later date 629 could have identical Type values, so long as one of the Extensions 630 may be used only in Mobile IP control messages and the other may be 631 used only in ICMP Router Discovery messages. 633 When an Extension numbered in either of these sets within the range 0 634 through 127 is encountered but not recognized, the message containing 635 that Extension MUST be silently discarded. When an Extension 636 numbered in the range 128 through 255 is encountered which is not 637 recognized, that particular Extension is ignored, but the rest of 638 the Extensions and message data MUST still be processed. The Length 639 field of the Extension is used to skip the Data field in searching 640 for the next Extension. 642 2. Agent Discovery 644 Agent Discovery is the method by which a mobile node determines 645 whether it is currently connected to its home network or to a foreign 646 network, and by which a mobile node can detect when it has moved 647 from one network to another. When connected to a foreign network, 648 the methods specified in this section also allow the mobile node to 649 determine the foreign agent care-of address being offered by each 650 foreign agent on that network. 652 Mobile IP extends ICMP Router Discovery [4] as its primary 653 mechanism for Agent Discovery. An Agent Advertisement is formed by 654 including a Mobility Agent Advertisement Extension in an ICMP Router 655 Advertisement message (Section 2.1). An Agent Solicitation message 656 is identical to an ICMP Router Solicitation, except that its IP TTL 657 MUST be set to 1 (Section 2.2). This section describes the message 658 formats and procedures by which mobile nodes, foreign agents, and 659 home agents cooperate to realize Agent Discovery. 661 Agent Advertisement and Agent Solicitation may not be necessary 662 for link layers that already provide this functionality. The 663 method by which mobile nodes establish link-layer connections 664 with prospective agents is outside the scope of this document (but 665 see Appendix B). The procedures described below assume that such 666 link-layer connectivity has already been established. 668 No authentication is required for Agent Advertisement and Agent 669 Solicitation messages. They MAY be authenticated using the IP 670 Authentication Header [1], which is unrelated to the messages 671 described in this document. Further specification of the way in 672 which Advertisement and Solicitation messages may be authenticated is 673 outside of the scope of this document. 675 2.1. Agent Advertisement 677 Agent Advertisements are transmitted by a mobility agent to advertise 678 its services on a link. Mobile nodes use these advertisements to 679 determine their current point of attachment to the Internet. An 680 Agent Advertisement is an ICMP Router Advertisement that has been 681 extended to also carry an Mobility Agent Advertisement Extension 682 (Section 2.1.1) and, optionally, a Prefix-Lengths Extension 683 (Section 2.1.2), One-byte Padding Extension (Section 2.1.3), or other 684 Extensions that might be defined in the future. 686 Within an Agent Advertisement message, ICMP Router Advertisement 687 fields of the message are required to conform to the following 688 additional specifications: 690 - Link-Layer Fields 692 Destination Address 693 The link-layer destination address of a unicast 694 Agent Advertisement MUST be the same as the source 695 link-layer address of the Agent Solicitation which 696 prompted the Advertisement. 698 - IP Fields 700 TTL The TTL for all Agent Advertisements MUST be set 701 to 1. 703 Destination Address 704 As specified for ICMP Router Discovery [4], the IP 705 destination address of an Agent Advertisement MUST 706 be either the "all systems on this link" multicast 707 address (224.0.0.1) [5] or the "limited broadcast" 708 address (255.255.255.255). The subnet-directed 709 broadcast address of the form .<-1> cannot be 710 used since mobile nodes will not generally know the 711 prefix of the foreign network. 713 - ICMP Fields 715 Code The Code field of the agent advertisement is 716 interpreted as follows: 718 0 The mobility agent handles common traffic -- that 719 is, it acts as a router for IP datagrams not 720 necessarily related to mobile nodes. 721 16 The mobility agent does not route common traffic. 722 However, all foreign agents MUST (minimally) 723 forward to a default router any datagrams received 724 from a registered mobile node (Section 4.2.2). 726 Lifetime 727 The maximum length of time that the Advertisement 728 is considered valid in the absence of further 729 Advertisements. 731 Router Address(es) 732 See Section 2.3.1 for a discussion of the addresses 733 that may appear in this portion of the Agent 734 Advertisement. 736 Num Addrs 737 The number of Router Addresses advertised in this 738 message. Note that in an Agent Advertisement 739 message, the number of router addresses specified in 740 the ICMP Router Advertisement portion of the message 741 MAY be set to 0. See Section 2.3.1 for details. 743 If sent periodically, the nominal interval at which Agent 744 Advertisements are sent SHOULD be 1/3 of the advertisement Lifetime 745 given in the ICMP header. This allows a mobile node to miss three 746 successive advertisements before deleting the agent from its list of 747 valid agents. The actual transmission time for each advertisement 748 SHOULD be slightly randomized [4] in order to avoid synchronization 749 and subsequent collisions with other Agent Advertisements that may 750 be sent by other agents (or with other Router Advertisements sent 751 by other routers). Note that this field has no relation to the 752 "Registration Lifetime" field within the Mobility Agent Advertisement 753 Extension defined below. 755 2.1.1. Mobility Agent Advertisement Extension 757 The Mobility Agent Advertisement Extension follows the ICMP Router 758 Advertisement fields. It is used to indicate that an ICMP Router 759 Advertisement message is also an Agent Advertisement being sent by 760 a mobility agent. The Mobility Agent Advertisement Extension is 761 defined as follows: 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | Sequence Number | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Registration Lifetime |R|B|H|F|M|G|V| reserved | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | zero or more Care-of Addresses | 771 | ... | 773 Type 16 775 Length (6 + 4*N), where N is the number of care-of addresses 776 advertised. 778 Sequence Number 779 The count of Agent Advertisement messages sent since the 780 agent was initialized (Section 2.3.2). 782 Registration Lifetime 783 The longest lifetime (measured in seconds) that this 784 agent is willing to accept in any Registration Request. 785 A value of 0xffff indicates infinity. This field has no 786 relation to the "Lifetime" field within the ICMP Router 787 Advertisement portion of the Agent Advertisement. 789 R Registration required. Registration with this foreign 790 agent (or another foreign agent on this link) is required 791 rather than using a co-located care-of address. 793 B Busy. The foreign agent will not accept registrations 794 from additional mobile nodes. 796 H Home agent. This agent offers service as a home agent 797 on the link on which this Agent Advertisement message is 798 sent. 800 F Foreign agent. This agent offers service as a foreign 801 agent on the link on which this Agent Advertisement 802 message is sent. 804 M Minimal encapsulation. This agent implements receiving 805 tunneled datagrams that use minimal encapsulation [15]. 807 G GRE encapsulation. This agent implements receiving 808 tunneled datagrams that use GRE encapsulation [8]. 810 V Van Jacobson header compression. This agent supports use 811 of Van Jacobson header compression [10] over the link 812 with any registered mobile node. 814 reserved 815 Sent as zero; ignored on reception. 817 Care-of Address(es) 818 The advertised foreign agent care-of address(es) provided 819 by this foreign agent. An Agent Advertisement MUST 820 include at least one care-of address if the 'F' bit 821 is set. The number of care-of addresses present is 822 determined by the Length field in the Extension. 824 A home agent MUST always be prepared to serve the mobile nodes for 825 which it is the home agent. A foreign agent may at times be too busy 826 to serve additional mobile nodes; even so, it must continue to send 827 Agent Advertisements, so that any mobile nodes already registered 828 with it will know that they have not moved out of range of the 829 foreign agent and that the foreign agent has not failed. A foreign 830 agent may indicate that it is "too busy" to allow new mobile nodes to 831 register with it, by setting the 'B' bit in its Agent Advertisements. 832 An Agent Advertisement message MUST NOT have the 'B' bit set if the 833 'F' bit is not also set, and at least one of the 'F' bit and the 'H' 834 bit MUST be set in any Agent Advertisement message sent. 836 When a foreign agent wishes to require registration even from those 837 mobile nodes which have acquired a co-located care-of address, it 838 sets the 'R' bit to one. Because this bit applies only to foreign 839 agents, an agent MUST NOT set the 'R' bit to one unless the 'F' bit 840 is also set to one. 842 2.1.2. Prefix-Lengths Extension 844 The Prefix-Lengths Extension MAY follow the Mobility Agent 845 Advertisement Extension. It is used to indicate the number of bits 846 of network prefix that applies to each Router Address listed in the 847 ICMP Router Advertisement portion of the Agent Advertisement. Note 848 that the prefix lengths given DO NOT apply to care-of address(es) 849 listed in the Mobility Agent Advertisement Extension. The 850 Prefix-Lengths Extension is defined as follows: 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Type | Length | Prefix Length | .... 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Type 19 (Prefix-Lengths Extension) 860 Length N, where N is the value of the Num Addrs field in 861 the ICMP Router Advertisement portion of the Agent 862 Advertisement. 864 Prefix Length(s) 865 The number of leading bits that define the network number 866 of the corresponding Router Address listed in the ICMP 867 Router Advertisement portion of the message. The prefix 868 length for each Router Address is encoded as a separate 869 byte, in the order that the Router Addresses are listed 870 in the ICMP Router Advertisement portion of the message. 872 See Section 2.4.2 for information about how the Prefix Lengths 873 Extension MAY be used by a mobile node when determining whether it 874 has moved. See Appendix E for implementation details about the use 875 of this Extension. 877 2.1.3. One-byte Padding Extension 879 Some IP protocol implementations insist upon padding ICMP messages 880 to an even number of bytes. If the ICMP length of an Agent 881 Advertisement is odd, this Extension MAY be included in order to make 882 the ICMP length even. Note that this Extension is NOT intended to 883 be a general-purpose Extension to be included in order to word- or 884 long-align the various fields of the Agent Advertisement. An Agent 885 Advertisement SHOULD NOT include more than one One-byte Padding 886 Extension and if present, this Extension SHOULD be the last Extension 887 in the Agent Advertisement. 889 Note that unlike other Extensions used in Mobile IP, the One-byte 890 Padding Extension is encoded as a single byte, with no "Length" nor 891 "Data" field present. The One-byte Padding Extension is defined as 892 follows: 894 0 1 2 3 4 5 6 7 895 +-+-+-+-+-+-+-+-+ 896 | Type | 897 +-+-+-+-+-+-+-+-+ 899 Type 0 (One-byte Padding Extension) 901 2.2. Agent Solicitation 903 An Agent Solicitation is identical to an ICMP Router Solicitation 904 with the further restriction that the IP TTL Field MUST be set to 1. 906 2.3. Foreign Agent and Home Agent Considerations 908 Any mobility agent which cannot be discovered by a link-layer 909 protocol MUST send Agent Advertisements. An agent which can be 910 discovered by a link-layer protocol SHOULD also implement Agent 911 Advertisements. However, the Advertisements need not be sent, 912 except when the site policy requires registration with the agent 913 (i.e., when the 'R' bit is set), or as a response to a specific 914 Agent Solicitation. All mobility agents SHOULD respond to Agent 915 Solicitations. 917 The same procedures, defaults, and constants are used in Agent 918 Advertisement messages and Agent Solicitation messages as specified 919 for ICMP Router Discovery [4], except that: 921 - a mobility agent MUST limit the rate at which it sends broadcast 922 or multicast Agent Advertisements; a recommended maximum rate is 923 once per second, AND 925 - a mobility agent that receives a Router Solicitation MUST NOT 926 require that the IP Source Address is the address of a neighbor 927 (i.e., an address that matches one of the router's own addresses 928 on the arrival interface, under the subnet mask associated with 929 that address of the router). 931 - a mobility agent MAY be configured to send Agent Advertisements 932 only in response to an Agent Solicitation message. 934 If the home network is not a virtual network, then the home agent 935 for any mobile node SHOULD be located on the link identified by the 936 mobile node's home address, and Agent Advertisement messages sent by 937 the home agent on this link MUST have the 'H' bit set. In this way, 938 mobile nodes on their own home network will be able to determine that 939 they are indeed at home. Any Agent Advertisement messages sent by 940 the home agent on another link to which it may be attached (if it is 941 a mobility agent serving more than one link), MUST NOT have the 'H' 942 bit set, unless the home agent also serves as a home agent (to other 943 mobile nodes) on that other link. 945 If the home network is a virtual network, the home network has no 946 physical realization external to the home agent itself. In this 947 case, there is no physical network link on which to send Agent 948 Advertisement messages advertising the home agent. Mobile nodes for 949 which this is the home network are always treated as being away from 950 home. 952 On a particular subnet, either all mobility agents MUST include 953 the Prefix-Lengths Extension or all of them MUST NOT include this 954 Extension. Equivalently, it is prohibited for some agents on a given 955 subnet to include the Extension but for others not to include it. 956 Otherwise, one of the move detection algorithms designed for mobile 957 nodes will not function properly (Section 2.4.2). 959 2.3.1. Advertised Router Addresses 961 The ICMP Router Advertisement portion of the Agent Advertisement MAY 962 contain one or more router addresses. Thus, an agent MAY include 963 one of its own addresses in the advertisement. A foreign agent 964 MAY discourage use of this address as a default router by setting 965 the preference to a low value and by including the address of 966 another router in the advertisement (with a correspondingly higher 967 preference). Nevertheless, a foreign agent MUST route datagrams it 968 receives from registered mobile nodes (Section 4.2.2). 970 2.3.2. Sequence Numbers and Rollover Handling 972 The sequence number in Agent Advertisements ranges from 0 to 973 0xffff. After booting, an agent MUST use the number 0 for its first 974 advertisement. Each subsequent advertisement MUST use the sequence 975 number one greater, with the exception that the sequence number 976 0xffff MUST be followed by sequence number 256. In this way, mobile 977 nodes can distinguish reductions in sequence numbers that result from 978 reboots, from reductions that result in rollover of the sequence 979 number after it attains the value 0xffff. 981 2.4. Mobile Node Considerations 983 Every mobile node MUST implement Agent Solicitation. Solicitations 984 SHOULD only be sent in the absence of Agent Advertisements and when a 985 care-of address has not been determined through a link-layer protocol 986 or other means. The mobile node uses the same procedures, defaults, 987 and constants for Agent Solicitation as specified for ICMP Router 988 Solicitation messages [4], except that the mobile node MAY solicit 989 more often than once every three seconds, and that a mobile node that 990 is currently not connected to any foreign agent MAY solicit more 991 times than MAX_SOLICITATIONS. 993 The rate at which a mobile node sends Solicitations MUST be 994 limited by the mobile node. The mobile node MAY send three initial 995 Solicitations at a maximum rate of one per second while searching for 996 an agent. After this, the rate at which Solicitations are sent MUST 997 be reduced so as to limit the overhead on the local link. Subsequent 998 Solicitations MUST be sent using a binary exponential backoff 999 mechanism, doubling the interval between consecutive Solicitations, 1000 up to a maximum interval. The maximum interval SHOULD be chosen 1001 appropriately based upon the characteristics of the media over which 1002 the mobile node is soliciting. This maximum interval SHOULD be at 1003 least one minute between Solicitations. 1005 While still searching for an agent, the mobile node MUST NOT increase 1006 the rate at which it sends Solicitations unless it has received 1007 a positive indication that it has moved to a new link. After 1008 successfully registering with an agent, the mobile node SHOULD 1009 also increase the rate at which it will send Solicitations when it 1010 next begins searching for a new agent with which to register. The 1011 increased solicitation rate MAY revert to the maximum rate, but then 1012 MUST be limited in the manner described above. In all cases, the 1013 recommended solicitation intervals are nominal values. Mobile nodes 1014 MUST randomize their solicitation times around these nominal values 1015 as specified for ICMP Router Discovery [4]. 1017 Mobile nodes MUST process received Agent Advertisements. A mobile 1018 node can distinguish an Agent Advertisement message from other uses 1019 of the ICMP Router Advertisement message by examining the number 1020 of advertised addresses and the IP Total Length field. When the 1021 IP total length indicates that the ICMP message is longer than 1022 needed for the number of advertised addresses, the remaining data is 1023 interpreted as one or more Extensions. The presence of a Mobility 1024 Agent Advertisement Extension identifies the advertisement as an 1025 Agent Advertisement. 1027 When multiple methods of agent discovery are in use, the mobile node 1028 SHOULD first attempt registration with agents including Mobility 1029 Agent Advertisement Extensions in their advertisements, in preference 1030 to those discovered by other means. This preference maximizes 1031 the likelihood that the registration will be recognized, thereby 1032 minimizing the number of registration attempts. 1034 2.4.1. Registration Required 1036 When the mobile node receives an Agent Advertisement with the 'R' 1037 bit set, the mobile node SHOULD register through the foreign agent, 1038 even when the mobile node might be able to acquire its own co-located 1039 care-of address. This feature is intended to allow sites to enforce 1040 visiting policies (such as accounting) which require exchanges of 1041 authorization. 1043 2.4.2. Move Detection 1045 Two primary mechanisms are provided for mobile nodes to detect when 1046 they have moved from one subnet to another. Other mechanisms MAY 1047 also be used. When the mobile node detects that it has moved, it 1048 SHOULD register (Section 3) with a suitable care-of address on the 1049 new foreign network. However, the mobile node MUST NOT register 1050 more frequently than once per second on average, as specified in 1051 Section 3.6.3. 1053 2.4.2.1. Algorithm 1 1055 The first method of move detection is based upon the Lifetime field 1056 within the main body of the ICMP Router Advertisement portion of 1057 the Agent Advertisement. A mobile node SHOULD record the Lifetime 1058 received in any Agent Advertisements, until that Lifetime expires. 1059 If the mobile node fails to receive another advertisement from the 1060 same agent within the specified Lifetime, it SHOULD assume that it 1061 has lost contact with that agent. If the mobile node has previously 1062 received an Agent Advertisement from another agent for which the 1063 Lifetime field has not yet expired, the mobile node MAY immediately 1064 attempt registration with that other agent. Otherwise, the mobile 1065 node SHOULD attempt to discover a new agent with which to register. 1067 2.4.2.2. Algorithm 2 1069 The second method uses network prefixes. The Prefix-Lengths 1070 Extension MAY be used in some cases by a mobile node to determine 1071 whether or not a newly received Agent Advertisement was received on 1072 the same subnet as the mobile node's current care-of address. If the 1073 prefixes differ, the mobile node MAY assume that it has moved. If 1074 a mobile node is currently using a foreign agent care-of address, 1075 the mobile node SHOULD NOT use this method of move detection unless 1076 both the current agent and the new agent include the Prefix-Lengths 1077 Extension in their respective Agent Advertisements; if this Extension 1078 is missing from one or both of the advertisements, this method of 1079 move detection SHOULD NOT be used. Similarly, if a mobile node is 1080 using a co-located care-of address, it SHOULD not use this method 1081 of move detection unless the new agent includes the Prefix-Lengths 1082 Extension in its Advertisement and the mobile node knows the network 1083 prefix of its current co-located care-of address. On the expiration 1084 of its current registration, if this method indicates that the 1085 mobile node has moved, rather than re-registering with its current 1086 care-of address, a mobile node MAY choose instead to register 1087 with a the foreign agent sending the new Advertisement with the 1088 different network prefix. The Agent Advertisement on which the new 1089 registration is based MUST NOT have expired according to its Lifetime 1090 field. 1092 2.4.3. Returning Home 1094 A mobile node can detect that it has returned to its home network 1095 when it receives an Agent Advertisement from its own home agent. If 1096 so, it SHOULD deregister with its home agent (Section 3). Before 1097 attempting to deregister, the mobile node SHOULD configure its 1098 routing table appropriately for its home network (Section 4.2.1). In 1099 addition, if the home network is using ARP [16], the mobile node MUST 1100 follow the procedures described in Section 4.6 with regard to ARP, 1101 proxy ARP, and gratuitous ARP. 1103 2.4.4. Sequence Numbers and Rollover Handling 1105 If a mobile node detects two successive values of the sequence number 1106 in the Agent Advertisements from the foreign agent with which it is 1107 registered, the second of which is less than the first and inside the 1108 range 0 to 255, the mobile node SHOULD register again. If the second 1109 value is less than the first but is greater than or equal to 256, 1110 the mobile node SHOULD assume that the sequence number has rolled 1111 over past its maximum value (0xffff), and that reregistration is not 1112 necessary (Section 2.3). 1114 3. Registration 1116 Mobile IP registration provides a flexible mechanism for mobile nodes 1117 to communicate their current reachability information to their home 1118 agent. It is the method by which mobile nodes: 1120 - request forwarding services when visiting a foreign network, 1122 - inform their home agent of their current care-of address, 1124 - renew a registration which is due to expire, and/or 1126 - deregister when they return home. 1128 Registration messages exchange information between a mobile node, 1129 (optionally) a foreign agent, and the home agent. Registration 1130 creates or modifies a mobility binding at the home agent, associating 1131 the mobile node's home address with its care-of address for the 1132 specified Lifetime. 1134 Several other (optional) capabilities are available through the 1135 registration procedure, which enable a mobile node to: 1137 - maintain multiple simultaneous registrations, so that a copy of 1138 each datagram will be tunneled to each active care-of address 1140 - deregister specific care-of addresses while retaining other 1141 mobility bindings, and 1143 - discover the address of a home agent if the mobile node is not 1144 configured with this information. 1146 3.1. Registration Overview 1148 Mobile IP defines two different registration procedures, one via 1149 a foreign agent that relays the registration to the mobile node's 1150 home agent, and one directly with the mobile node's home agent. The 1151 following rules determine which of these two registration procedures 1152 to use in any particular circumstance: 1154 - If a mobile node is registering a foreign agent care-of address, 1155 the mobile node MUST register via that foreign agent. 1157 - If a mobile node is using a co-located care-of address, and 1158 receives an Agent Advertisement from a foreign agent on the 1159 link on which it is using this care-of address, the mobile node 1160 SHOULD register via that foreign agent (or via another foreign 1161 agent on this link) if the 'R' bit is set in the received Agent 1162 Advertisement message. 1164 - If a mobile node is otherwise using a co-located care-of address, 1165 the mobile node MUST register directly with its home agent. 1167 - If a mobile node has returned to its home network and is 1168 (de)registering with its home agent, the mobile node MUST 1169 register directly with its home agent. 1171 Both registration procedures involve the exchange of Registration 1172 Request and Registration Reply messages (Sections 3.3 and 3.4). When 1173 registering via a foreign agent, the registration procedure requires 1174 the following four messages: 1176 a) The mobile node sends a Registration Request to the 1177 prospective foreign agent to begin the registration process. 1179 b) The foreign agent processes the Registration Request and then 1180 relays it to the home agent. 1182 c) The home agent sends a Registration Reply to the foreign 1183 agent to grant or deny the Request. 1185 d) The foreign agent processes the Registration Reply and then 1186 relays it to the mobile node to inform it of the disposition 1187 of its Request. 1189 When the mobile node instead registers directly with its home agent, 1190 the registration procedure requires only the following two messages: 1192 a) The mobile node sends a Registration Request to the home 1193 agent. 1195 b) The home agent sends a Registration Reply to the mobile node, 1196 granting or denying the Request. 1198 The registration messages defined in Sections 3.3 and 3.4 use the 1199 User Datagram Protocol (UDP) [17]. A nonzero UDP checksum SHOULD be 1200 included in the header, and MUST be checked by the recipient. 1202 3.2. Authentication 1204 Each mobile node, foreign agent, and home agent MUST be able to 1205 support a mobility security association for mobile entities, indexed 1206 by their SPI and IP address. In the case of the mobile node, this 1207 must be its Home Address. See Section 5.1 for requirements for 1208 support of authentication algorithms. Registration messages between 1209 a mobile node and its home agent MUST be authenticated with the 1210 Mobile-Home Authentication Extension (Section 3.5.2). This Extension 1211 immediately follows all non-authentication Extensions, except those 1212 foreign agent-specific Extensions which may be added to the message 1213 after the mobile node computes the authentication. 1215 3.3. Registration Request 1217 A mobile node registers with its home agent using a Registration 1218 Request message so that its home agent can create or modify a 1219 mobility binding for that mobile node (e.g., with a new lifetime). 1220 The Request may be relayed to the home agent by the foreign agent 1221 through which the mobile node is registering, or it may be sent 1222 directly to the home agent in the case in which the mobile node is 1223 registering a co-located care-of address. 1225 IP fields: 1227 Source Address Typically the interface address from which the 1228 message is sent. 1230 Destination Address Typically that of the foreign agent or the 1231 home agent. 1233 See Sections 3.6.1.1 and 3.7.2.2 for details. 1235 UDP fields: 1237 Source Port variable 1239 Destination Port 434 1241 The UDP header is followed by the Mobile IP fields shown below: 1243 0 1 2 3 1244 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 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Type |S|B|D|M|G|V|rsv| Lifetime | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Home Address | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Home Agent | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Care-of Address | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | | 1255 + Identification + 1256 | | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Extensions ... 1259 +-+-+-+-+-+-+-+- 1261 Type 1 (Registration Request) 1263 S Simultaneous bindings. If the 'S' bit is set, the mobile 1264 node is requesting that the home agent retain its prior 1265 mobility bindings, as described in Section 3.6.1.2. 1267 B Broadcast datagrams. If the 'B' bit is set, the mobile 1268 node requests that the home agent tunnel to it any 1269 broadcast datagrams that it receives on the home network, 1270 as described in Section 4.3. 1272 D Decapsulation by mobile node. If the 'D' bit is set, the 1273 mobile node will itself decapsulate datagrams which are 1274 sent to the care-of address. That is, the mobile node is 1275 using a co-located care-of address. 1277 M Minimal encapsulation. If the 'M' bit is set, the 1278 mobile node requests that its home agent use minimal 1279 encapsulation [15] for datagrams tunneled to the mobile 1280 node. 1282 G GRE encapsulation. If the 'G' bit is set, the 1283 mobile node requests that its home agent use GRE 1284 encapsulation [8] for datagrams tunneled to the mobile 1285 node. 1287 V The mobile node requests that its mobility agent use Van 1288 Jacobson header compression [10] over its link with the 1289 mobile node. 1291 rsv Reserved bits; sent as zero 1293 Lifetime 1294 The number of seconds remaining before the registration 1295 is considered expired. A value of zero indicates a 1296 request for deregistration. A value of 0xffff indicates 1297 infinity. 1299 Home Address 1300 The IP address of the mobile node. 1302 Home Agent 1303 The IP address of the mobile node's home agent. 1305 Care-of Address 1306 The IP address for the end of the tunnel. 1308 Identification 1309 A 64-bit number, constructed by the mobile node, used for 1310 matching Registration Requests with Registration Replies, 1311 and for protecting against replay attacks of registration 1312 messages. See Sections 5.4 and 5.6. 1314 Extensions 1315 The fixed portion of the Registration Request is followed 1316 by one or more of the Extensions listed in Section 3.5. 1317 The Mobile-Home Authentication Extension MUST be included 1318 in all Registration Requests. See Sections 3.6.1.3 1319 and 3.7.2.2 for information on the relative order in 1320 which different extensions, when present, MUST be placed 1321 in a Registration Request message. 1323 3.4. Registration Reply 1325 A mobility agent returns a Registration Reply message to a mobile 1326 node which has sent a Registration Request (Section 3.3) message. 1327 If the mobile node is requesting service from a foreign agent, 1328 that foreign agent will receive the Reply from the home agent and 1329 subsequently relay it to the mobile node. The Reply message contains 1330 the necessary codes to inform the mobile node about the status of its 1331 Request, along with the lifetime granted by the home agent, which MAY 1332 be smaller than the original Request. 1334 The foreign agent MUST NOT increase the Lifetime selected by the 1335 mobile node in the Registration Request, since the Lifetime is 1336 covered by the Mobile-Home Authentication Extension, which cannot 1337 be correctly (re)computed by the foreign agent. The home agent 1338 MUST NOT increase the Lifetime selected by the mobile node in the 1339 Registration Request, since doing so could increase it beyond the 1340 maximum Registration Lifetime allowed by the foreign agent. If the 1341 Lifetime received in the Registration Reply is greater than that in 1342 the Registration Request, the Lifetime in the Request MUST be used. 1343 When the Lifetime received in the Registration Reply is less than 1344 that in the Registration Request, the Lifetime in the Reply MUST be 1345 used. 1347 IP fields: 1349 Source Address Typically copied from the destination 1350 address of the Registration Request to which 1351 the agent is replying. See Sections 3.7.2.3 1352 and 3.8.3.1 for complete details. 1354 Destination Address Copied from the source address of the 1355 Registration Request to which the agent is 1356 replying 1358 UDP fields: 1360 Source Port 1362 Destination Port Copied from the source port of the 1363 corresponding Registration Request 1364 (Section 3.7.1). 1366 The UDP header is followed by the Mobile IP fields shown below: 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Type | Code | Lifetime | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Home Address | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Home Agent | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | | 1378 + Identification + 1379 | | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Extensions ... 1382 +-+-+-+-+-+-+-+- 1384 Type 3 (Registration Reply) 1386 Code A value indicating the result of the Registration 1387 Request. See below for a list of currently defined Code 1388 values. 1390 Lifetime 1391 If the Code field indicates that the registration was 1392 accepted, the Lifetime field is set to the number of 1393 seconds remaining before the registration is considered 1394 expired. A value of zero indicates that the mobile node 1395 has been deregistered. A value of 0xffff indicates 1396 infinity. If the Code field indicates that the 1397 registration was denied, the contents of the Lifetime 1398 field are unspecified and MUST be ignored on reception. 1400 Home Address 1401 The IP address of the mobile node. 1403 Home Agent 1404 The IP address of the mobile node's home agent. 1406 Identification 1407 A 64-bit number used for matching Registration Requests 1408 with Registration Replies, and for protecting against 1409 replay attacks of registration messages. The value is 1410 based on the Identification field from the Registration 1411 Request message from the mobile node, and on the style of 1412 replay protection used in the security context between 1413 the mobile node and its home agent (defined by the 1414 mobility security association between them, and SPI 1415 value in the Mobile-Home Authentication Extension). See 1416 Sections 5.4 and 5.6. 1418 Extensions 1419 The fixed portion of the Registration Reply is followed 1420 by one or more of the Extensions listed in Section 3.5. 1421 The Mobile-Home Authentication Extension MUST be included 1422 in all Registration Replies returned by the home agent. 1423 See Sections 3.7.2.2 and 3.8.3.3 for rules on placement 1424 of extensions to Reply messages. 1426 The following values are defined for use within the Code field. 1427 Registration successful: 1429 0 registration accepted 1430 1 registration accepted, but simultaneous mobility 1431 bindings unsupported 1433 Registration denied by the foreign agent: 1435 64 reason unspecified 1436 65 administratively prohibited 1437 66 insufficient resources 1438 67 mobile node failed authentication 1439 68 home agent failed authentication 1440 69 requested Lifetime too long 1441 70 poorly formed Request 1442 71 poorly formed Reply 1443 72 requested encapsulation unavailable 1444 73 requested Van Jacobson compression unavailable 1445 80 home network unreachable (ICMP error received) 1446 81 home agent host unreachable (ICMP error received) 1447 82 home agent port unreachable (ICMP error received) 1448 88 home agent unreachable (other ICMP error received) 1450 Registration denied by the home agent: 1452 128 reason unspecified 1453 129 administratively prohibited 1454 130 insufficient resources 1455 131 mobile node failed authentication 1456 132 foreign agent failed authentication 1457 133 registration Identification mismatch 1458 134 poorly formed Request 1459 135 too many simultaneous mobility bindings 1460 136 unknown home agent address 1462 Up-to-date values of the Code field are specified in the most recent 1463 "Assigned Numbers" [20]. 1465 3.5. Registration Extensions 1467 3.5.1. Computing Authentication Extension Values 1469 The Authenticator value computed for each authentication Extension 1470 MUST protect the following fields from the registration message: 1472 - the UDP payload (that is, the Registration Request or 1473 Registration Reply data), 1475 - all prior Extensions in their entirety, and 1477 - the Type and Length of this Extension. 1479 The default authentication algorithm uses keyed-MD5 [21] in 1480 "prefix+suffix" mode to compute a 128-bit "message digest" of the 1481 registration message. The default authenticator is a 128-bit value 1482 computed as the MD5 checksum over the the following stream of bytes: 1484 - the shared secret defined by the mobility security association 1485 between the nodes and by SPI value specified in the 1486 authentication Extension, followed by 1488 - the protected fields from the registration message, in the order 1489 specified above, followed by 1491 - the shared secret again. 1493 Note that the Authenticator field itself and the UDP header are NOT 1494 included in the computation of the default Authenticator value. 1495 See Section 5.1 for information about support requirements for 1496 message authentication codes, which are to be used with the various 1497 authentication Extensions. 1499 The Security Parameter Index (SPI) within any of the authentication 1500 Extensions defines the security context which is used to compute 1501 the Authenticator value and which MUST be used by the receiver to 1502 check that value. In particular, the SPI selects the authentication 1503 algorithm and mode (Section 5.1) and secret (a shared key, or 1504 appropriate public/private key pair) used in computing the 1505 Authenticator. In order to ensure interoperability between different 1506 implementations of the Mobile IP protocol, an implementation MUST be 1507 able to associate any SPI value with any authentication algorithm 1508 and mode which it implements. In addition, all implementations 1509 of Mobile IP MUST implement the default authentication algorithm 1510 (keyed-MD5) and mode ("prefix+suffix") defined above. 1512 3.5.2. Mobile-Home Authentication Extension 1514 Exactly one Mobile-Home Authentication Extension MUST be present 1515 in all Registration Requests and Registration Replies, and is 1516 intended to eliminate problems [2] which result from the uncontrolled 1517 propagation of remote redirects in the Internet. The location of the 1518 extension marks the end of the authenticated data. 1520 0 1 2 3 1521 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 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Type | Length | SPI .... 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 ... SPI (cont.) | Authenticator ... 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 Type 32 1530 Length 4 plus the number of bytes in the Authenticator. 1532 SPI Security Parameter Index (4 bytes). An opaque 1533 identifier (see Section 1.6). 1535 Authenticator (variable length) (See Section 3.5.1.) 1537 3.5.3. Mobile-Foreign Authentication Extension 1539 This Extension MAY be included in Registration Requests and Replies 1540 in cases in which a mobility security association exists between the 1541 mobile node and the foreign agent. See Section 5.1 for information 1542 about support requirements for message authentication codes. 1544 0 1 2 3 1545 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 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | Type | Length | SPI .... 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 ... SPI (cont.) | Authenticator ... 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 Type 33 1554 Length 4 plus the number of bytes in the Authenticator. 1556 SPI Security Parameter Index (4 bytes). An opaque 1557 identifier (see Section 1.6). 1559 Authenticator (variable length) (See Section 3.5.1.) 1561 3.5.4. Foreign-Home Authentication Extension 1563 This Extension MAY be included in Registration Requests and Replies 1564 in cases in which a mobility security association exists between the 1565 foreign agent and the home agent. See Section 5.1 for information 1566 about support requirements for message authentication codes. 1568 0 1 2 3 1569 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 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | Type | Length | SPI .... 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 ... SPI (cont.) | Authenticator ... 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 Type 34 1578 Length 4 plus the number of bytes in the Authenticator. 1580 SPI Security Parameter Index (4 bytes). An opaque 1581 identifier (see Section 1.6). 1583 Authenticator (variable length) (See Section 3.5.1.) 1585 3.6. Mobile Node Considerations 1587 A mobile node MUST be configured with its home address, a netmask, 1588 and a mobility security association for each home agent. In 1589 addition, a mobile node MAY be configured with the IP address of one 1590 or more of its home agents; otherwise, the mobile node MAY discover a 1591 home agent using the procedures described in Section 3.6.1.2. 1593 For each pending registration, the mobile node maintains the 1594 following information: 1596 - the link-layer address of the foreign agent to which the 1597 Registration Request was sent, if applicable, 1598 - the IP destination address of the Registration Request, 1599 - the care-of address used in the registration, 1600 - the Identification value sent in the registration, 1601 - the originally requested Lifetime, and 1602 - the remaining Lifetime of the pending registration. 1604 A mobile node SHOULD initiate a registration whenever it detects a 1605 change in its network connectivity. See Section 2.4.2 for methods by 1606 which mobile nodes MAY make such a determination. When it is away 1607 from home, the mobile node's Registration Request allows its home 1608 agent to create or modify a mobility binding for it. When it is at 1609 home, the mobile node's (de)Registration Request allows its home 1610 agent to delete any previous mobility binding(s) for it. A mobile 1611 node operates without the support of mobility functions when it is at 1612 home. 1614 There are other conditions under which the mobile node SHOULD 1615 (re)register with its foreign agent, such as when the mobile 1616 node detects that the foreign agent has rebooted (as specified in 1617 Section 2.4.4) and when the current registration's Lifetime is near 1618 expiration. 1620 In the absence of link-layer indications of changes in point 1621 of attachment, Agent Advertisements from new agents SHOULD NOT 1622 cause a mobile node to attempt a new registration, if its current 1623 registration has not expired and it is still also receiving Agent 1624 Advertisements from the foreign agent with which it is currently 1625 registered. In the absence of link-layer indications, a mobile node 1626 MUST NOT attempt to register more often than once per second. 1628 A mobile node MAY register with a different agent when 1629 transport-layer protocols indicate excessive retransmissions. 1630 A mobile node MUST NOT consider reception of an ICMP Redirect from 1631 a foreign agent that is currently providing service to it as reason 1632 to register with a new foreign agent. Within these constraints, the 1633 mobile node MAY register again at any time. 1635 Appendix D shows some examples of how the fields in registration 1636 messages would be set up in some typical registration scenarios. 1638 3.6.1. Sending Registration Requests 1640 The following sections specify details for the values the mobile node 1641 MUST supply in the fields of Registration Request messages. 1643 3.6.1.1. IP Fields 1645 This section provides the specific rules by which mobile nodes pick 1646 values for the IP header fields of a Registration Request. 1648 IP Source Address: 1650 - When registering on a foreign network with a co-located care-of 1651 address, the IP source address MUST be the care-of address. 1653 - In all other circumstances, the IP source address MUST be the 1654 mobile node's home address. 1656 IP Destination Address: 1658 - When the mobile node has discovered the agent with which it is 1659 registering, through some means (e.g., link-layer) that does not 1660 provide the IP address of the agent (the IP address of the agent 1661 is unknown to the mobile node), then the "All Mobility Agents" 1662 multicast address (224.0.0.11) MUST be used. In this case, the 1663 mobile node MUST use the agent's link-layer unicast address in 1664 order to deliver the datagram to the correct agent. 1666 - When registering with a foreign agent, the address of the agent 1667 as learned from the IP source address of the corresponding Agent 1668 Advertisement MUST be used. In addition, when transmitting 1669 this Registration Request message, the mobile node MUST use a 1670 link-layer destination address copied from the link-layer source 1671 address of the Agent Advertisement message in which it learned 1672 this foreign agent's IP address. 1674 - When the mobile node is registering directly with its home 1675 agent and knows the (unicast) IP address of its home agent, the 1676 destination address MUST be set to this address. 1678 - If the mobile node is registering directly with its home 1679 agent, but does not know the IP address of its home agent, 1680 the mobile node may use dynamic home agent address resolution 1681 to automatically determine the IP address of its home agent 1682 (Section 3.6.1.2). In this case, the IP destination address is 1683 set to the subnet-directed broadcast address of the mobile node's 1684 home network. This address MUST NOT be used as the destination 1685 IP address if the mobile node is registering via a foreign agent, 1686 although it MAY be used as the Home Agent address in the body of 1687 the Registration Request when registering via a foreign agent. 1689 IP Time to Live: 1691 - The IP TTL field MUST be set to 1 if the IP destination address 1692 is set to the "All Mobility Agents" multicast address as 1693 described above. Otherwise a suitable value should be chosen in 1694 accordance with standard IP practice [19]. 1696 3.6.1.2. Registration Request Fields 1698 This section provides specific rules by which mobile nodes pick 1699 values for the fields within the fixed portion of a Registration 1700 Request. 1702 A mobile node MAY set the 'S' bit in order to request that the 1703 home agent maintain prior mobility binding(s). Otherwise, the 1704 home agent deletes any previous binding(s) and replaces them with 1705 the new binding specified in the Registration Request. Multiple 1706 simultaneous mobility bindings are likely to be useful when a mobile 1707 node using at least one wireless network interface moves within 1708 wireless transmission range of more than one foreign agent. IP 1709 explicitly allows duplication of datagrams. When the home agent 1710 allows simultaneous bindings, it will tunnel a separate copy of each 1711 arriving datagram to each care-of address, and the mobile node will 1712 receive multiple copies of datagrams destined to it. 1714 The mobile node SHOULD set the 'D' bit if it is registering with a 1715 co-located care-of address. Otherwise, the 'D' bit MUST NOT be set. 1717 A mobile node MAY set the 'B' bit to request its home agent to 1718 forward to it, a copy of broadcast datagrams received by its home 1719 agent from the home network. The method used by the home agent to 1720 forward broadcast datagrams depends on the type of care-of address 1721 registered by the mobile node, as determined by the 'D' bit in the 1722 mobile node's Registration Request: 1724 - If the 'D' bit is set, then the mobile node has indicated that it 1725 will decapsulate any datagrams tunneled to this care-of address 1726 itself (the mobile node is using a co-located care-of address). 1727 In this case, to forward such a received broadcast datagram to 1728 the mobile node, the home agent MUST tunnel it to this care-of 1729 address. The mobile node de-tunnels the received datagram in the 1730 same way as any other datagram tunneled directly to it. 1732 - If the 'D' bit is NOT set, then the mobile node has indicated 1733 that it is using a foreign agent care-of address, and that the 1734 foreign agent will thus decapsulate arriving datagrams before 1735 forwarding them to the mobile node. In this case, to forward 1736 such a received broadcast datagram to the mobile node, the home 1737 agent MUST first encapsulate the broadcast datagram in a unicast 1738 datagram addressed to the mobile node's home address, and then 1739 MUST tunnel this resulting datagram to the mobile node's care-of 1740 address. 1742 When decapsulated by the foreign agent, the inner datagram will 1743 thus be a unicast IP datagram addressed to the mobile node, 1744 identifying to the foreign agent the intended destination of the 1745 encapsulated broadcast datagram, and will be delivered to the 1746 mobile node in the same way as any tunneled datagram arriving 1747 for the mobile node. The foreign agent MUST NOT decapsulate the 1748 encapsulated broadcast datagram and MUST NOT use a local network 1749 broadcast to transmit it to the mobile node. The mobile node 1750 thus MUST decapsulate the encapsulated broadcast datagram itself, 1751 and thus MUST NOT set the 'B' bit in its Registration Request in 1752 this case unless it is capable of decapsulating datagrams. 1754 The mobile node MAY request alternative forms of encapsulation by 1755 setting the 'M' bit and/or the 'G' bit, but only if the mobile node 1756 is decapsulating its own datagrams (the mobile node is using a 1757 co-located care-of address) or if its foreign agent has indicated 1758 support for these forms of encapsulation by setting the corresponding 1759 bits in the Mobility Agent Advertisement Extension of an Agent 1760 Advertisement received by the mobile node. Otherwise, the mobile 1761 node MUST NOT set these bits. 1763 The Lifetime field is chosen as follows: 1765 - If the mobile node is registering with a foreign agent, the 1766 Lifetime SHOULD NOT exceed the value in the Registration Lifetime 1767 field of the Agent Advertisement message received from the 1768 foreign agent. When the method by which the care-of address is 1769 learned does not include a Lifetime, the default ICMP Router 1770 Advertisement Lifetime (1800 seconds) MAY be used. 1772 - The mobile node MAY ask a home agent to delete a particular 1773 mobility binding, by sending a Registration Request with the 1774 care-of address for this binding, with the Lifetime field set to 1775 zero (Section 3.8.2). 1777 - Similarly, a Lifetime of zero is used when the mobile node 1778 deregisters all care-of addresses, such as upon returning home. 1780 The Home Agent field MUST be set to the address of the mobile node's 1781 home agent, if the mobile node knows this address. Otherwise, the 1782 mobile node MAY use dynamic home agent address resolution to learn 1783 the address of its home agent. In this case, the mobile node MUST 1784 set the Home Agent field to the subnet-directed broadcast address 1785 of the mobile node's home network. Each home agent receiving such 1786 a Registration Request with a broadcast destination address MUST 1787 reject the mobile node's registration and SHOULD return a rejection 1788 Registration Reply indicating its unicast IP address for use by the 1789 mobile node in a future registration attempt. 1791 The Care-of Address field MUST be set to the value of the particular 1792 care-of address that the mobile node wishes to (de)register. In the 1793 special case in which a mobile node wishes to deregister all care-of 1794 addresses, it MUST set this field to its home address. 1796 The mobile node chooses the Identification field in accordance with 1797 the style of replay protection it uses with its home agent. This is 1798 part of the mobility security association the mobile node shares with 1799 its home agent. See Section 5.6 for the method by which the mobile 1800 node computes the Identification field. 1802 3.6.1.3. Extensions 1804 This section describes the ordering of any mandatory and any optional 1805 Extensions that a mobile node appends to a Registration Request. 1806 This following ordering MUST be followed: 1808 a) The IP header, followed by the UDP header, followed by the 1809 fixed-length portion of the Registration Request, followed by 1811 b) If present, any non-authentication Extensions expected to be 1812 used by the home agent (which may or may not also be used by 1813 the foreign agent), followed by 1815 c) The Mobile-Home Authentication Extension, followed by 1817 d) If present, any non-authentication Extensions used only by 1818 the foreign agent, followed by 1820 e) The Mobile-Foreign Authentication Extension, if present. 1822 Note that items (a) and (c) MUST appear in every Registration Request 1823 sent by the mobile node. Items (b), (d), and (e) are optional. 1824 However, item (e) MUST be included when the mobile node and the 1825 foreign agent share a mobility security association. 1827 3.6.2. Receiving Registration Replies 1829 Registration Replies will be received by the mobile node in response 1830 to its Registration Requests. Registration Replies generally fall 1831 into three categories: 1833 - the registration was accepted, 1834 - the registration was denied by the foreign agent, or 1835 - the registration was denied by the home agent. 1837 The remainder of this section describes the Registration Reply 1838 handling by a mobile node in each of these three categories. 1840 3.6.2.1. Validity Checks 1842 Registration Replies with an invalid, non-zero UDP checksum MUST be 1843 silently discarded. 1845 In addition, the low-order 32 bits of the Identification field in the 1846 Registration Reply MUST be compared to the low-order 32 bits of the 1847 Identification field in the most recent Registration Request sent to 1848 the replying agent. If they do not match, the Reply MUST be silently 1849 discarded. 1851 Also, the authentication in the Registration Reply MUST be checked. 1852 That is, the mobile node MUST check for the presence of a valid 1853 authentication Extension, acting in accordance with the Code field in 1854 the Reply. The rules are as follows: 1856 a) If the mobile node and the foreign agent share a 1857 mobility security association, exactly one Mobile-Foreign 1858 Authentication Extension MUST be present in the Registration 1859 Reply, and the mobile node MUST check the Authenticator 1860 value in the Extension. If no Mobile-Foreign Authentication 1861 Extension is found, or if more than one Mobile-Foreign 1862 Authentication Extension is found, or if the Authenticator is 1863 invalid, the mobile node MUST silently discard the Reply and 1864 SHOULD log the event as a security exception. 1866 b) If the Code field indicates that service is denied by 1867 the home agent, or if the Code field indicates that the 1868 registration was accepted by the home agent, exactly one 1869 Mobile-Home Authentication Extension MUST be present in 1870 the Registration Reply, and the mobile node MUST check the 1871 Authenticator value in the Extension. If no Mobile-Home 1872 Authentication Extension is found, or if more than one 1873 Mobile-Home Authentication Extension is found, or if the 1874 Authenticator is invalid, the mobile node MUST silently 1875 discard the Reply and SHOULD log the event as a security 1876 exception. 1878 If the Code field indicates an authentication failure, either at the 1879 foreign agent or the home agent, then it is quite possible that any 1880 authenticators in the Registration Reply will also be in error. This 1881 could happen, for example, if the shared secret between the mobile 1882 node and home agent was erroneously configured. The mobile node 1883 SHOULD log such errors as security exceptions. 1885 3.6.2.2. Registration Request Accepted 1887 If the Code field indicates that the request has been accepted, the 1888 mobile node SHOULD configure its routing table appropriately for its 1889 current point of attachment (Section 4.2.1). 1891 If the mobile node is returning to its home network and that 1892 network is one which implements ARP, the mobile node MUST follow the 1893 procedures described in Section 4.6 with regard to ARP, proxy ARP, 1894 and gratuitous ARP. 1896 If the mobile node has registered on a foreign network, it 1897 SHOULD re-register before the expiration of the Lifetime of its 1898 registration. As described in Section 3.6, for each pending 1899 Registration Request, the mobile node MUST maintain the remaining 1900 lifetime of this pending registration, as well as the original 1901 Lifetime from the Registration Request. When the mobile node 1902 receives a valid Registration Reply, the mobile node MUST decrease 1903 its view of the remaining lifetime of the registration by the amount 1904 by which the home agent decreased the originally requested Lifetime. 1905 This procedure is equivalent to the mobile node starting a timer for 1906 the granted Lifetime at the time it sent the Registration Request, 1907 even though the granted Lifetime is not known to the mobile node 1908 until the Registration Reply is received. Since the Registration 1909 Request is certainly sent before the home agent begins timing the 1910 registration Lifetime (also based on the granted Lifetime), this 1911 procedure ensures that the mobile node will re-register before the 1912 home agent expires and deletes the registration, in spite of possibly 1913 non-negligible transmission delays for the original Registration 1914 Request and Reply that started the timing of the Lifetime at the 1915 mobile node and its home agent. 1917 3.6.2.3. Registration Request Denied 1919 If the Code field indicates that service is being denied, the mobile 1920 node SHOULD log the error. In certain cases the mobile node may be 1921 able to "repair" the error. These include: 1923 Code 69: (Denied by foreign agent, Lifetime too long) 1925 In this case, the Lifetime field in the Registration Reply will 1926 contain the maximum Lifetime value which that foreign agent is 1927 willing to accept in any Registration Request. The mobile node 1928 MAY attempt to register with this same agent, using a Lifetime 1929 in the Registration Request that MUST be less than or equal to 1930 the value specified in the Reply. 1932 Code 133: (Denied by home agent, Identification mismatch) 1934 In this case, the Identification field in the Registration 1935 Reply will contain a value that allows the mobile node to 1936 synchronize with the home agent, based upon the style of replay 1937 protection in effect (Section 5.6). The mobile node MUST 1938 adjust the parameters it uses to compute the Identification 1939 field based upon the information in the Registration Reply, 1940 before issuing any future Registration Requests. 1942 Code 136: (Denied by home agent, Unknown home agent address) 1944 This code is returned by a home agent when the mobile node is 1945 performing dynamic home agent address resolution as described 1946 in Sections 3.6.1.1 and 3.6.1.2. In this case, the Home Agent 1947 field within the Reply will contain the unicast IP address of 1948 the home agent returning the Reply. The mobile node MAY then 1949 attempt to register with this home agent in future Registration 1950 Requests. In addition, the mobile node SHOULD adjust the 1951 parameters it uses to compute the Identification field based 1952 upon the corresponding field in the Registration Reply, before 1953 issuing any future Registration Requests. 1955 3.6.3. Registration Retransmission 1957 When no Registration Reply has been received within a reasonable 1958 time, another Registration Request MAY be transmitted. When 1959 timestamps are used, a new registration Identification is chosen for 1960 each retransmission; thus it counts as a new registration. When 1961 nonces are used, the unanswered Request is retransmitted unchanged; 1962 thus the retransmission does not count as a new registration 1963 (Section 5.6). In this way a retransmission will not require the 1964 home agent to resynchronize with the mobile node by issuing another 1965 nonce in the case in which the original Registration Request (rather 1966 than its Registration Reply) was lost by the network. 1968 The maximum time until a new Registration Request is sent SHOULD be 1969 no greater than the requested Lifetime of the Registration Request. 1970 The minimum value SHOULD be large enough to account for the size 1971 of the messages, twice the round trip time for transmission to the 1972 home agent, and at least an additional 100 milliseconds to allow for 1973 processing the messages before responding. The round trip time for 1974 transmission to the home agent will be at least as large as the time 1975 required to transmit the messages at the link speed of the mobile 1976 node's current point of attachment. Some circuits add another 200 1977 milliseconds of satellite delay in the total round trip time to the 1978 home agent. The minimum time between Registration Requests MUST NOT 1979 be less than 1 second. Each successive retransmission timeout period 1980 SHOULD be at least twice the previous period, as long as that is less 1981 than the maximum as specified above. 1983 3.7. Foreign Agent Considerations 1985 The foreign agent plays a mostly passive role in Mobile IP 1986 registration. It relays Registration Requests between mobile 1987 nodes and home agents, and, when it provides the care-of address, 1988 decapsulates datagrams for delivery to the mobile node. It SHOULD 1989 also send periodic Agent Advertisement messages to advertise its 1990 presence as described in Section 2.3, if not detectable by link-layer 1991 means. 1993 A foreign agent MUST NOT transmit a Registration Request except when 1994 relaying a Registration Request received from a mobile node, to 1995 the mobile node's home agent. A foreign agent MUST NOT transmit a 1996 Registration Reply except when relaying a Registration Reply received 1997 from a mobile node's home agent, or when replying to a Registration 1998 Request received from a mobile node in the case in which the foreign 1999 agent is denying service to the mobile node. In particular, a 2000 foreign agent MUST NOT generate a Registration Request or Reply 2001 because a mobile node's registration Lifetime has expired. A foreign 2002 agent also MUST NOT originate a Registration Request message that 2003 asks for deregistration of a mobile node; however, it MUST relay 2004 valid (de)Registration Requests originated by a mobile node. 2006 3.7.1. Configuration and Registration Tables 2008 Each foreign agent MUST be configured with a care-of address. In 2009 addition, for each pending or current registration, the foreign 2010 agent MUST maintain a visitor list entry containing the following 2011 information obtained from the mobile node's Registration Request: 2013 - the link-layer source address of the mobile node 2014 - the IP Source Address (the mobile node's Home Address) 2015 - the IP Destination Address (as specified in 3.6.2.3) 2016 - the UDP Source Port 2017 - the Home Agent address 2018 - the Identification field 2019 - the requested registration Lifetime, and 2020 - the remaining Lifetime of the pending or current registration. 2022 As with any node on the Internet, a foreign agent MAY also share 2023 mobility security associations with any other nodes. When relaying 2024 a Registration Request from a mobile node to its home agent, if the 2025 foreign agent shares a mobility security association with the home 2026 agent, it MUST add a Foreign-Home Authentication Extension to the 2027 Request and MUST check the required Foreign-Home Authentication 2028 Extension in the Registration Reply from the home agent (Sections 3.3 2029 and 3.4). Similarly, when receiving a Registration Request from 2030 a mobile node, if the foreign agent shares a mobility security 2031 association with the mobile node, it MUST check the required 2032 Mobile-Foreign Authentication Extension in the Request and MUST add a 2033 Mobile-Foreign Authentication Extension to the Registration Reply to 2034 the mobile node. 2036 3.7.2. Receiving Registration Requests 2038 If the foreign agent accepts a Registration Request from a mobile 2039 node, it then MUST relay the Request to the indicated home agent. 2040 Otherwise, if the foreign agent denies the Request, it MUST send a 2041 Registration Reply to the mobile node with an appropriate denial 2042 Code, except in cases where the foreign agent would be required to 2043 send out more than one such denial per second to the same mobile 2044 node. The following sections describe this behavior in more detail. 2046 If a foreign agent receives a Registration Request from a mobile 2047 node in its visitor list, the existing visitor list entry for the 2048 mobile node SHOULD NOT be deleted or modified until the foreign 2049 agent receives a valid Registration Reply from the home agent 2050 with a Code indicating success. The foreign agent MUST record 2051 the new pending Request separately from the existing visitor list 2052 entry for the mobile node. If the Registration Request requests 2053 deregistration, the existing visitor list entry for the mobile 2054 node SHOULD NOT be deleted until the foreign agent has received a 2055 successful Registration Reply. If the Registration Reply indicates 2056 that the Request (for registration or deregistration) was denied by 2057 the home agent, the existing visitor list entry for the mobile node 2058 MUST NOT be modified as a result of receiving the Registration Reply. 2060 3.7.2.1. Validity Checks 2062 Registration Requests with an invalid, non-zero UDP checksum MUST be 2063 silently discarded. 2065 Also, the authentication in the Registration Request MUST be checked. 2066 If the foreign agent and the mobile node share a mobility security 2067 association, exactly one Mobile-Foreign Authentication Extension MUST 2068 be present in the Registration Request, and the foreign agent MUST 2069 check the Authenticator value in the Extension. If no Mobile-Foreign 2070 Authentication Extension is found, or if more than one Mobile-Foreign 2071 Authentication Extension is found, or if the Authenticator is 2072 invalid, the foreign agent MUST silently discard the Request and 2073 SHOULD log the event as a security exception. The foreign agent also 2074 SHOULD send a Registration Reply to the mobile node with Code 67. 2076 3.7.2.2. Forwarding a Valid Request to the Home Agent 2078 If the foreign agent accepts the mobile node's Registration Request, 2079 it MUST relay the Request to the mobile node's home agent as 2080 specified in the Home Agent field of the Registration Request. 2081 The foreign agent MUST NOT modify any of the fields beginning 2082 with the fixed portion of the Registration Request up through and 2083 including the Mobile-Home Authentication Extension. Otherwise, an 2084 authentication failure is very likely to occur at the home agent. In 2085 addition, the foreign agent proceeds as follows: 2087 - It MUST process and remove any Extensions following the 2088 Mobile-Home Authentication Extension, 2089 - It MAY append any of its own non-authentication Extensions of 2090 relevance to the home agent, if applicable, and 2091 - It MUST append the Foreign-Home Authentication Extension, if the 2092 foreign agent shares a mobility security association with the home 2093 agent. 2095 Specific fields within the IP header and the UDP header of the 2096 relayed Registration Request MUST be set as follows: 2098 IP Source Address 2099 The foreign agent's address on the interface from which 2100 the message will be sent. 2102 IP Destination Address 2103 Copied from the Home Agent field within the Registration 2104 Request. 2106 UDP Source Port 2107 2109 UDP Destination Port 2110 434 2112 After forwarding a valid Registration Request to the home agent, the 2113 foreign agent MUST begin timing the remaining lifetime of the pending 2114 registration based on the Lifetime in the Registration Request. If 2115 this lifetime expires before receiving a valid Registration Reply, 2116 the foreign agent MUST delete its visitor list entry for this pending 2117 registration. 2119 3.7.2.3. Denying Invalid Requests 2121 If the foreign agent denies the mobile node's Registration Request 2122 for any reason, it SHOULD send the mobile node a Registration Reply 2123 with a suitable denial Code. In such a case, the Home Address, Home 2124 Agent, and Identification fields within the Registration Reply are 2125 copied from the corresponding fields of the Registration Request. 2127 If the Reserved field is nonzero, the foreign agent MUST deny the 2128 Request and SHOULD return a Registration Reply with status code 70 2129 to the mobile node. If the Request is being denied because the 2130 requested Lifetime is too long, the foreign agent sets the Lifetime 2131 in the Reply to the maximum Lifetime value it is willing to accept in 2132 any Registration Request, and sets the Code field to 69. Otherwise, 2133 the Lifetime SHOULD be copied from the Lifetime field in the Request. 2135 Specific fields within the IP header and the UDP header of the 2136 Registration Reply MUST be set as follows: 2138 IP Source Address 2139 Copied from the IP Destination Address of Registration 2140 Request, unless the "All Agents Multicast" address was 2141 used. In this case, the foreign agent's address (on the 2142 interface from which the message will be sent) MUST be 2143 used. 2145 IP Destination Address 2146 Copied from the IP Source Address of the Registration 2147 Request. 2149 UDP Source Port 2150 434 2152 UDP Destination Port 2153 Copied from the UDP Source Port of the Registration 2154 Request. 2156 3.7.3. Receiving Registration Replies 2158 The foreign agent updates its visitor list when it receives a 2159 valid Registration Reply from a home agent. It then relays the 2160 Registration Reply to the mobile node. The following sections 2161 describe this behavior in more detail. 2163 If upon relaying a Registration Request to a home agent, the foreign 2164 agent receives an ICMP error message instead of a Registration Reply, 2165 then the foreign agent SHOULD send to the mobile node a Registration 2166 Reply with an appropriate "Home Agent Unreachable" failure Code 2167 (within the range 80-95, inclusive). See Section 3.7.2.3 for details 2168 on building the Registration Reply. 2170 3.7.3.1. Validity Checks 2172 Registration Replies with an invalid, non-zero UDP checksum MUST be 2173 silently discarded. 2175 When a foreign agent receives a Registration Reply message, it MUST 2176 search its visitor list for a pending Registration Request with the 2177 same mobile node home address as indicated in the Reply. If no 2178 pending Request is found, the foreign agent MUST silently discard the 2179 Reply. The foreign agent MUST also silently discard the Reply if the 2180 low-order 32 bits of the Identification field in the Reply do not 2181 match those in the Request. 2183 Also, the authentication in the Registration Reply MUST be checked. 2184 If the foreign agent and the home agent share a mobility security 2185 association, exactly one Foreign-Home Authentication Extension MUST 2186 be present in the Registration Reply, and the foreign agent MUST 2187 check the Authenticator value in the Extension. If no Foreign-Home 2188 Authentication Extension is found, or if more than one Foreign-Home 2189 Authentication Extension is found, or if the Authenticator is 2190 invalid, the foreign agent MUST silently discard the Reply and SHOULD 2191 log the event as a security exception. The foreign agent also MUST 2192 reject the mobile node's registration and SHOULD send a Registration 2193 Reply to the mobile node with Code 68. 2195 3.7.3.2. Forwarding Replies to the Mobile Node 2197 A Registration Reply which satisfies the validity checks of 2198 Section 3.8.2.1 is relayed to the mobile node. The foreign agent 2199 MUST also update its visitor list entry for the mobile node to 2200 reflect the results of the Registration Request, as indicated by the 2201 Code field in the Reply. If the Code indicates that the mobile node 2202 has accepted the registration and the Lifetime field is nonzero, the 2203 foreign agent MUST set the Lifetime in the visitor list entry to the 2204 value specified in the Lifetime field of the Registration Reply. 2205 If, instead, the Code indicates that the Lifetime field is zero, 2206 the foreign agent MUST delete its visitor list entry for the mobile 2207 node. Finally, if the Code indicates that the registration was 2208 denied by the home agent, the foreign agent MUST delete its pending 2209 registration list entry, but not its visitor list entry, for the 2210 mobile node. 2212 The foreign agent MUST NOT modify any of the fields beginning 2213 with the fixed portion of the Registration Reply up through and 2214 including the Mobile-Home Authentication Extension. Otherwise, 2215 an authentication failure is very likely to occur at the mobile 2216 node. In addition, the foreign agent SHOULD perform the following 2217 additional procedures: 2219 - It MUST process and remove any Extensions following the 2220 Mobile-Home Authentication Extension, 2221 - It MAY append its own non-authentication Extensions of relevance 2222 to the mobile node, if applicable, and 2223 - It MUST append the Mobile-Foreign Authentication Extension, if 2224 the foreign agent shares a mobility security association with the 2225 mobile node. 2227 Specific fields within the IP header and the UDP header of the 2228 relayed Registration Reply are set according to the same rules 2229 specified in Section 3.7.2.3. 2231 After forwarding a valid Registration Reply to the mobile node, 2232 the foreign agent MUST update its visitor list entry for this 2233 registration as follows. If the Registration Reply indicates that 2234 the registration was accepted by the home agent, the foreign agent 2235 resets its timer of the lifetime of the registration to the Lifetime 2236 granted in the Registration Reply; unlike the mobile node's timing 2237 of the registration lifetime as described in Section 3.6.2.2, the 2238 foreign agent considers this lifetime to begin when it forwards the 2239 Registration Reply message, ensuring that the foreign agent will not 2240 expire the registration before the mobile node does. On the other 2241 hand, if the Registration Reply indicates that the registration was 2242 rejected by the home agent, the foreign agent deletes its visitor 2243 list entry for this attempted registration. 2245 3.8. Home Agent Considerations 2247 Home agents play a reactive role in the registration process. The 2248 home agent receives Registration Requests from the mobile node 2249 (perhaps relayed by a foreign agent), updates its record of the 2250 mobility bindings for this mobile node, and issues a suitable 2251 Registration Reply in response to each. 2253 A home agent MUST NOT transmit a Registration Reply except when 2254 replying to a Registration Request received from a mobile node. In 2255 particular, the home agent MUST NOT generate a Registration Reply to 2256 indicate that the Lifetime has expired. 2258 3.8.1. Configuration and Registration Tables 2260 Each home agent MUST be configured with an IP address and with the 2261 prefix size for the home network. The home agent MUST be configured 2262 with the home address and mobility security association of each 2263 authorized mobile node that it is serving as a home agent. When 2264 the home agent accepts a valid Registration Request from a mobile 2265 node that it serves as a home agent, the home agent MUST create or 2266 modify the entry for this mobile node in its mobility binding list 2267 containing: 2269 - the mobile node's care-of address 2270 - the Identification field from the Registration Reply 2271 - the remaining Lifetime of the registration 2273 The home agent MAY also maintain mobility security associations 2274 with various foreign agents. When receiving a Registration Request 2275 from a foreign agent, if the home agent shares a mobility security 2276 association with the foreign agent, the home agent MUST check the 2277 Authenticator in the required Foreign-Home Authentication Extension 2278 in the message, based on this mobility security association. 2279 Similarly, when sending a Registration Reply to a foreign agent, 2280 if the home agent shares a mobility security association with 2281 the foreign agent, the home agent MUST include a Foreign-Home 2282 Authentication Extension in the message, based on this mobility 2283 security association. 2285 3.8.2. Receiving Registration Requests 2287 If the home agent accepts an incoming Registration Request, it MUST 2288 update its record of the the mobile node's mobility binding(s) and 2289 SHOULD send a Registration Reply with a suitable Code. Otherwise 2290 (the home agent denies the Request), it SHOULD send a Registration 2291 Reply with an appropriate Code specifying the reason the Request 2292 was denied. The following sections describe this behavior in more 2293 detail. 2295 3.8.2.1. Validity Checks 2297 Registration Requests with an invalid, non-zero UDP checksum MUST be 2298 silently discarded by the home agent. 2300 The authentication in the Registration Request MUST be checked. This 2301 involves the following operations: 2303 a) The home agent MUST check for the presence of a valid 2304 Mobile-Home Authentication Extension, and perform the 2305 indicated authentication. Exactly one Mobile-Home 2306 Authentication Extension MUST be present in the Registration 2307 Request, and the home agent MUST check the Authenticator 2308 value in the Extension. If no Mobile-Home Authentication 2309 Extension is found, or if more than one Mobile-Home 2310 Authentication Extension is found, or if the Authenticator 2311 is invalid, the home agent MUST reject the mobile node's 2312 registration and SHOULD send a Registration Reply to the 2313 mobile node with Code 131. The home agent MUST then discard 2314 the Request and SHOULD log the error as a security exception. 2316 b) The home agent MUST check that the registration 2317 Identification field is correct using the context selected by 2318 the SPI within the Mobile-Home Authentication Extension. See 2319 Section 5.6 for a description of how this is performed. If 2320 incorrect, the home agent MUST reject the Request and SHOULD 2321 send a Registration Reply to the mobile node with Code 133, 2322 including an Identification field computed in accordance with 2323 the rules specified in Section 5.6. The home agent MUST do 2324 no further processing with such a Request, though it SHOULD 2325 log the error as a security exception. 2327 c) If the home agent shares a mobility security association with 2328 the foreign agent, the home agent MUST check for the presence 2329 of a valid Foreign-Home Authentication Extension. Exactly 2330 one Foreign-Home Authentication Extension MUST be present in 2331 the Registration Request in this case, and the home agent 2332 MUST check the Authenticator value in the Extension. If no 2333 Foreign-Home Authentication Extension is found, or if more 2334 than one Foreign-Home Authentication Extension is found, or 2335 if the Authenticator is invalid, the home agent MUST reject 2336 the mobile node's registration and SHOULD send a Registration 2337 Reply to the mobile node with Code 132. The home agent 2338 MUST then discard the Request and SHOULD log the error as a 2339 security exception. 2341 In addition to checking the authentication in the Registration 2342 Request, home agents MUST deny Registration Requests that are sent to 2343 the subnet-directed broadcast address of the home network (as opposed 2344 to being unicast to the home agent). The home agent MUST discard 2345 the Request and SHOULD returning a Registration Reply with a Code 2346 of 136. In this case, the Registration Reply will contain the home 2347 agent's unicast address, so that the mobile node can re-issue the 2348 Registration Request with the correct home agent address. 2350 3.8.2.2. Accepting a Valid Request 2352 If the Registration Request satisfies the validity checks in 2353 Section 3.8.2.1, and the home agent is able to accommodate the 2354 Request, the home agent MUST update its mobility binding list for 2355 the requesting mobile node and MUST return a Registration Reply to 2356 the mobile node. In this case, the Reply Code will be either 0 if 2357 the home agent supports simultaneous mobility bindings, or 1 if it 2358 does not. See Section 3.8.3 for details on building the Registration 2359 Reply message. 2361 The home agent updates its record of the mobile node's mobility 2362 bindings as follows, based on the fields in the Registration Request: 2364 - If the Lifetime is zero and the Care-of Address equals the mobile 2365 node's home address, the home agent deletes all of the entries in 2366 the mobility binding list for the requesting mobile node. This 2367 is how a mobile node requests that its home agent cease providing 2368 mobility services. 2370 - If the Lifetime is zero and the Care-of Address does not equal 2371 the mobile node's home address, the home agent deletes only the 2372 entry containing the specified Care-of Address from the mobility 2373 binding list for the requesting mobile node. Any other active 2374 entries containing other care-of addresses will remain active. 2376 - If the Lifetime is nonzero, the home agent adds an entry 2377 containing the requested Care-of Address to the mobility binding 2378 list for the mobile node. If the 'S' bit is set and the home 2379 agent supports simultaneous mobility bindings, the previous 2380 mobility binding entries are retained. Otherwise, the home agent 2381 removes all previous entries in the mobility binding list for the 2382 mobile node. 2384 In all cases, the home agent MUST send a Registration Reply to 2385 the source of the Registration Request, which might indeed be a 2386 different foreign agent than that whose care-of address is being 2387 (de)registered. If the home agent shares a mobility security 2388 association with the foreign agent whose care-of address is being 2389 deregistered, and that foreign agent is different from the one which 2390 relayed the Registration Request, the home agent MAY additionally 2391 send a Registration Reply to the foreign agent whose care-of address 2392 is being deregistered. The home agent MUST NOT send such a Reply if 2393 it does not share a mobility security association with the foreign 2394 agent. If no Reply is sent, the foreign agent's visitor list will 2395 expire naturally when the original Lifetime expires. 2397 The home agent MUST NOT increase the Lifetime above that specified 2398 by the mobile node in the Registration Request. However, it is not 2399 an error for the mobile node to request a Lifetime longer than the 2400 home agent is willing to accept. In this case, the home agent simply 2401 reduces the Lifetime to a permissible value and returns this value in 2402 the Registration Reply. The Lifetime value in the Registration Reply 2403 informs the mobile node of the granted lifetime of the registration, 2404 indicating when it SHOULD re-register in order to maintain continued 2405 service. After the expiration of this registration lifetime, 2406 the home agent MUST delete its entry for this registration in its 2407 mobility binding list. 2409 If the Registration Request duplicates an accepted current 2410 Registration Request, the new Lifetime MUST NOT extend beyond the 2411 Lifetime originally granted. A Registration Request is a duplicate 2412 if the home address, care-of address, and Identification fields all 2413 equal those of an accepted current registration. 2415 In addition, if the home network implements ARP [16], and the 2416 Registration Request asks the home agent to create a mobility binding 2417 for a mobile node which previously had no binding (the mobile node 2418 was previously assumed to be at home), then the home agent MUST 2419 follow the procedures described in Section 4.6 with regard to ARP, 2420 proxy ARP, and gratuitous ARP. If the mobile node already had a 2421 previous mobility binding, the home agent MUST continue to follow the 2422 rules for proxy ARP described in Section 4.6. 2424 3.8.2.3. Denying an Invalid Request 2426 If the Registration Reply does not satisfy all of the validity checks 2427 in Section 3.8.2.1, or the home agent is unable to accommodate the 2428 Request, the home agent SHOULD return a Registration Reply to the 2429 mobile node with a Code that indicates the reason for the error. If 2430 a foreign agent was involved in relaying the Request, this allows the 2431 foreign agent to delete its pending visitor list entry. Also, this 2432 informs the mobile node of the reason for the error such that it may 2433 attempt to fix the error and issue another Request. 2435 This section lists a number of reasons the home agent might reject a 2436 Request, and provides the Code value it should use in each instance. 2437 See Section 3.8.3 for additional details on building the Registration 2438 Reply message. 2440 Many reasons for rejecting a registration are administrative 2441 in nature. For example, a home agent can limit the number of 2442 simultaneous registrations for a mobile node, by rejecting any 2443 registrations that would cause its limit to be exceeded, and 2444 returning a Registration Reply with error code 135. Similarly, a 2445 home agent may refuse to grant service to mobile nodes which have 2446 entered unauthorized service areas by returning a Registration Reply 2447 with a Code of 129. 2449 If the Reserved field is nonzero, it MUST deny the Request with a 2450 Code of 134. 2452 3.8.3. Sending Registration Replies 2454 If the home agent accepts a Registration Request, it then MUST update 2455 its record of the mobile node's mobility binding(s) and SHOULD send a 2456 Registration Reply with a suitable Code. Otherwise (the home agent 2457 has denied the Request), it SHOULD send a Registration Reply with an 2458 appropriate Code specifying the reason the Request was denied. The 2459 following sections provide additional detail for the values the home 2460 agent MUST supply in the fields of Registration Reply messages. 2462 3.8.3.1. IP/UDP Fields 2464 This section provides the specific rules by which mobile nodes pick 2465 values for the IP and UDP header fields of a Registration Reply. 2467 IP Source Address 2468 Copied from the IP Destination Address of Registration 2469 Request, unless a multicast or broadcast address was 2470 used. If the IP Destination Address of the Registration 2471 Request was a broadcast or multicast address, the IP 2472 Source Address of the Registration Reply MUST be set to 2473 the home agent's (unicast) IP address. 2475 IP Destination Address 2476 Copied from the IP Source Address of the Registration 2477 Request. 2479 UDP Source Port 2480 Copied from the UDP Destination Port of the Registration 2481 Request. 2483 UDP Destination Port 2484 Copied from the UDP Source Port of the Registration 2485 Request. 2487 When sending a Registration Reply in response to a Registration 2488 Request that requested deregistration of the mobile node (the 2489 Lifetime is zero and the Care-of Address equals the mobile node's 2490 home address) and in which the IP Source Address was also set to 2491 the mobile node's home address (this is the normal method used by a 2492 mobile node to deregister when it returns to its home network), the 2493 IP Destination Address in the Registration Reply will be set to the 2494 mobile node's home address, as copied from the IP Source Address of 2495 the Request. 2497 In this case, when transmitting the Registration Reply, the home 2498 agent MUST transmit the Reply directly onto the home network as if 2499 the mobile node were at home, bypassing any mobility binding list 2500 entry that may still exist at the home agent for the destination 2501 mobile node. In particular, for a mobile node returning home 2502 after being registered with a care-of address, if the mobile node's 2503 new Registration Request is not accepted by the home agent, the 2504 mobility binding list entry for the mobile node will still indicate 2505 that datagrams addressed to the mobile node should be tunneled to 2506 the mobile node's registered care-of address; when sending the 2507 Registration Reply indicating the rejection of this Request, this 2508 existing binding list entry MUST be ignored, and the home agent MUST 2509 transmit this Reply as if the mobile node were at home. 2511 3.8.3.2. Registration Reply Fields 2513 This section provides specific rules by which home agents pick values 2514 for the fields within the fixed portion of a Registration Reply. 2516 The Code field of the Registration Reply is chosen in accordance with 2517 the rules specified in the previous sections. When replying to an 2518 accepted registration, a home agent SHOULD respond with Code 1 if it 2519 does not support simultaneous registrations. 2521 The Lifetime field MUST be copied from the corresponding field in 2522 the Registration Request, unless the requested value is greater than 2523 the maximum length of time the home agent is willing to provide the 2524 requested service. In such a case, the Lifetime MUST be set to the 2525 length of time that service will actually be provided by the home 2526 agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed 2527 by the home agent (for this mobile node and care-of address). 2529 The Home Address field MUST be copied from the corresponding field in 2530 the Registration Request. 2532 If the Home Agent field in the Registration Request contains a 2533 unicast address of this home agent, then that field MUST be copied 2534 into the Home Agent field of the Registration Reply. Otherwise, the 2535 home agent MUST set the Home Agent field in the Registration Reply to 2536 its unicast address. In this latter case, the home agent MUST reject 2537 the registration with a suitable code (e.g., Code 136) to prevent the 2538 mobile node from possibly being simultaneously registered with two or 2539 more home agents. 2541 3.8.3.3. Extensions 2543 This section describes the ordering of any required and any optional 2544 Mobile IP Extensions that a home agent appends to a Registration 2545 Reply. The following ordering MUST be followed: 2547 a) The IP header, followed by the UDP header, followed by the 2548 fixed-length portion of the Registration Reply, 2550 b) If present, any non-authentication Extensions used by the 2551 mobile node (which may or may not also be used by the foreign 2552 agent), 2554 c) The Mobile-Home Authentication Extension, 2556 d) If present, any non-authentication Extensions used only by 2557 the foreign agent, and 2559 e) The Foreign-Home Authentication Extension, if present. 2561 Note that items (a) and (c) MUST appear in every Registration Reply 2562 sent by the home agent. Items (b), (d), and (e) are optional. 2564 However, item (e) MUST be included when the home agent and the 2565 foreign agent share a mobility security association. 2567 4. Routing Considerations 2569 This section describes how mobile nodes, home agents, and (possibly) 2570 foreign agents cooperate to route datagrams to/from mobile nodes that 2571 are connected to a foreign network. The mobile node informs its 2572 home agent of its current location using the registration procedure 2573 described in Section 3. See the protocol overview in Section 1.7 for 2574 the relative locations of the mobile node's home address with respect 2575 to its home agent, and the mobile node itself with respect to any 2576 foreign agent with which it might attempt to register. 2578 4.1. Encapsulation Types 2580 Home agents and foreign agents MUST support tunneling datagrams 2581 using IP in IP encapsulation [14]. Any mobile node that uses a 2582 co-located care-of address MUST support receiving datagrams tunneled 2583 using IP in IP encapsulation. Minimal encapsulation [15] and GRE 2584 encapsulation [8] are alternate encapsulation methods which MAY 2585 optionally be supported by mobility agents and mobile nodes. The use 2586 of these alternative forms of encapsulation, when requested by the 2587 mobile node, is otherwise at the discretion of the home agent. 2589 4.2. Unicast Datagram Routing 2591 4.2.1. Mobile Node Considerations 2593 When connected to its home network, a mobile node operates without 2594 the support of mobility services. That is, it operates in the same 2595 way as any other (fixed) host or router. The method by which a 2596 mobile node selects a default router when connected to its home 2597 network, or when away from home and using a co-located care-of 2598 address, is outside the scope of this document. ICMP Router 2599 Advertisement [4] is one such method. 2601 When registered on a foreign network, the mobile node chooses a 2602 default router by the following rules: 2604 - If the mobile node is registered using a foreign agent care-of 2605 address, then the mobile node MUST choose its default router 2606 from among the Router Addresses advertised in the ICMP Router 2607 Advertisement portion of that Agent Advertisement message. The 2608 mobile node MAY also consider the IP source address of the Agent 2609 Advertisement as another possible choice for the IP address of a 2610 default router, along with the (possibly empty) list of Router 2611 Addresses from the ICMP Router Advertisement portion of the 2612 message. In such cases, the IP source address MUST be considered 2613 to be the worst choice (lowest preference) for a default router. 2615 - If the mobile node is registered directly with its home agent 2616 using a co-located care-of address, then the mobile node SHOULD 2617 choose its default router from among those advertised in any 2618 ICMP Router Advertisement message that it receives for which 2619 its externally obtained care-of address and the Router Address 2620 match under the network prefix. If the mobile node's externally 2621 obtained care-of address matches the IP source address of the 2622 Agent Advertisement under the network prefix, the mobile node 2623 MAY also consider that IP source address as another possible 2624 choice for the IP address of a default router, along with the 2625 (possibly empty) list of Router Addresses from the ICMP Router 2626 Advertisement portion of the message. If so, the IP source 2627 address MUST be considered to be the worst choice (lowest 2628 preference) for a default router. The network prefix MAY 2629 be obtained from the Prefix-Lengths Extension in the Router 2630 Advertisement, if present. The prefix MAY also be obtained 2631 through other mechanisms beyond the scope of this document. 2633 Beyond these rules, the actual selection of the default router is 2634 made by the selection method specified for ICMP Router Discovery [4], 2635 among the Router Addresses specified above. In any case, a mobile 2636 node registered via a foreign agent MAY choose its foreign agent as a 2637 default router. 2639 Note that Van Jacobson header compression [10] will not function 2640 properly unless all TCP IP datagrams to and from the mobile node 2641 pass, respectively, through the same first and last-hop router. 2642 The mobile node, therefore, MUST select its foreign agent as its 2643 default router if it performs Van Jacobson header compression with 2644 its foreign agent. 2646 4.2.2. Foreign Agent Considerations 2648 Upon receipt of an encapsulated datagram sent to its advertised 2649 care-of address, a foreign agent MUST compare the inner destination 2650 address to those entries in its visitor list. When the destination 2651 does not match the address of any mobile node currently in the 2652 visitor list, the foreign agent MUST NOT forward the datagram without 2653 modifications to the original IP header, because otherwise a routing 2654 loop is likely to result. The datagram SHOULD be silently discarded. 2655 ICMP Destination Unreachable MUST NOT be sent when a foreign agent 2656 is unable to forward an incoming tunneled datagram. Otherwise, the 2657 foreign agent forwards the decapsulated datagram to the mobile node. 2659 The foreign agent MUST NOT advertise to other routers in its routing 2660 domain, nor to any other mobile node, the presence of a mobile router 2661 (Section 4.5). 2663 The foreign agent MUST route datagrams it receives from registered 2664 mobile nodes. At a minimum, this means that the foreign agent 2665 must verify the IP Header Checksum, decrement the IP Time To Live, 2666 recompute the IP Header Checksum, and forward such datagrams to 2667 a default router. In addition, the foreign agent SHOULD send an 2668 appropriate ICMP Redirect message to the mobile node. 2670 4.2.3. Home Agent Considerations 2672 The home agent MUST be able to intercept any datagrams on the 2673 home network addressed to the mobile node while the mobile node is 2674 registered away from home. Proxy and gratuitous ARP MAY be used in 2675 enabling this interception, as specified in Section 4.6. 2677 The home agent must examine the IP Destination Address of all 2678 arriving datagrams to see if it is equal to the home address of any 2679 of its mobile nodes registered away from home. If so, the home 2680 agent tunnels the datagram to the mobile node's currently registered 2681 care-of address or addresses. If the home agent supports the 2682 optional capability of multiple simultaneous mobility bindings, it 2683 tunnels a copy to each care-of address in the mobile node's mobility 2684 binding list. If the mobile node has no current mobility bindings, 2685 the home agent MUST NOT attempt to intercept datagrams destined for 2686 the mobile node, and thus will not in general receive such datagrams. 2687 However, if the home agent is also a router handling common IP 2688 traffic, it is possible that it will receive such datagrams for 2689 forwarding onto the home network. In this case, the home agent MUST 2690 assume the mobile node is at home and simply forward the datagram 2691 directly onto the home network. 2693 See Section 4.1 regarding methods of encapsulation that may be used 2694 for tunneling. Nodes implementing tunneling SHOULD also implement 2695 the "tunnel soft state" mechanism [14], which allows ICMP error 2696 messages returned from the tunnel to correctly be reflected back to 2697 the original senders of the tunneled datagrams. 2699 Home agents SHOULD be able to decapsulate and further deliver packets 2700 addressed to themselves, sent by a mobile node for the purpose of 2701 maintaining location privacy, as described in Section 5.5. 2703 If the Lifetime for a given mobility binding expires before the 2704 home agent has received another valid Registration Request for that 2705 mobile node, then that binding is deleted from the mobility binding 2706 list. The home agent MUST NOT send any Registration Reply message 2707 simply because the mobile node's binding has expired. The entry in 2708 the visitor list of the mobile node's current foreign agent will 2709 expire naturally, probably at the same time as the binding expired 2710 at the home agent. When a mobility binding's lifetime expires, the 2711 home agent MUST delete the binding, but it MUST retain any other 2712 (non-expired) simultaneous mobility bindings that it holds for the 2713 mobile node. 2715 When a home agent receives a datagram, intercepted for one of its 2716 mobile nodes registered away from home, the home agent MUST examine 2717 the datagram to check if it is already encapsulated. If so, special 2718 rules apply in the forwarding of that datagram to the mobile node: 2720 - If the inner (encapsulated) Destination Address is the same 2721 as the outer Destination Address (the mobile node), then the 2722 home agent MUST also examine the outer Source Address of the 2723 encapsulated datagram (the source address of the tunnel). If 2724 this outer Source Address is the same as the mobile node's 2725 current care-of address, the home agent MUST silently discard 2726 that datagram in order to prevent a likely routing loop. If, 2727 instead, the outer Source Address is NOT the same as the mobile 2728 node's current care-of address, then the home agent SHOULD 2729 forward the datagram to the mobile node. In order to forward 2730 the datagram in this case, the home agent MAY simply alter the 2731 outer Destination Address to the care-of address, rather than 2732 re-encapsulating the datagram. 2734 - Otherwise (the inner Destination Address is NOT the same as the 2735 outer Destination Address), the home agent SHOULD encapsulate 2736 the datagram again (recursive encapsulation), with the new outer 2737 Destination Address set equal to the mobile node's care-of 2738 address. That is, the home agent forwards the entire datagram 2739 to the mobile node in the same way as any other datagram 2740 (encapsulated already or not). 2742 4.3. Broadcast Datagrams 2744 When a home agent receives a broadcast datagram, it MUST NOT forward 2745 the datagram to any mobile nodes in its mobility binding list other 2746 than those that have requested forwarding of broadcast datagrams. A 2747 mobile node MAY request forwarding of broadcast datagrams by setting 2748 the 'B' bit in its Registration Request message (Section 3.3). For 2749 each such registered mobile node, the home agent SHOULD forward 2750 received broadcast datagrams to the mobile node, although it is 2751 a matter of configuration at the home agent as to which specific 2752 categories of broadcast datagrams will be forwarded to such mobile 2753 nodes. 2755 If the 'D' bit was set in the mobile node's Registration Request 2756 message, indicating that the mobile node is using a co-located 2757 care-of address, the home agent simply tunnels appropriate broadcast 2758 IP datagrams to the mobile node's care-of address. Otherwise (the 2759 'D' bit was NOT set), the home agent first encapsulates the broadcast 2760 datagram in a unicast datagram addressed to the mobile node's home 2761 address, and then tunnels this encapsulated datagram to the foreign 2762 agent. This extra level of encapsulation is required so that the 2763 foreign agent can determine which mobile node should receive the 2764 datagram after it is decapsulated. When received by the foreign 2765 agent, the unicast encapsulated datagram is detunneled and delivered 2766 to the mobile node in the same way as any other datagram. In either 2767 case, the mobile node must decapsulate the datagram it receives in 2768 order to recover the original broadcast datagram. 2770 4.4. Multicast Datagram Routing 2772 As mentioned previously, a mobile node that is connected to its 2773 home network functions in the same way as any other (fixed) host 2774 or router. Thus, when it is at home, a mobile node functions 2775 identically to other multicast senders and receivers. This section 2776 therefore describes the behavior of a mobile node that is visiting a 2777 foreign network. 2779 In order receive multicasts, a mobile node MUST join the multicast 2780 group in one of two ways. First, a mobile node MAY join the group 2781 via a (local) multicast router on the visited subnet. This option 2782 assumes that there is a multicast router present on the visited 2783 subnet. If the mobile node is using a co-located care-of address, 2784 it SHOULD use this address as the source IP address of its IGMP [5] 2785 messages. Otherwise, it MUST use its home address. 2787 Alternatively, a mobile node which wishes to receive multicasts 2788 MAY join groups via a bi-directional tunnel to its home agent, 2789 assuming that its home agent is a multicast router. The mobile node 2790 tunnels IGMP messages to its home agent and the home agent forwards 2791 multicast datagrams down the tunnel to the mobile node. The rules 2792 for multicast datagram delivery to mobile nodes in this case are 2793 identical to those for broadcast datagrams (Section 4.3). Namely, if 2794 the mobile node is using a co-located care-of address (the 'D' bit 2795 was set in the mobile node's Registration Request), then the home 2796 agent SHOULD tunnel the datagram to this care-of address; otherwise, 2797 the home agent MUST first encapsulate the datagram in a unicast 2798 datagram addressed to the mobile node's home address and then MUST 2799 tunnel the resulting datagram (recursive tunneling) to the mobile 2800 node's care-of address. 2802 A mobile node that wishes to send datagrams to a multicast group 2803 also has two options: (1) send directly on the visited network; or 2804 (2) send via a tunnel to its home agent. Because multicast routing 2805 in general depends upon the IP source address, a mobile node which 2806 sends multicast datagrams directly on the visited network MUST use a 2807 co-located care-of address as the IP source address. Similarly, a 2808 mobile node which tunnels a multicast datagram to its home agent MUST 2809 use its home address as the IP source address of both the (inner) 2810 multicast datagram and the (outer) encapsulating datagram. This 2811 second option assumes that the home agent is a multicast router. 2813 4.5. Mobile Routers 2815 A mobile node can be a router, which is responsible for the mobility 2816 of one or more entire networks moving together, perhaps on an 2817 airplane, a ship, a train, an automobile, a bicycle, or a kayak. 2818 The nodes connected to a network served by the mobile router may 2819 themselves be fixed nodes or mobile nodes or routers. In this 2820 document, such networks are called "mobile networks". 2822 A mobile router MAY act as a foreign agent and provide a foreign 2823 agent care-of address to mobile nodes connected to the mobile 2824 network. Typical routing to a mobile node via a mobile router in 2825 this case is illustrated by the following example: 2827 a) A laptop computer is disconnected from its home network and 2828 later attached to a network port in the seat back of an 2829 aircraft. The laptop computer uses Mobile IP to register on 2830 this foreign network, using a foreign agent care-of address 2831 discovered through an Agent Advertisement from the aircraft's 2832 foreign agent. 2834 b) The aircraft network is itself mobile. Suppose the node 2835 serving as the foreign agent on the aircraft also serves as 2836 the default router that connects the aircraft network to the 2837 rest of the Internet. When the aircraft is at home, this 2838 router is attached to some fixed network at the airline's 2839 headquarters, which is the router's home network. While 2840 the aircraft is in flight, this router registers from time 2841 to time over its radio link with a series of foreign agents 2842 below it on the ground. This router's home agent is a node 2843 on the fixed network at the airline's headquarters. 2845 c) Some correspondent node sends a datagram to the laptop 2846 computer, addressing the datagram to the laptop's home 2847 address. This datagram is initially routed to the laptop's 2848 home network. 2850 d) The laptop's home agent intercepts the datagram on the home 2851 network and tunnels it to the laptop's care-of address, which 2852 in this example is an address of the node serving as router 2853 and foreign agent on the aircraft. Normal IP routing will 2854 route the datagram to the fixed network at the airline's 2855 headquarters. 2857 e) The aircraft router and foreign agent's home agent there 2858 intercepts the datagram and tunnels it to its current care-of 2859 address, which in this example is some foreign agent on the 2860 ground below the aircraft. The original datagram from the 2861 correspondent node has now been encapsulated twice: once 2862 by the laptop's home agent and again by the aircraft's home 2863 agent. 2865 f) The foreign agent on the ground decapsulates the datagram, 2866 yielding a datagram still encapsulated by the laptop's home 2867 agent, with a destination address of the laptop's care-of 2868 address. The ground foreign agent sends the resulting 2869 datagram over its radio link to the aircraft. 2871 g) The foreign agent on the aircraft decapsulates the datagram, 2872 yielding the original datagram from the correspondent node, 2873 with a destination address of the laptop's home address. 2874 The aircraft foreign agent delivers the datagram over the 2875 aircraft network to the laptop's link-layer address. 2877 This example illustrated the case in which a mobile node is attached 2878 to a mobile network. That is, the mobile node is mobile with respect 2879 to the network, which itself is also mobile (here with respect to 2880 the ground). If, instead, the node is fixed with respect to the 2881 mobile network (the mobile network is the fixed node's home network), 2882 then either of two methods may be used to cause datagrams from 2883 correspondent nodes to be routed to the fixed node. 2885 A home agent MAY be configured to have a permanent registration for 2886 the fixed node, that indicates the mobile router's address as the 2887 fixed host's care-of address. The mobile router's home agent will 2888 usually be used for this purpose. The home agent is then responsible 2889 for advertising connectivity using normal routing protocols to the 2890 fixed node. Any datagrams sent to the fixed node will thus use 2891 recursive tunneling as described above. 2893 Alternatively, the mobile router MAY advertise connectivity to the 2894 entire mobile network using normal IP routing protocols through a 2895 bi-directional tunnel to its own home agent. This method avoids the 2896 need for recursive tunneling of datagrams. 2898 4.6. ARP, Proxy ARP, and Gratuitous ARP 2900 The use of ARP [16] requires special rules for correct operation when 2901 wireless or mobile nodes are involved. The requirements specified 2902 in this section apply to all home networks in which ARP is used for 2903 address resolution. 2905 In addition to the normal use of ARP for resolving a target node's 2906 link-layer address from its IP address, this document distinguishes 2907 two special uses of ARP: 2909 - A Proxy ARP [18] is an ARP Reply sent by one node on behalf 2910 of another node which is either unable or unwilling to answer 2911 its own ARP Requests. The sender of a Proxy ARP reverses the 2912 Sender and Target Protocol Address fields as described in [16], 2913 but supplies some configured link-layer address (generally, its 2914 own) in the Sender Hardware Address field. The node receiving 2915 the Reply will then associate this link-layer address with the 2916 IP address of the original target node, causing it to transmit 2917 future datagrams for this target node to the node with that 2918 link-layer address. 2920 - A Gratuitous ARP [23] is an ARP packet sent by a node in order to 2921 spontaneously cause other nodes to update an entry in their ARP 2922 cache. A gratuitous ARP MAY use either an ARP Request or an ARP 2923 Reply packet. In either case, the ARP Sender Protocol Address 2924 and ARP Target Protocol Address are both set to the IP address 2925 of the cache entry to be updated, and the ARP Sender Hardware 2926 Address is set to the link-layer address to which this cache 2927 entry should be updated. When using an ARP Reply packet, the 2928 Target Hardware Address is also set to the link-layer address to 2929 which this cache entry should be updated (this field is not used 2930 in an ARP Request packet). 2932 In either case, for a gratuitous ARP, the ARP packet MUST be 2933 transmitted as a local broadcast packet on the local link. As 2934 specified in [16], any node receiving any ARP packet (Request or 2935 Reply) MUST update its local ARP cache with the Sender Protocol 2936 and Hardware Addresses in the ARP packet, if the receiving node 2937 has an entry for that IP address already in its ARP cache. This 2938 requirement in the ARP protocol applies even for ARP Request 2939 packets, and for ARP Reply packets that do not match any ARP 2940 Request transmitted by the receiving node [16]. 2942 While a mobile node is registered on a foreign network, its home 2943 agent uses proxy ARP [18] to reply to ARP Requests it receives that 2944 seek the mobile node's link-layer address. When receiving an ARP 2945 Request, the home agent MUST examine the target IP address of the 2946 Request, and if this IP address matches the home address of any 2947 mobile node for which it has a registered mobility binding, the home 2948 agent MUST transmit an ARP Reply on behalf of the mobile node. After 2949 exchanging the sender and target addresses in the packet [18], the 2950 home agent MUST set the sender link-layer address in the packet to 2951 the link-layer address of its own interface over which the Reply will 2952 be sent. 2954 When a mobile node leaves its home network and registers a binding on 2955 a foreign network, its home agent uses gratuitous ARP to update the 2956 ARP caches of nodes on the home network. This causes such nodes to 2957 associate the link-layer address of the home agent with the mobile 2958 node's home (IP) address. When registering a binding for a mobile 2959 node for which the home agent previously had no binding (the mobile 2960 node was assumed to be at home), the home agent MUST transmit a 2961 gratuitous ARP on behalf of the mobile node. This gratuitous ARP 2962 packet MUST be transmitted as a broadcast packet on the link on which 2963 the mobile node's home address is located. Since broadcasts on the 2964 local link (such as Ethernet) are typically not guaranteed to be 2965 reliable, the gratuitous ARP packet SHOULD be retransmitted a small 2966 number of times to increase its reliability. 2968 When a mobile node returns to its home network, the mobile node 2969 and its home agent use gratuitous ARP to cause all nodes on the 2970 mobile node's home network to update their ARP caches to once again 2971 associate the mobile node's own link-layer address with the mobile 2972 node's home (IP) address. Before transmitting the (de)Registration 2973 Request message to its home agent, the mobile node MUST transmit this 2974 gratuitous ARP on its home network as a local broadcast on this link. 2975 The gratuitous ARP packet SHOULD be retransmitted a small number of 2976 times to increase its reliability, but these retransmissions SHOULD 2977 proceed in parallel with the transmission and processing of its 2978 (de)Registration Request. 2980 When the mobile node's home agent receives and accepts this 2981 (de)Registration Request, the home agent MUST also transmit a 2982 gratuitous ARP on the mobile node's home network. This gratuitous 2983 ARP also is used to associate the mobile node's home address with 2984 the mobile node's own link-layer address. A gratuitous ARP is 2985 transmitted by both the mobile node and its home agent, since in the 2986 case of wireless network interfaces, the area within transmission 2987 range of the mobile node will likely differ from that within range 2988 of its its home agent. Th ARP packet from the home agent MUST be 2989 transmitted as a local broadcast on the mobile node's home link, 2990 and SHOULD be retransmitted a small number of times to increase 2991 its reliability; these retransmissions, however, SHOULD proceed in 2992 parallel with the transmission and processing of its (de)Registration 2993 Reply. 2995 While the mobile node is away from home, it MUST NOT transmit any 2996 broadcast ARP Request or ARP Reply messages. Finally, while the 2997 mobile node is away from home, it MUST NOT reply to ARP Requests 2998 in which the target IP address is its own home address, unless the 2999 ARP Request is sent by a foreign agent with which the mobile node 3000 is attempting to register or a foreign agent with which the mobile 3001 node has an unexpired registration. In the latter case, the mobile 3002 node MUST use a unicast ARP Reply to respond to the foreign agent. 3003 Note that if the mobile node is using a co-located care-of address 3004 and receives an ARP Request in which the target IP address is this 3005 care-of address, then the mobile node SHOULD reply to this ARP 3006 Request. Note also that, when transmitting a Registration Request on 3007 a foreign network, a mobile node may discover the link-layer address 3008 of a foreign agent by storing the address as it is received from the 3009 Agent Advertisement from that foreign agent, but not by transmitting 3010 a broadcast ARP Request message. 3012 The specific order in which each of the above requirements for the 3013 use of ARP, proxy ARP, and gratuitous ARP are applied, relative to 3014 the transmission and processing of the mobile node's Registration 3015 Request and Registration Reply messages when leaving home or 3016 returning home, are important to the correct operation of the 3017 protocol. 3019 To summarize the above requirements, when a mobile node leaves its 3020 home network, the following steps, in this order, MUST be performed: 3022 - The mobile node decides to register away from home, perhaps 3023 because it has received an Agent Advertisement from a foreign 3024 agent and has not recently received one from its home agent. 3026 - Before transmitting the Registration Request, the mobile node 3027 disables its own future processing of any ARP Requests it 3028 may subsequently receive requesting the link-layer address 3029 corresponding to its home address, except insofar as necessary to 3030 communicate with foreign agents on visited networks. 3032 - The mobile node transmits its Registration Request. 3034 - When the mobile node's home agent receives and accepts the 3035 Registration Request, it performs a gratuitous ARP on behalf 3036 of the mobile node, and begins using proxy ARP to reply to ARP 3037 Requests that it receives requesting the mobile node's link-layer 3038 address. If, instead, the home agent rejects the Registration 3039 Request, no ARP processing (gratuitous nor proxy) is performed by 3040 the home agent. 3042 When a mobile node later returns to its home network, the following 3043 steps, in this order, MUST be performed: 3045 - The mobile node decides to register at home, perhaps because it 3046 has received an Agent Advertisement from its home agent. 3048 - Before transmitting the Registration Request, the mobile node 3049 re-enables its own future processing of any ARP Requests it may 3050 subsequently receive requesting its link-layer address. 3052 - The mobile node performs a gratuitous ARP for itself. 3054 - The mobile node transmits its Registration Request. 3056 - When the mobile node's home agent receives and accepts the 3057 Registration Request, it stops using proxy ARP to reply to 3058 ARP Requests that it receives requesting the mobile node's 3059 link-layer address, and then performs a gratuitous ARP on behalf 3060 of the mobile node. If, instead, the home agent rejects the 3061 Registration Request, no ARP processing (gratuitous nor proxy) is 3062 performed by the home agent. 3064 5. Security Considerations 3066 The mobile computing environment is potentially very different from 3067 the ordinary computing environment. In many cases, mobile computers 3068 will be connected to the network via wireless links. Such links 3069 are particularly vulnerable to passive eavesdropping, active replay 3070 attacks, and other active attacks. 3072 5.1. Message Authentication Codes 3074 Home agents and mobile nodes MUST be able to perform authentication. 3075 The default algorithm is keyed MD5 [21], with a key size of 128 3076 bits. The default mode of operation is to both precede and follow 3077 the data to be hashed, by the 128-bit key; that is, MD5 is to be 3078 used in "prefix+suffix" mode. The foreign agent MUST also support 3079 authentication using keyed MD5 and key sizes of 128 bits or greater, 3080 with manual key distribution. More authentication algorithms, 3081 algorithm modes, key distribution methods, and key sizes MAY also be 3082 supported. 3084 5.2. Areas of Security Concern in this Protocol 3086 The registration protocol described in this document will result 3087 in a mobile node's traffic being tunneled to its care-of address. 3088 This tunneling feature could be a significant vulnerability if the 3089 registration were not authenticated. Such remote redirection, for 3090 instance as performed by the mobile registration protocol, is widely 3091 understood to be a security problem in the current Internet if not 3092 authenticated [2]. Moreover, the Address Resolution Protocol (ARP) 3093 is not authenticated, and can potentially be used to steal another 3094 host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings 3095 with it all of the risks associated with the use of ARP. 3097 5.3. Key Management 3099 This specification requires a strong authentication mechanism 3100 (keyed MD5) which precludes many potential attacks based on the 3101 Mobile IP registration protocol. However, because key distribution 3102 is difficult in the absence of a network key management protocol, 3103 messages with the foreign agent are not all required to be 3104 authenticated. In a commercial environment it might be important 3105 to authenticate all messages between the foreign agent and the home 3106 agent, so that billing is possible, and service providers do not 3107 provide service to users that are not legitimate customers of that 3108 service provider. 3110 5.4. Picking Good Random Numbers 3112 The strength of any authentication mechanism depends on several 3113 factors, including the innate strength of the authentication 3114 algorithm, the secrecy of the key used, the strength of the key used, 3115 and the quality of the particular implementation. This specification 3116 requires implementation of keyed MD5 for authentication, but does not 3117 preclude the use of other authentication algorithms and modes. For 3118 keyed MD5 authentication to be useful, the 128-bit key must be both 3119 secret (that is, known only to authorized parties) and pseudo-random. 3120 If nonces are used in connection with replay protection, they must 3121 also be selected carefully. Eastlake, et al. [7] provides more 3122 information on generating pseudo-random numbers. 3124 5.5. Privacy 3126 Users who have sensitive data that they do not wish others to see 3127 should use mechanisms outside the scope of this document (such as 3128 encryption) to provide appropriate protection. Users concerned about 3129 traffic analysis should consider appropriate use of link encryption. 3130 If absolute location privacy is desired, the mobile node can create a 3131 tunnel to its home agent. Then, datagrams destined for correspondent 3132 nodes will appear to emanate from the home network, and it may be 3133 more difficult to pinpoint the location of the mobile node. Such 3134 mechanisms are all beyond the scope of this document. 3136 5.6. Replay Protection for Registration Requests 3138 The Identification field is used to let the home agent verify that a 3139 registration message has been freshly generated by the mobile node, 3140 not replayed by an attacker from some previous registration. Two 3141 methods are described in this section: timestamps (mandatory) and 3142 "nonces" (optional). All mobile nodes and home agents MUST implement 3143 timestamp-based replay protection. These nodes MAY also implement 3144 nonce-based replay protection (but see Appendix A.2 for a patent that 3145 may apply to nonce-based replay protection). 3147 The style of replay protection in effect between a mobile node 3148 and its home agent is part of the mobile security association. A 3149 mobile node and its home agent MUST agree on which method of replay 3150 protection will be used. The interpretation of the Identification 3151 field depends on the method of replay protection as described in the 3152 subsequent subsections. 3154 Whatever method is used, the low-order 32 bits of the Identification 3155 MUST be copied unchanged from the Registration Request to the 3156 Reply. The foreign agent uses those bits (and the mobile node's 3157 home address) to match Registration Requests with corresponding 3158 replies. The mobile node MUST verify that the low-order 32 bits 3159 of any Registration Reply are identical to the bits it sent in the 3160 Registration Request. 3162 The Identification in a new Registration Request MUST NOT be the same 3163 as in an immediately preceding Request, and SHOULD NOT repeat while 3164 the same security context is being used between the mobile node and 3165 the home agent. Retransmission as in Section 3.6.3 is allowed. 3167 5.6.1. Replay Protection using Timestamps 3169 The basic principle of timestamp replay protection is that the node 3170 generating a message inserts the current time of day, and the node 3171 receiving the message checks that this timestamp is sufficiently 3172 close to its own time of day. Obviously the two nodes must have 3173 adequately synchronized time-of-day clocks. As with any messages, 3174 time synchronization messages may be protected against tampering 3175 by an authentication mechanism determined by the security context 3176 between the two nodes. 3178 If timestamps are used, the mobile node MUST set the Identification 3179 field to a 64-bit value formatted as specified by the Network Time 3180 Protocol [13]. The low-order 32 bits of the NTP format represent 3181 fractional seconds, and those bits which are not available from a 3182 time source SHOULD be generated from a good source of randomness. 3183 Note, however, that when using timestamps, the 64-bit Identification 3184 used in a Registration Request from the mobile node MUST be greater 3185 than that used in any previous Registration Request, as the home 3186 agent uses this field also as a sequence number. Without such a 3187 sequence number, it would be possible for a delayed duplicate of an 3188 earlier Registration Request to arrive at the home agent (within 3189 the clock synchronization required by the home agent), and thus be 3190 applied out of order, mistakenly altering the mobile node's current 3191 registered care-of address. 3193 Upon receipt of a Registration Request with a valid Mobile-Home 3194 Authentication Extension, the home agent MUST check the 3195 Identification field for validity. In order to be valid, the 3196 timestamp contained in the Identification field MUST be close enough 3197 to the home agent's time of day clock and the timestamp MUST be 3198 greater than all previously accepted timestamps for the requesting 3199 mobile node. Time tolerances and resynchronization details are 3200 specific to a particular mobility security association. 3202 If the timestamp is valid, the home agent copies the entire 3203 Identification field into the Registration Reply it returns the Reply 3204 to the mobile node. If the timestamp is not valid, the home agent 3205 copies only the low-order 32 bits into the Registration Reply, and 3206 supplies the high-order 32 bits from its own time of day. In this 3207 latter case, the home agent MUST reject the registration by returning 3208 Code 133 (identification mismatch) in the Registration Reply. 3210 As described in Section 3.6.2.1, the mobile node MUST verify that the 3211 low-order 32 bits of the Identification in the Registration Reply are 3212 identical to those in the rejected registration attempt, before using 3213 the high-order bits for clock resynchronization. 3215 5.6.2. Replay Protection using Nonces 3217 Implementors of this optional mechanism should examine Appendix A.2 3218 for a patent that may be applicable to nonce-based replay protection. 3220 The basic principle of nonce replay protection is that node A 3221 includes a new random number in every message to node B, and 3222 checks that node B returns that same number in its next message to 3223 node A. Both messages use an authentication code to protect against 3224 alteration by an attacker. At the same time node B can send its own 3225 nonces in all messages to node A (to be echoed by node A), so that it 3226 too can verify that it is receiving fresh messages. 3228 The home agent may be expected to have resources for computing 3229 pseudo-random numbers useful as nonces [7]. It inserts a new nonce 3230 as the high-order 32 bits of the identification field of every 3231 Registration Reply. The home agent copies the low-order 32 bits 3232 of the Identification from the Registration Request message into 3233 the low-order 32 bits of the Identification in the Registration 3234 Reply. When the mobile node receives an authenticated Registration 3235 Reply from the home agent, it saves the high-order 32 bits of 3236 the identification for use as the high-order 32 bits of its next 3237 Registration Request. 3239 The mobile node is responsible for generating the low-order 32 bits 3240 of the Identification in each Registration Request. Ideally it 3241 should generate its own random nonces. However it may use any 3242 expedient method, including duplication of the random value sent by 3243 the home agent. The method chosen is of concern only to the mobile 3244 node, because it is the node that checks for valid values in the 3245 Registration Reply. The high-order and low-order 32 bits of the 3246 identification chosen SHOULD both differ from their previous values. 3247 The home agent uses a new high-order value and the mobile node uses 3248 a new low-order value for each registration message. The foreign 3249 agent uses the low-order value (and the mobile host's home address) 3250 to correctly match registration replies with pending Requests 3251 (Section 3.7.1). 3253 If a registration message is rejected because of an invalid nonce, 3254 the Reply always provides the mobile node with a new nonce to 3255 be used in the next registration. Thus the nonce protocol is 3256 self-synchronizing. 3258 6. Acknowledgments 3260 Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp 3261 and John Ioannidis (JI) (Columbia), for forming the working group, 3262 chairing it, and putting so much effort into its early development. 3264 Thanks also to Kannan Alaggapan, Greg Minshall, and Tony Li for 3265 their contributions to the group while performing the duties of 3266 chairperson, as well as for their many useful comments. 3268 Thanks to the active members of the Mobile IP Working Group, 3269 particularly those who contributed text, including (in alphabetical 3270 order) 3272 - Ran Atkinson (Naval Research Lab), 3273 - Dave Johnson (Carnegie Mellon University), 3274 - Frank Kastenholz (FTP Software), 3275 - Anders Klemets (KTH), 3276 - Chip Maguire (KTH), 3277 - Andrew Myles (Macquarie University), 3278 - Al Quirt (Bell Northern Research), 3279 - Yakov Rekhter (IBM), and 3280 - Fumio Teraoka (Sony). 3282 Thanks to Charlie Kunzinger and to Bill Simpson, the editors who 3283 produced the first drafts for of this document, reflecting the 3284 discussions of the Working Group. Much of the new text in the latest 3285 drafts is due to Jim Solomon and Dave Johnson. 3287 Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), and Frank 3288 Kastenholz (FTP Software) for their generous support in hosting 3289 interim Working Group meetings. 3291 A. Patent Issues 3293 As of the time of publication, the IETF had been made aware of 3294 two patents that may be relevant to implementors of the protocol 3295 described in this technical specification. 3297 A.1. IBM Patent #5,159,592 3299 Charles Perkins, editor of this draft, is sole inventor of 3300 U.S. Patent No. 5,159,592, assigned to IBM. In a letter dated 3301 May 30, 1995, IBM brought this patent to the attention of the IETF, 3302 stating that this patent "relates to the Mobile IP." We understand 3303 that IBM did not intend to assert that any particular implementation 3304 of Mobile IP would or would not infringe the patent, but rather that 3305 IBM was meeting what it viewed as a duty to disclose information that 3306 could be relevant to the process of adopting a standard. 3308 Based on a review of the claims of the patent, IETF believes that 3309 a system of registering an address obtained from a foreign agent, 3310 as described in the draft, would not necessarily infringe any of 3311 the claims of the patent; and that a system in which an address is 3312 obtained elsewhere and then registered can be implemented without 3313 necessarily infringing any claims of the patent. Accordingly, 3314 our view is that the proposed protocol can be implemented without 3315 necessarily infringing the Perkins Patent. 3317 Parties considering adopting this protocol must be aware that 3318 some specific implementations, or features added to otherwise 3319 non-infringing implementations, may raise an issue of infringement 3320 with respect to this patent or to some other patent. 3322 This statement is for the IETF's assistance in its standard-setting 3323 procedure, and should not be relied upon by any party as an opinion 3324 or guarantee that any implementation it might make or use would 3325 not be covered by the Perkins Patent and any other patents. In 3326 particular, IBM might disagree with the interpretation of this patent 3327 described herein. 3329 A.2. IBM Patent #5,148,479 3331 This patent, also assigned to IBM, may be relevant to those 3332 who implement nonce-based replay protection as described in 3333 Section 5.6.2. Note that nonce-based replay protection is an 3334 optional feature of this specification. Timestamp-based replay 3335 protection, on the other hand, (Section 5.6.1) is a requirement of 3336 this specification. 3338 B. Link-Layer Considerations 3340 The mobile node MAY use link-layer mechanisms to decide that its 3341 point of attachment has changed. Such indications include the 3342 Down/Testing/Up interface status [11], and changes in cell or 3343 administration. The mechanisms will be specific to the particular 3344 link-layer technology, and are outside the scope of this document. 3346 The Point-to-Point-Protocol (PPP) [22] and its Internet Protocol 3347 Control Protocol (IPCP) [12], negotiates the use of IP addresses. 3349 The mobile node SHOULD first attempt to specify its home address, 3350 so that if the mobile node is attaching to its home network, the 3351 unrouted link will function correctly. When the home address is 3352 not accepted by the peer, but a transient IP address is dynamically 3353 assigned to the mobile node, and the mobile node is capable of 3354 supporting a co-located care-of address, the mobile node MAY 3355 register that address as a co-located care-of address. When the peer 3356 specifies its own IP address, that address MUST NOT be assumed to be 3357 a foreign agent care-of address or the IP address of a home agent. 3359 C. TCP Considerations 3361 C.1. TCP Timers 3363 Most hosts and routers which implement TCP/IP do not permit easy 3364 configuration of the TCP timer values. When high-delay (e.g., 3365 SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are 3366 in use, the default TCP timer values in many systems may cause 3367 retransmissions or timeouts, even when the link and network are 3368 actually operating properly with greater than usual delays because 3369 of the medium in use. This can cause an inability to create or 3370 maintain TCP connections over such links, and can also cause unneeded 3371 retransmissions which consume already scarce bandwidth. Vendors are 3372 encouraged to make TCP timers more configurable. Vendors of systems 3373 designed for the mobile computing markets should pick default timer 3374 values more suited to low-bandwidth, high-delay links. Users of 3375 mobile nodes should be sensitive to the possibility of timer-related 3376 difficulties. 3378 C.2. TCP Congestion Management 3380 Mobile nodes often use media which are more likely to introduce 3381 errors, effectively causing more packets to be dropped. This 3382 introduces a conflict with the mechanisms for congestion management 3383 found in modern versions of TCP [9]. Now, when a packet is dropped, 3384 the correspondent node's TCP implementation is likely to react as 3385 if there were a source of network congestion, and initiate the 3386 slow-start mechanisms [9] designed for controlling that problem. 3387 However, those mechanisms are inappropriate for overcoming errors 3388 introduced by the links themselves, and have the effect of magnifying 3389 the discontinuity introduced by the dropped packet. This problem 3390 has been analyzed by Caceres, et al. [3]; there is no easy solution 3391 available, and certainly no solution likely to be installed soon on 3392 all correspondent nodes. While this problem is beyond the scope 3393 of this document, it does illustrate that providing performance 3394 transparency to mobile nodes involves understanding mechanisms 3395 outside the network layer. It also indicates the need to avoid 3396 designs which systematically drop packets; such designs might 3397 otherwise be considered favorably when making engineering tradeoffs. 3399 D. Example Scenarios 3401 This section shows example Registration Requests for several common 3402 scenarios. 3404 D.1. Registering with a Foreign Agent Care-of Address 3406 The mobile node receives an Agent Advertisement from a foreign 3407 agent and wishes to register with that agent using the advertised 3408 foreign agent care-of address. The mobile node wishes only 3409 IP-in-IP encapsulation, does not want broadcasts, and does not want 3410 simultaneous mobility bindings: 3412 IP fields: 3413 Source Address = mobile node's home address 3414 Destination Address = copied from the IP source address of the 3415 Agent Advertisement 3416 Time to Live = 1 3417 UDP fields: 3418 Source Port = 3419 Destination Port = 434 3420 Registration Request fields: 3421 Type = 1 3422 S=0,B=0,D=0,M=0,G=0 3423 Lifetime = the Registration Lifetime copied from the 3424 Mobility Agent Advertisement Extension of the 3425 Router Advertisement message 3426 Home Address = the mobile node's home address 3427 Home Agent = IP address of mobile node's home agent 3428 Care-of Address = the Care-of Address copied from the 3429 Mobility Agent Advertisement Extension of the 3430 Router Advertisement message 3431 Identification = Network Time Protocol timestamp or Nonce 3432 Extensions: 3433 The Mobile-Home Authentication Extension 3435 D.2. Registering with a Co-Located Care-of Address 3437 The mobile node enters a foreign network that contains no foreign 3438 agents. The mobile node obtains an address from a DHCP server [6] 3439 for use as a co-located care-of address. The mobile node supports 3440 all forms of encapsulation (IP-in-IP, minimal encapsulation, and 3441 GRE), desires a copy of broadcast datagrams on the home network, and 3442 does not want simultaneous mobility bindings: 3444 IP fields: 3445 Source Address = care-of address obtained from DHCP server 3446 Destination Address = IP address of home agent 3447 Time to Live = 64 3448 UDP fields: 3449 Source Port = 3450 Destination Port = 434 3451 Registration Request fields: 3452 Type = 1 3453 S=0,B=1,D=1,M=1,G=1 3454 Lifetime = 1800 (seconds) 3455 Home Address = the mobile node's home address 3456 Home Agent = IP address of mobile node's home agent 3457 Care-of Address = care-of address obtained from DHCP server 3458 Identification = Network Time Protocol timestamp or Nonce 3459 Extensions: 3460 The Mobile-Home Authentication Extension 3462 D.3. Deregistration 3464 The mobile node returns home and wishes to deregister all care-of 3465 addresses with its home agent. 3467 IP fields: 3468 Source Address = mobile node's home address 3469 Destination Address = IP address of home agent 3470 Time to Live = 1 3471 UDP fields: 3472 Source Port = 3473 Destination Port = 434 3474 Registration Request fields: 3475 Type = 1 3476 S=0,B=0,D=0,M=0,G=0 3477 Lifetime = 0 3478 Home Address = the mobile node's home address 3479 Home Agent = IP address of mobile node's home agent 3480 Care-of Address = the mobile node's home address 3481 Identification = Network Time Protocol timestamp or Nonce 3482 Extensions: 3483 The Mobile-Home Authentication Extension 3485 E. Applicability of Prefix Lengths Extension 3487 Caution is indicated with the use of the Prefix Lengths Extension 3488 over wireless links, due to the irregular coverage areas provided by 3489 wireless transmitters. As a result, it is possible that two foreign 3490 agents advertising the same prefix might indeed provide different 3491 connectivity to prospective mobile nodes. The Prefix-Lengths 3492 Extension SHOULD NOT be included in the advertisements sent by agents 3493 in such a configuration. 3495 Foreign agents using different wireless interfaces would have to 3496 cooperate using special protocols to provide identical coverage 3497 in space, and thus be able to claim to have wireless interfaces 3498 situated on the same subnetwork. In the case of wired interfaces, 3499 a mobile node disconnecting and subsequently connecting to a new 3500 point of attachment, may well send in a new Registration Request 3501 no matter whether the new advertisement is on the same medium as 3502 the last recorded advertisement. And, finally, in areas with dense 3503 populations of foreign agents it would seem unwise to require the 3504 propagation via routing protocols of the subnet prefixes associated 3505 with each individual wireless foreign agent; such a strategy could 3506 lead to quick depletion of available space for routing tables, 3507 unwarranted increases in the time required for processing routing 3508 updates, and longer decision times for route selection if routes 3509 (which are almost always unnecessary) are stored for wireless 3510 "subnets". 3512 References 3514 [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 3516 [2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. 3517 ACM Computer Communications Review, 19(2), March 1989. 3519 [3] Ramon Caceres and Liviu Iftode. Improving the Performance 3520 of Reliable Transport Protocols in Mobile Computing 3521 Environments. IEEE Journal on Selected Areas in Communications, 3522 13(5):850--857, June 1995. 3524 [4] Stephen E. Deering, editor. ICMP Router Discovery Messages. 3525 RFC 1256, September 1991. 3527 [5] Steve Deering. Host Extensions for IP Multicasting. RFC 1112, 3528 August 1989. 3530 [6] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 3531 October 1993. 3533 [7] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. 3534 Randomness Requirements for Security. RFC 1750, December 1994. 3536 [8] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 3537 Routing Encapsulation (GRE). RFC 1701, October 1994. 3539 [9] Van Jacobson. Congestion Avoidance and Control. In Proceedings 3540 of the SIGCOMM '88 Symposium: Communications Architectures & 3541 Protocols, pages 314--329, August 1988. 3543 [10] Van Jacobson. Compressing TCP/IP Headers for Low-Speed Serial 3544 Links. RFC 1144, February 1990. 3546 [11] Keith McCloghrie and Frank Kastenholz. Evolution of the 3547 Interfaces Group of MIB-II. RFC 1573, January 1994. 3549 [12] Glenn McGregor. The PPP Internet Protocol Control Protocol 3550 (IPCP). RFC 1332, May 1992. 3552 [13] David L. Mills. Network Time Protocol (Version 3): 3553 Specification, Implementation and Analysis. RFC 1305, March 3554 1992. 3556 [14] Charles Perkins. IP Encapsulation within IP. 3557 draft-ietf-mobileip-ip4inip4-02.txt (work in progress), May 1996. 3559 [15] Charles Perkins. Minimal Encapsulation within IP. 3560 draft-ietf-mobileip-minenc-02.txt, May 1996. (work in 3561 progress). 3563 [16] David C. Plummer. An Ethernet Address Resolution Protocol: 3564 Or Converting Network Protocol Addresses to 48.bit Ethernet 3565 Addresses for Transmission on Ethernet Hardware. RFC 826, 3566 November 1982. 3568 [17] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 3570 [18] J. B. Postel. Multi-LAN Address Resolution. RFC 925, October 3571 1984. 3573 [19] J. B. Postel, Editor. Internet Protocol. RFC 791, September 3574 1981. 3576 [20] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, 3577 October 1994. 3579 [21] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 3580 April 1992. 3582 [22] William Allen Simpson, editor. The Point-to-Point Protocol 3583 (PPP). RFC 1661, July 1994. 3585 [23] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The 3586 Protocols. Addison-Wesley, Reading, Massachusetts, 1994. 3588 Editor's Address 3590 Questions about this memo can also be directed to the editor: 3592 Charles Perkins 3593 Room H3-D34 3594 T. J. Watson Research Center 3595 IBM Corporation 3596 30 Saw Mill River Rd. 3597 Hawthorne, NY 10532 3599 Work: +1-914-784-7350 3600 Fax: +1-914-784-6205 3601 E-mail: perk@watson.ibm.com 3603 The working group can be contacted via the current chair: 3605 Jim Solomon 3606 Motorola, Inc. 3607 1301 E. Algonquin Rd. 3608 Schaumburg, IL 60196 3610 Work: +1-847-576-2753 3611 E-mail: solomon@comm.mot.com