idnits 2.17.1 draft-ietf-mobileip-rfc2002-bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 4147 has weird spacing: '...ensions used ...' == 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 (20 September 2000) is 8618 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- No information found for draft-ietf-mobileip-vendor-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 1750 (ref. '11') (Obsoleted by RFC 4086) -- No information found for draft-ietf-mobileip-regtun - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 2402 (ref. '16') (Obsoleted by RFC 4302, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '17') ** Obsolete normative reference: RFC 1573 (ref. '18') (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1305 (ref. '20') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2344 (ref. '21') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '22') ** Obsolete normative reference: RFC 2002 (ref. '24') (Obsoleted by RFC 3220) -- Unexpected draft version: The latest known version of draft-ietf-mobileip-gen-key is -01, but you're referring to -02. (However, the state information for draft-ietf-mobileip-regtun is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. '26' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-09 -- Possible downref: Normative reference to a draft: ref. '27' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-03 -- Possible downref: Normative reference to a draft: ref. '28' ** Downref: Normative reference to an Unknown state RFC: RFC 925 (ref. '32') ** Obsolete normative reference: RFC 1700 (ref. '33') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '34') -- Possible downref: Non-RFC (?) normative reference: ref. '38' Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 15 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 Nokia Research Center 3 20 September 2000 5 IP Mobility Support for IPv4, revised 6 draft-ietf-mobileip-rfc2002-bis-03.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@STANDARDS.NORTELNETWORKS.COM mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 30 http://www.ietf.org/shadow.html. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 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. Message Format and Protocol Extensibility . . . . . . . . 10 62 2. Agent Discovery 12 63 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 12 64 2.1.1. Mobility Agent Advertisement Extension . . . . . 14 65 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . 16 66 2.1.3. One-byte Padding Extension . . . . . . . . . . . 17 67 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 17 68 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 17 69 2.3.1. Advertised Router Addresses . . . . . . . . . . . 18 70 2.3.2. Sequence Numbers and Rollover Handling . . . . . 19 71 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 19 72 2.4.1. Registration Required . . . . . . . . . . . . . . 20 73 2.4.2. Move Detection . . . . . . . . . . . . . . . . . 21 74 2.4.3. Returning Home . . . . . . . . . . . . . . . . . 22 75 2.4.4. Sequence Numbers and Rollover Handling . . . . . 22 77 3. Registration 23 78 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 23 79 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 25 80 3.3. Registration Request . . . . . . . . . . . . . . . . . . 25 81 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 27 82 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 31 83 3.5.1. Computing Authentication Extension Values . . . . 31 84 3.5.2. Mobile-Home Authentication Extension . . . . . . 32 85 3.5.3. Mobile-Foreign Authentication Extension . . . . . 32 86 3.5.4. Foreign-Home Authentication Extension . . . . . . 33 87 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 34 88 3.6.1. Sending Registration Requests . . . . . . . . . . 35 89 3.6.2. Receiving Registration Replies . . . . . . . . . 39 90 3.6.3. Registration Retransmission . . . . . . . . . . . 42 91 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 42 92 3.7.1. Configuration and Registration Tables . . . . . . 43 93 3.7.2. Receiving Registration Requests . . . . . . . . . 44 94 3.7.3. Receiving Registration Replies . . . . . . . . . 47 95 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 49 96 3.8.1. Configuration and Registration Tables . . . . . . 49 97 3.8.2. Receiving Registration Requests . . . . . . . . . 50 98 3.8.3. Sending Registration Replies . . . . . . . . . . 54 100 4. Routing Considerations 56 101 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 56 102 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 57 103 4.2.1. Mobile Node Considerations . . . . . . . . . . . 57 104 4.2.2. Foreign Agent Considerations . . . . . . . . . . 58 105 4.2.3. Home Agent Considerations . . . . . . . . . . . . 58 106 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 60 107 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 61 108 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 62 109 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 63 111 5. Security Considerations 68 112 5.1. Message Authentication Codes . . . . . . . . . . . . . . 68 113 5.2. Areas of Security Concern in this Protocol . . . . . . . 68 114 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 68 115 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 69 116 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 69 117 5.6. Replay Protection for Registration Requests . . . . . . . 69 118 5.6.1. Replay Protection using Timestamps . . . . . . . 70 119 5.6.2. Replay Protection using Nonces . . . . . . . . . 71 121 6. IANA Considerations 72 123 7. Acknowledgments 72 125 A. Patent Issues 74 126 A.1. IBM Patent #5,159,592 . . . . . . . . . . . . . . . . . . 74 127 A.2. IBM Patent #5,148,479 . . . . . . . . . . . . . . . . . . 74 129 B. Link-Layer Considerations 75 131 C. TCP Considerations 76 132 C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 76 133 C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 76 135 D. Example Scenarios 77 136 D.1. Registering with a Foreign Agent Care-of Address . . . . 77 137 D.2. Registering with a Co-Located Care-of Address . . . . . . 77 138 D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 78 140 E. Applicability of Prefix-Lengths Extension 79 141 F. Changes since RFC 2002 79 142 F.1. Changes since revision 02 of RFC2002bis . . . . . . . . . 79 143 F.2. Changes Preceding Revision 02 of RFC2002bis . . . . . . . 80 145 G. Number Assignments 82 146 G.1. Mobile IP Message Types . . . . . . . . . . . . . . . . . 83 147 G.2. Extensions to RFC 1256 Router Advertisement . . . . . . . 83 148 G.3. Extensions to Mobile IP Registration Messages . . . . . . 83 149 G.4. Code Values for Mobile IP Registration Reply Messages . . 83 151 H. Proposed Number Assignments 85 152 H.1. Proposed Extensions to RFC 1256 Router Advertisement . . 85 153 H.2. Proposed New Mobile IP Message Types . . . . . . . . . . 85 154 H.3. Proposed Extensions to Mobile IP Registration Messages . 86 155 H.4. Proposed Code Values for Mobile IP Registration Reply 156 Messages . . . . . . . . . . . . . . . . . . . . . . . 86 157 H.5. Proposed SPI Values for the Mobile IP Reserved SPIs . . . 87 158 H.6. Proposed Subtypes for the Generalized Authentication 159 Extension . . . . . . . . . . . . . . . . . . . . . . 87 161 I. Example Messages 88 162 I.1. Example ICMP Agent Advertisement Message Format . . . . . 88 163 I.2. Example Registration Request Message Format . . . . . . . 89 164 I.3. Example Registration Reply Message Format . . . . . . . . 90 166 Addresses 94 167 1. Introduction 169 IP version 4 assumes that a node's IP address uniquely identifies the 170 node's point of attachment to the Internet. Therefore, a node must 171 be located on the network indicated by its IP address in order to 172 receive datagrams destined to it; otherwise, datagrams destined to 173 the node would be undeliverable. For a node to change its point of 174 attachment without losing its ability to communicate, currently one 175 of the two following mechanisms must typically be employed: 177 a) the node must change its IP address whenever it changes its 178 point of attachment, or 180 b) host-specific routes must be propagated throughout much of 181 the Internet routing fabric. 183 Both of these alternatives are often unacceptable. The first makes 184 it impossible for a node to maintain transport and higher-layer 185 connections when the node changes location. The second has obvious 186 and severe scaling problems, especially relevant considering the 187 explosive growth in sales of notebook (mobile) computers. 189 A new, scalable, mechanism is required for accommodating node 190 mobility within the Internet. This document defines such a 191 mechanism, which enables nodes to change their point of attachment to 192 the Internet without changing their IP address. 194 Changes between this revised specification for Mobile IP and the 195 original specifications (see [24, 23, 25, 37, 6] are detailed in the 196 appendix section F. 198 1.1. Protocol Requirements 200 A mobile node must be able to communicate with other nodes after 201 changing its link-layer point of attachment to the Internet, yet 202 without changing its IP address. 204 A mobile node must be able to communicate with other nodes that do 205 not implement these mobility functions. No protocol enhancements are 206 required in hosts or routers that are not acting as any of the new 207 architectural entities introduced in Section 1.5. 209 All messages used to update another node as to the location of a 210 mobile node must be authenticated in order to protect against remote 211 redirection attacks. 213 1.2. Goals 215 The link by which a mobile node is directly attached to the 216 Internet may often be a wireless link. This link may thus have a 217 substantially lower bandwidth and higher error rate than traditional 218 wired networks. Moreover, mobile nodes are likely to be battery 219 powered, and minimizing power consumption is important. Therefore, 220 the number of administrative messages sent over the link by which a 221 mobile node is directly attached to the Internet should be minimized, 222 and the size of these messages should be kept as small as is 223 reasonably possible. 225 1.3. Assumptions 227 The protocols defined in this document place no additional 228 constraints on the assignment of IP addresses. That is, a mobile 229 node can be assigned an IP address by the organization that owns the 230 machine. 232 This protocol assumes that mobile nodes will generally not change 233 their point of attachment to the Internet more frequently than once 234 per second. 236 This protocol assumes that IP unicast datagrams are routed based on 237 the destination address in the datagram header (and not, for example, 238 by source address). 240 1.4. Applicability 242 Mobile IP is intended to enable nodes to move from one IP subnet to 243 another. It is just as suitable for mobility across homogeneous 244 media as it is for mobility across heterogeneous media. That is, 245 Mobile IP facilitates node movement from one Ethernet segment to 246 another as well as it accommodates node movement from an Ethernet 247 segment to a wireless LAN, as long as the mobile node's IP address 248 remains the same after such a movement. 250 One can think of Mobile IP as solving the "macro" mobility management 251 problem. It is less well suited for more "micro" mobility management 252 applications -- for example, handoff amongst wireless transceivers, 253 each of which covers only a very small geographic area. As long 254 as node movement does not occur between points of attachment on 255 different IP subnets, link-layer mechanisms for mobility (i.e., 256 link-layer handoff) may offer faster convergence and far less 257 overhead than Mobile IP. 259 1.5. New Architectural Entities 261 Mobile IP introduces the following new functional entities: 263 Mobile Node 265 A host or router that changes its point of attachment from one 266 network or subnetwork to another. A mobile node may change its 267 location without changing its IP address; it may continue to 268 communicate with other Internet nodes at any location using its 269 (constant) IP address, assuming link-layer connectivity to a 270 point of attachment is available. 272 Home Agent 274 A router on a mobile node's home network which tunnels 275 datagrams for delivery to the mobile node when it is away from 276 home, and maintains current location information for the mobile 277 node. 279 Foreign Agent 281 A router on a mobile node's visited network which provides 282 routing services to the mobile node while registered. The 283 foreign agent detunnels and delivers datagrams to the mobile 284 node that were tunneled by the mobile node's home agent. For 285 datagrams sent by a mobile node, the foreign agent may serve as 286 a default router for registered mobile nodes. 288 A mobile node is given a long-term IP address on a home network. 289 This home address is administered in the same way as a "permanent" IP 290 address is provided to a stationary host. When away from its home 291 network, a "care-of address" is associated with the mobile node and 292 reflects the mobile node's current point of attachment. The mobile 293 node uses its home address as the source address of all IP datagrams 294 that it sends, except where otherwise described in this document for 295 datagrams sent for certain mobility management functions (e.g., as in 296 Section 3.6.1.1). 298 1.6. Terminology 300 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 301 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 302 document are to be interpreted as described in RFC 2119 [2]. 304 In addition, this document frequently uses the following terms: 306 Authorization-enabling extension 307 An authentication which makes a (registration) message 308 acceptable to the ultimate recipient of the registration 309 message. An authorization-enabling extension MUST 310 contain an SPI. 312 In this document, all uses of authorization-enabling 313 extension refer to authentication extensions that enable 314 the Registration Request message to be acceptable to 315 the home agent. Using additional protocol structures 316 specified outside of this document, it may be possible 317 for the mobile node to provide authentication of its 318 registration to the home agent, by way of another 319 authenticating entity within the network that is 320 acceptable to the home agent (for example, see RFC 321 2794 [4]). 323 Agent Advertisement 324 An advertisement message constructed by attaching a 325 special Extension to a router advertisement [7] message. 327 Authentication The process of verifying (using cryptographic 328 techniques, for all applications in this specification) 329 the identity of the originator of a message. 331 Care-of Address 332 The termination point of a tunnel toward a mobile node, 333 for datagrams forwarded to the mobile node while it is 334 away from home. The protocol can use two different types 335 of care-of address: a "foreign agent care-of address" is 336 an address of a foreign agent with which the mobile node 337 is registered, and a "co-located care-of address" is an 338 externally obtained local address which the mobile node 339 has associated with one of its own network interfaces. 341 Correspondent Node 342 A peer with which a mobile node is communicating. A 343 correspondent node may be either mobile or stationary. 345 Foreign Network 346 Any network other than the mobile node's Home Network. 348 Home Address 349 An IP address that is assigned for an extended period of 350 time to a mobile node. It remains unchanged regardless 351 of where the node is attached to the Internet. 353 Home Network 354 A network, possibly virtual, having a network prefix 355 matching that of a mobile node's home address. Note that 356 standard IP routing mechanisms will deliver datagrams 357 destined to a mobile node's Home Address to the mobile 358 node's Home Network. 360 Link A facility or medium over which nodes can communicate at 361 the link layer. A link underlies the network layer. 363 Link-Layer Address 364 The address used to identify an endpoint of some 365 communication over a physical link. Typically, the 366 Link-Layer address is an interface's Media Access Control 367 (MAC) address. 369 Mobility Agent 370 Either a home agent or a foreign agent. 372 Mobility Binding 373 The association of a home address with a care-of address, 374 along with the remaining lifetime of that association. 376 Mobility Security Association 377 A collection of security contexts, between a pair 378 of nodes, which may be applied to Mobile IP protocol 379 messages exchanged between them. Each context indicates 380 an authentication algorithm and mode (Section 5.1), a 381 secret (a shared key, or appropriate public/private 382 key pair), and a style of replay protection in use 383 (Section 5.6). 385 Node A host or a router. 387 Nonce A randomly chosen value, different from previous choices, 388 inserted in a message to protect against replays. 390 Security Parameter Index (SPI) 391 An index identifying a security context between a pair 392 of nodes among the contexts available in the Mobility 393 Security Association. SPI values 0 through 255 are 394 reserved and MUST NOT be used in any Mobility Security 395 Association. 397 Tunnel The path followed by a datagram while it is encapsulated. 398 The model is that, while it is encapsulated, a datagram 399 is routed to a knowledgeable decapsulating agent, which 400 decapsulates the datagram and then correctly delivers it 401 to its ultimate destination. 403 Virtual Network 404 A network with no physical instantiation beyond a router 405 (with a physical network interface on another network). 406 The router (e.g., a home agent) generally advertises 407 reachability to the virtual network using conventional 408 routing protocols. 410 Visited Network 411 A network other than a mobile node's Home Network, to 412 which the mobile node is currently connected. 414 Visitor List 415 The list of mobile nodes visiting a foreign agent. 417 1.7. Protocol Overview 419 The following support services are defined for Mobile IP: 421 Agent Discovery 422 Home agents and foreign agents may advertise their 423 availability on each link for which they provide service. 424 A newly arrived mobile node can send a solicitation on 425 the link to learn if any prospective agents are present. 427 Registration 428 When the mobile node is away from home, it registers 429 its care-of address with its home agent. Depending on 430 its method of attachment, the mobile node will register 431 either directly with its home agent, or through a foreign 432 agent which forwards the registration to the home agent. 434 silently discard 435 The implementation discards the datagram without further 436 processing, and without indicating an error to the 437 sender. The implementation SHOULD provide the capability 438 of logging the error, including the contents of the 439 discarded datagram, and SHOULD record the event in a 440 statistics counter. 442 The following steps provide a rough outline of operation of the 443 Mobile IP protocol: 445 - Mobility agents (i.e., foreign agents and home agents) advertise 446 their presence via Agent Advertisement messages (Section 2). A 447 mobile node may optionally solicit an Agent Advertisement message 448 from any locally attached mobility agents through an Agent 449 Solicitation message. 451 - A mobile node receives these Agent Advertisements and determines 452 whether it is on its home network or a foreign network. 454 - When the mobile node detects that it is located on its home 455 network, it operates without mobility services. If returning 456 to its home network from being registered elsewhere, the mobile 457 node deregisters with its home agent, through exchange of a 458 Registration Request and Registration Reply message with it. 460 - When a mobile node detects that it has moved to a foreign 461 network, it obtains a care-of address on the foreign network. 462 The care-of address can either be determined from a foreign 463 agent's advertisements (a foreign agent care-of address), or 464 by some external assignment mechanism such as DHCP [10] (a 465 co-located care-of address). 467 - The mobile node operating away from home then registers its 468 new care-of address with its home agent through exchange of a 469 Registration Request and Registration Reply message with it, 470 possibly via a foreign agent (Section 3). 472 - Datagrams sent to the mobile node's home address are intercepted 473 by its home agent, tunneled by the home agent to the mobile 474 node's care-of address, received at the tunnel endpoint (either 475 at a foreign agent or at the mobile node itself), and finally 476 delivered to the mobile node (Section 4.2.3). 478 - In the reverse direction, datagrams sent by the mobile node 479 are generally delivered to their destination using standard IP 480 routing mechanisms, not necessarily passing through the home 481 agent. 483 When away from home, Mobile IP uses protocol tunneling to hide a 484 mobile node's home address from intervening routers between its 485 home network and its current location. The tunnel terminates at 486 the mobile node's care-of address. The care-of address must be an 487 address to which datagrams can be delivered via conventional IP 488 routing. At the care-of address, the original datagram is removed 489 from the tunnel and delivered to the mobile node. 491 Mobile IP provides two alternative modes for the acquisition of a 492 care-of address: 494 - A "foreign agent care-of address" is a care-of address provided 495 by a foreign agent through its Agent Advertisement messages. In 496 this case, the care-of address is an IP address of the foreign 497 agent. In this mode, the foreign agent is the endpoint of the 498 tunnel and, upon receiving tunneled datagrams, decapsulates them 499 and delivers the inner datagram to the mobile node. This mode 500 of acquisition is preferred because it allows many mobile nodes 501 to share the same care-of address and therefore does not place 502 unnecessary demands on the already limited IPv4 address space. 504 - A "co-located care-of address" is a care-of address acquired 505 by the mobile node as a local IP address through some external 506 means, which the mobile node then associates with one of its own 507 network interfaces. The address may be dynamically acquired as a 508 temporary address by the mobile node such as through DHCP [10], 509 or may be owned by the mobile node as a long-term address for its 510 use only while visiting some foreign network. Specific external 511 methods of acquiring a local IP address for use as a co-located 512 care-of address are beyond the scope of this document. When 513 using a co-located care-of address, the mobile node serves as the 514 endpoint of the tunnel and itself performs decapsulation of the 515 datagrams tunneled to it. 517 The mode of using a co-located care-of address has the advantage 518 that it allows a mobile node to function without a foreign agent, 519 for example, in networks that have not yet deployed a foreign agent. 520 It does, however, place additional burden on the IPv4 address space 521 because it requires a pool of addresses within the foreign network 522 to be made available to visiting mobile nodes. It is difficult to 523 efficiently maintain pools of addresses for each subnet that may 524 permit mobile nodes to visit. 526 It is important to understand the distinction between the care-of 527 address and the foreign agent functions. The care-of address is 528 simply the endpoint of the tunnel. It might indeed be an address 529 of a foreign agent (a foreign agent care-of address), but it might 530 instead be an address temporarily acquired by the mobile node (a 531 co-located care-of address). A foreign agent, on the other hand, 532 is a mobility agent that provides services to mobile nodes. See 533 Sections 3.7 and 4.2.2 for additional details. 535 A home agent MUST be able to attract and intercept datagrams that 536 are destined to the home address of any of its registered mobile 537 nodes. Using the proxy and gratuitous ARP mechanisms described in 538 Section 4.6, this requirement can be satisfied if the home agent has 539 a network interface on the link indicated by the mobile node's home 540 address. Other placements of the home agent relative to the mobile 541 node's home location MAY also be possible using other mechanisms for 542 intercepting datagrams destined to the mobile node's home address. 543 Such placements are beyond the scope of this document. 545 Similarly, a mobile node and a prospective or current foreign agent 546 MUST be able to exchange datagrams without relying on standard IP 547 routing mechanisms; that is, those mechanisms which make forwarding 548 decisions based upon the network-prefix of the destination address 549 in the IP header. This requirement can be satisfied if the foreign 550 agent and the visiting mobile node have an interface on the same 551 link. In this case, the mobile node and foreign agent simply 552 bypass their normal IP routing mechanism when sending datagrams to 553 each other, addressing the underlying link-layer packets to their 554 respective link-layer addresses. Other placements of the foreign 555 agent relative to the mobile node MAY also be possible using other 556 mechanisms to exchange datagrams between these nodes, but such 557 placements are beyond the scope of this document. 559 If a mobile node is using a co-located care-of address (as described 560 in (b) above), the mobile node MUST be located on the link identified 561 by the network prefix of this care-of address. Otherwise, datagrams 562 destined to the care-of address would be undeliverable. 564 For example, the figure below illustrates the routing of datagrams 565 to and from a mobile node away from home, once the mobile node has 566 registered with its home agent. In the figure below, the mobile node 567 is using a foreign agent care-of address: 569 2) Datagram is intercepted 3) Datagram is 570 by home agent and detunneled and 571 is tunneled to the delivered to the 572 care-of address. mobile node. 574 +-----+ +-------+ +------+ 575 |home | =======> |foreign| ------> |mobile| 576 |agent| | agent | <------ | node | 577 +-----+ +-------+ +------+ 578 1) Datagram to /|\ / 579 mobile node | / 4) For datagrams sent by the 580 arrives on | / mobile node, standard IP 581 home network | / routing delivers each to its 582 via standard | |_ destination. In this figure, 583 IP routing. +----+ the foreign agent is the 584 |host| mobile node's default router. 585 +----+ 587 1.8. Message Format and Protocol Extensibility 589 Mobile IP defines a set of new control messages, sent with UDP [30] 590 using well-known port number 434. The following two message types 591 are defined in this document: 593 1 Registration Request 594 3 Registration Reply 596 Up-to-date values for the message types for Mobile IP control 597 messages are specified in the most recent "Assigned Numbers" [33]. 599 In addition, for Agent Discovery, Mobile IP makes use of the existing 600 Router Advertisement and Router Solicitation messages defined for 601 ICMP Router Discovery [7]. 603 Mobile IP defines a general Extension mechanism to allow optional 604 information to be carried by Mobile IP control messages or by ICMP 605 Router Discovery messages. Each of these Extensions (with one 606 exception) is encoded in the following Type-Length-Value format: 608 0 1 2 609 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 611 | Type | Length | Data ... 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 614 Type Indicates the particular type of Extension. 616 Length Indicates the length (in bytes) of the data field within 617 this Extension. The length does NOT include the Type and 618 Length bytes. 620 Data The particular data associated with this Extension. This 621 field may be zero or more bytes in length. The format 622 and length of the data field is determined by the type 623 and length fields. 625 Extensions allow variable amounts of information to be carried within 626 each datagram. The end of the list of Extensions is indicated by the 627 total length of the IP datagram. 629 Two separately maintained sets of numbering spaces, from which 630 Extension Type values are allocated, are used in Mobile IP: 632 - The first set consists of those Extensions which may appear only 633 in Mobile IP control messages (those sent to and from UDP port 634 number 434). In this document, the following Types are defined 635 for Extensions appearing in Mobile IP control messages: 637 32 Mobile-Home Authentication 638 33 Mobile-Foreign Authentication 639 34 Foreign-Home Authentication 641 - The second set consists of those extensions which may appear 642 only in ICMP Router Discovery messages [7]. In this document, 643 the following Types are defined for Extensions appearing in ICMP 644 Router Discovery messages: 646 0 One-byte Padding (encoded with no Length nor Data field) 647 16 Mobility Agent Advertisement 648 19 Prefix-Lengths 650 Each individual Extension is described in detail in a separate 651 section later in this document. Up-to-date values for these 652 Extension Type numbers are specified in the most recent "Assigned 653 Numbers" [33]. 655 Due to the separation (orthogonality) of these sets, it is 656 conceivable that two Extensions that are defined at a later date 657 could have identical Type values, so long as one of the Extensions 658 may be used only in Mobile IP control messages and the other may be 659 used only in ICMP Router Discovery messages. 661 When an Extension numbered in either of these sets within the range 0 662 through 127 is encountered but not recognized, the message containing 663 that Extension MUST be silently discarded. When an Extension 664 numbered in the range 128 through 255 is encountered which is not 665 recognized, that particular Extension is ignored, but the rest of 666 the Extensions and message data MUST still be processed. The Length 667 field of the Extension is used to skip the Data field in searching 668 for the next Extension. 670 2. Agent Discovery 672 Agent Discovery is the method by which a mobile node determines 673 whether it is currently connected to its home network or to a foreign 674 network, and by which a mobile node can detect when it has moved 675 from one network to another. When connected to a foreign network, 676 the methods specified in this section also allow the mobile node to 677 determine the foreign agent care-of address being offered by each 678 foreign agent on that network. 680 Mobile IP extends ICMP Router Discovery [7] as its primary 681 mechanism for Agent Discovery. An Agent Advertisement is formed by 682 including a Mobility Agent Advertisement Extension in an ICMP Router 683 Advertisement message (Section 2.1). An Agent Solicitation message 684 is identical to an ICMP Router Solicitation, except that its IP TTL 685 MUST be set to 1 (Section 2.2). This section describes the message 686 formats and procedures by which mobile nodes, foreign agents, and 687 home agents cooperate to realize Agent Discovery. 689 Agent Advertisement and Agent Solicitation may not be necessary 690 for link layers that already provide this functionality. The 691 method by which mobile nodes establish link-layer connections 692 with prospective agents is outside the scope of this document (but 693 see Appendix B). The procedures described below assume that such 694 link-layer connectivity has already been established. 696 No authentication is required for Agent Advertisement and Agent 697 Solicitation messages. They MAY be authenticated using the IP 698 Authentication Header [16], which is unrelated to the messages 699 described in this document. Further specification of the way in 700 which Advertisement and Solicitation messages may be authenticated is 701 outside of the scope of this document. 703 2.1. Agent Advertisement 705 Agent Advertisements are transmitted by a mobility agent to advertise 706 its services on a link. Mobile nodes use these advertisements to 707 determine their current point of attachment to the Internet. An 708 Agent Advertisement is an ICMP Router Advertisement that has been 709 extended to also carry an Mobility Agent Advertisement Extension 710 (Section 2.1.1) and, optionally, a Prefix-Lengths Extension 711 (Section 2.1.2), One-byte Padding Extension (Section 2.1.3), or other 712 Extensions that might be defined in the future. 714 Within an Agent Advertisement message, ICMP Router Advertisement 715 fields of the message are required to conform to the following 716 additional specifications: 718 - Link-Layer Fields 720 Destination Address 721 The link-layer destination address of a unicast 722 Agent Advertisement MUST be the same as the source 723 link-layer address of the Agent Solicitation which 724 prompted the Advertisement. 726 - IP Fields 728 TTL The TTL for all Agent Advertisements MUST be set 729 to 1. 731 Destination Address 732 As specified for ICMP Router Discovery [7], the IP 733 destination address of an Agent Advertisement MUST 734 be either the "all systems on this link" multicast 735 address (224.0.0.1) [8] or the "limited broadcast" 736 address (255.255.255.255). The subnet-directed 737 broadcast address of the form .<-1> cannot be 738 used since mobile nodes will not generally know the 739 prefix of the foreign network. 741 - ICMP Fields 743 Code The Code field of the agent advertisement is 744 interpreted as follows: 746 0 The mobility agent handles common traffic -- that 747 is, it acts as a router for IP datagrams not 748 necessarily related to mobile nodes. 749 16 The mobility agent does not route common traffic. 750 However, all foreign agents MUST (minimally) 751 forward to a default router any datagrams received 752 from a registered mobile node (Section 4.2.2). 754 Lifetime 755 The maximum length of time that the Advertisement 756 is considered valid in the absence of further 757 Advertisements. 759 Router Address(es) 760 See Section 2.3.1 for a discussion of the addresses 761 that may appear in this portion of the Agent 762 Advertisement. 764 Num Addrs 765 The number of Router Addresses advertised in this 766 message. Note that in an Agent Advertisement 767 message, the number of router addresses specified in 768 the ICMP Router Advertisement portion of the message 769 MAY be set to 0. See Section 2.3.1 for details. 771 If sent periodically, the nominal interval at which Agent 772 Advertisements are sent SHOULD be no longer than 1/3 of the 773 advertisement Lifetime given in the ICMP header. This interval MAY 774 be shorter than 1/3 the advertised Lifetime. This allows a mobile 775 node to miss three successive advertisements before deleting the 776 agent from its list of valid agents. The actual transmission time 777 for each advertisement SHOULD be slightly randomized [7] in order 778 to avoid synchronization and subsequent collisions with other Agent 779 Advertisements that may be sent by other agents (or with other Router 780 Advertisements sent by other routers). Note that this field has no 781 relation to the "Registration Lifetime" field within the Mobility 782 Agent Advertisement Extension defined below. 784 2.1.1. Mobility Agent Advertisement Extension 786 The Mobility Agent Advertisement Extension follows the ICMP Router 787 Advertisement fields. It is used to indicate that an ICMP Router 788 Advertisement message is also an Agent Advertisement being sent by 789 a mobility agent. The Mobility Agent Advertisement Extension is 790 defined as follows: 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type | Length | Sequence Number | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | zero or more Care-of Addresses | 800 | ... | 802 Type 16 804 Length (6 + 4*N), where 6 accounts for the number of bytes in 805 the Sequence Number, Registration Lifetime, flags, and 806 reserved fields, and N is the number of care-of addresses 807 advertised. 809 Sequence Number 810 The count of Agent Advertisement messages sent since the 811 agent was initialized (Section 2.3.2). 813 Registration Lifetime 814 The longest lifetime (measured in seconds) that this 815 agent is willing to accept in any Registration Request. 816 A value of 0xffff indicates infinity. This field has no 817 relation to the "Lifetime" field within the ICMP Router 818 Advertisement portion of the Agent Advertisement. 820 R Registration required. Registration with this foreign 821 agent (or another foreign agent on this link) is required 822 even when using a co-located care-of address. 824 B Busy. The foreign agent will not accept registrations 825 from additional mobile nodes. 827 H Home agent. This agent offers service as a home agent 828 on the link on which this Agent Advertisement message is 829 sent. 831 F Foreign agent. This agent offers service as a foreign 832 agent on the link on which this Agent Advertisement 833 message is sent. 835 M Minimal encapsulation. This agent implements receiving 836 tunneled datagrams that use minimal encapsulation [25]. 838 G GRE encapsulation. This agent implements receiving 839 tunneled datagrams that use GRE encapsulation [13]. 841 r Sent as zero; ignored on reception. SHOULD NOT be 842 allocated for any other uses. 844 T Foreign agent supports reverse tunneling [21]. 846 reserved 847 Sent as zero; ignored on reception. 849 Care-of Address(es) 850 The advertised foreign agent care-of address(es) provided 851 by this foreign agent. An Agent Advertisement MUST 852 include at least one care-of address if the 'F' bit 853 is set. The number of care-of addresses present is 854 determined by the Length field in the Extension. 856 A home agent MUST always be prepared to serve the mobile nodes for 857 which it is the home agent. A foreign agent may at times be too busy 858 to serve additional mobile nodes; even so, it must continue to send 859 Agent Advertisements, so that any mobile nodes already registered 860 with it will know that they have not moved out of range of the 861 foreign agent and that the foreign agent has not failed. A foreign 862 agent may indicate that it is "too busy" to allow new mobile nodes to 863 register with it, by setting the 'B' bit in its Agent Advertisements. 864 An Agent Advertisement message MUST NOT have the 'B' bit set if the 865 'F' bit is not also set, and at least one of the 'F' bit and the 'H' 866 bit MUST be set in any Agent Advertisement message sent. 868 When a foreign agent wishes to require registration even from those 869 mobile nodes which have acquired a co-located care-of address, it 870 sets the 'R' bit to one. Because this bit applies only to foreign 871 agents, an agent MUST NOT set the 'R' bit to one unless the 'F' bit 872 is also set to one. 874 2.1.2. Prefix-Lengths Extension 876 The Prefix-Lengths Extension MAY follow the Mobility Agent 877 Advertisement Extension. It is used to indicate the number of bits 878 of network prefix that applies to each Router Address listed in the 879 ICMP Router Advertisement portion of the Agent Advertisement. Note 880 that the prefix lengths given DO NOT apply to care-of address(es) 881 listed in the Mobility Agent Advertisement Extension. The 882 Prefix-Lengths Extension is defined as follows: 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Type | Length | Prefix Length | .... 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Type 19 (Prefix-Lengths Extension) 892 Length N, where N is the value (possibly zero) of the Num Addrs 893 field in the ICMP Router Advertisement portion of the 894 Agent Advertisement. 896 Prefix Length(s) 897 The number of leading bits that define the network number 898 of the corresponding Router Address listed in the ICMP 899 Router Advertisement portion of the message. The prefix 900 length for each Router Address is encoded as a separate 901 byte, in the order that the Router Addresses are listed 902 in the ICMP Router Advertisement portion of the message. 904 See Section 2.4.2 for information about how the Prefix-Lengths 905 Extension MAY be used by a mobile node when determining whether it 906 has moved. See Appendix E for implementation details about the use 907 of this Extension. 909 2.1.3. One-byte Padding Extension 911 Some IP protocol implementations insist upon padding ICMP messages 912 to an even number of bytes. If the ICMP length of an Agent 913 Advertisement is odd, this Extension MAY be included in order to make 914 the ICMP length even. Note that this Extension is NOT intended to 915 be a general-purpose Extension to be included in order to word- or 916 long-align the various fields of the Agent Advertisement. An Agent 917 Advertisement SHOULD NOT include more than one One-byte Padding 918 Extension and if present, this Extension SHOULD be the last Extension 919 in the Agent Advertisement. 921 Note that unlike other Extensions used in Mobile IP, the One-byte 922 Padding Extension is encoded as a single byte, with no "Length" nor 923 "Data" field present. The One-byte Padding Extension is defined as 924 follows: 926 0 1 2 3 4 5 6 7 927 +-+-+-+-+-+-+-+-+ 928 | Type | 929 +-+-+-+-+-+-+-+-+ 931 Type 0 (One-byte Padding Extension) 933 2.2. Agent Solicitation 935 An Agent Solicitation is identical to an ICMP Router Solicitation 936 with the further restriction that the IP TTL Field MUST be set to 1. 938 2.3. Foreign Agent and Home Agent Considerations 940 Any mobility agent which cannot be discovered by a link-layer 941 protocol MUST send Agent Advertisements. An agent which can be 942 discovered by a link-layer protocol SHOULD also implement Agent 943 Advertisements. However, the Advertisements need not be sent, 944 except when the site policy requires registration with the agent 945 (i.e., when the 'R' bit is set), or as a response to a specific 946 Agent Solicitation. All mobility agents SHOULD respond to Agent 947 Solicitations. 949 The same procedures, defaults, and constants are used in Agent 950 Advertisement messages and Agent Solicitation messages as specified 951 for ICMP Router Discovery [7], except that: 953 - a mobility agent MUST limit the rate at which it sends broadcast 954 or multicast Agent Advertisements; the maximum rate SHOULD be 955 chosen so that the Advertisements do not consume a significant 956 amount of network bandwidth, AND 958 - a mobility agent that receives a Router Solicitation MUST NOT 959 require that the IP Source Address is the address of a neighbor 960 (i.e., an address that matches one of the router's own addresses 961 on the arrival interface, under the subnet mask associated with 962 that address of the router). 964 - a mobility agent MAY be configured to send Agent Advertisements 965 only in response to an Agent Solicitation message. 967 If the home network is not a virtual network, then the home agent 968 for any mobile node SHOULD be located on the link identified by the 969 mobile node's home address, and Agent Advertisement messages sent by 970 the home agent on this link MUST have the 'H' bit set. In this way, 971 mobile nodes on their own home network will be able to determine that 972 they are indeed at home. Any Agent Advertisement messages sent by 973 the home agent on another link to which it may be attached (if it is 974 a mobility agent serving more than one link), MUST NOT have the 'H' 975 bit set, unless the home agent also serves as a home agent (to other 976 mobile nodes) on that other link. A mobility agent MAY use different 977 settings for each of the 'R', 'H', and 'F' bits on different network 978 interfaces. 980 If the home network is a virtual network, the home network has no 981 physical realization external to the home agent itself. In this 982 case, there is no physical network link on which to send Agent 983 Advertisement messages advertising the home agent. Mobile nodes for 984 which this is the home network are always treated as being away from 985 home. 987 On a particular subnet, either all mobility agents MUST include 988 the Prefix-Lengths Extension or all of them MUST NOT include this 989 Extension. Equivalently, it is prohibited for some agents on a given 990 subnet to include the Extension but for others not to include it. 991 Otherwise, one of the move detection algorithms designed for mobile 992 nodes will not function properly (Section 2.4.2). 994 2.3.1. Advertised Router Addresses 996 The ICMP Router Advertisement portion of the Agent Advertisement MAY 997 contain one or more router addresses. An agent SHOULD only put its 998 own addresses, if any, in the advertisement. Whether or not its own 999 address appears in the Router Addresses, a foreign agent MUST route 1000 datagrams it receives from registered mobile nodes (Section 4.2.2). 1002 2.3.2. Sequence Numbers and Rollover Handling 1004 The sequence number in Agent Advertisements ranges from 0 to 1005 0xffff. After booting, an agent MUST use the number 0 for its first 1006 advertisement. Each subsequent advertisement MUST use the sequence 1007 number one greater, with the exception that the sequence number 1008 0xffff MUST be followed by sequence number 256. In this way, mobile 1009 nodes can distinguish reductions in sequence numbers that result from 1010 reboots, from reductions that result in rollover of the sequence 1011 number after it attains the value 0xffff. 1013 2.4. Mobile Node Considerations 1015 Every mobile node MUST implement Agent Solicitation. Solicitations 1016 SHOULD only be sent in the absence of Agent Advertisements and when a 1017 care-of address has not been determined through a link-layer protocol 1018 or other means. The mobile node uses the same procedures, defaults, 1019 and constants for Agent Solicitation as specified for ICMP Router 1020 Solicitation messages [7], except that the mobile node MAY solicit 1021 more often than once every three seconds, and that a mobile node that 1022 is currently not connected to any foreign agent MAY solicit more 1023 times than MAX_SOLICITATIONS. 1025 The rate at which a mobile node sends Solicitations MUST be 1026 limited by the mobile node. The mobile node MAY send three initial 1027 Solicitations at a maximum rate of one per second while searching for 1028 an agent. After this, the rate at which Solicitations are sent MUST 1029 be reduced so as to limit the overhead on the local link. Subsequent 1030 Solicitations MUST be sent using a binary exponential backoff 1031 mechanism, doubling the interval between consecutive Solicitations, 1032 up to a maximum interval. The maximum interval SHOULD be chosen 1033 appropriately based upon the characteristics of the media over which 1034 the mobile node is soliciting. This maximum interval SHOULD be at 1035 least one minute between Solicitations. 1037 While still searching for an agent, the mobile node MUST NOT increase 1038 the rate at which it sends Solicitations unless it has received 1039 a positive indication that it has moved to a new link. After 1040 successfully registering with an agent, the mobile node SHOULD 1041 also increase the rate at which it will send Solicitations when it 1042 next begins searching for a new agent with which to register. The 1043 increased solicitation rate MAY revert to the maximum rate, but then 1044 MUST be limited in the manner described above. In all cases, the 1045 recommended solicitation intervals are nominal values. Mobile nodes 1046 MUST randomize their solicitation times around these nominal values 1047 as specified for ICMP Router Discovery [7]. 1049 Mobile nodes MUST process received Agent Advertisements. A mobile 1050 node can distinguish an Agent Advertisement message from other uses 1051 of the ICMP Router Advertisement message by examining the number 1052 of advertised addresses and the IP Total Length field. When the 1053 IP total length indicates that the ICMP message is longer than 1054 needed for the number of advertised addresses, the remaining data is 1055 interpreted as one or more Extensions. The presence of a Mobility 1056 Agent Advertisement Extension identifies the advertisement as an 1057 Agent Advertisement. 1059 If there is more than one advertised address, the mobile node SHOULD 1060 pick the first address for its initial registration attempt. If the 1061 registration attempt fails with a status Code indicating rejection by 1062 the foreign agent, the mobile node MAY retry the attempt with each 1063 subsequent advertised address in turn. 1065 When multiple methods of agent discovery are in use, the mobile node 1066 SHOULD first attempt registration with agents including Mobility 1067 Agent Advertisement Extensions in their advertisements, in preference 1068 to those discovered by other means. This preference maximizes 1069 the likelihood that the registration will be recognized, thereby 1070 minimizing the number of registration attempts. 1072 A mobile node MUST ignore reserved bits in Agent Advertisements, as 1073 opposed to discarding such advertisements. In this way, new bits 1074 can be defined later, without affecting the ability for mobile nodes 1075 to use the advertisements even when the newly defined bits are not 1076 understood. 1078 2.4.1. Registration Required 1080 When the mobile node receives an Agent Advertisement with the 'R' 1081 bit set, the mobile node SHOULD register through the foreign agent, 1082 even when the mobile node might be able to acquire its own co-located 1083 care-of address. This feature is intended to allow sites to enforce 1084 visiting policies (such as accounting) which require exchanges of 1085 authorization. 1087 If formerly reserved bits require some kind of monitoring/enforcement 1088 at the foreign link, foreign agents implementing the new 1089 specification for the formerly reserved bits can set the 'R' bit. 1090 This has the effect of forcing the mobile node to register through 1091 the foreign agent, so the foreign agent could then monitor/enforce 1092 the policy. 1094 2.4.2. Move Detection 1096 Two primary mechanisms are provided for mobile nodes to detect when 1097 they have moved from one subnet to another. Other mechanisms MAY 1098 also be used. When the mobile node detects that it has moved, it 1099 SHOULD register (Section 3) with a suitable care-of address on the 1100 new foreign network. However, the mobile node MUST NOT register 1101 more frequently than once per second on average, as specified in 1102 Section 3.6.3. 1104 2.4.2.1. Algorithm 1 1106 The first method of move detection is based upon the Lifetime field 1107 within the main body of the ICMP Router Advertisement portion of 1108 the Agent Advertisement. A mobile node SHOULD record the Lifetime 1109 received in any Agent Advertisements, until that Lifetime expires. 1110 If the mobile node fails to receive another advertisement from the 1111 same agent within the specified Lifetime, it SHOULD assume that it 1112 has lost contact with that agent. If the mobile node has previously 1113 received an Agent Advertisement from another agent for which the 1114 Lifetime field has not yet expired, the mobile node MAY immediately 1115 attempt registration with that other agent. Otherwise, the mobile 1116 node SHOULD attempt to discover a new agent with which to register. 1118 2.4.2.2. Algorithm 2 1120 The second method uses network prefixes. The Prefix-Lengths 1121 Extension MAY be used in some cases by a mobile node to determine 1122 whether or not a newly received Agent Advertisement was received on 1123 the same subnet as the mobile node's current care-of address. If the 1124 prefixes differ, the mobile node MAY assume that it has moved. If 1125 a mobile node is currently using a foreign agent care-of address, 1126 the mobile node SHOULD NOT use this method of move detection unless 1127 both the current agent and the new agent include the Prefix-Lengths 1128 Extension in their respective Agent Advertisements; if this Extension 1129 is missing from one or both of the advertisements, this method of 1130 move detection SHOULD NOT be used. Similarly, if a mobile node is 1131 using a co-located care-of address, it SHOULD not use this method 1132 of move detection unless the new agent includes the Prefix-Lengths 1133 Extension in its Advertisement and the mobile node knows the network 1134 prefix of its current co-located care-of address. On the expiration 1135 of its current registration, if this method indicates that the 1136 mobile node has moved, rather than re-registering with its current 1137 care-of address, a mobile node MAY choose instead to register 1138 with a the foreign agent sending the new Advertisement with the 1139 different network prefix. The Agent Advertisement on which the new 1140 registration is based MUST NOT have expired according to its Lifetime 1141 field. 1143 2.4.3. Returning Home 1145 A mobile node can detect that it has returned to its home network 1146 when it receives an Agent Advertisement from its own home agent. If 1147 so, it SHOULD deregister with its home agent (Section 3). Before 1148 attempting to deregister, the mobile node SHOULD configure its 1149 routing table appropriately for its home network (Section 4.2.1). In 1150 addition, if the home network is using ARP [29], the mobile node MUST 1151 follow the procedures described in Section 4.6 with regard to ARP, 1152 proxy ARP, and gratuitous ARP. 1154 2.4.4. Sequence Numbers and Rollover Handling 1156 If a mobile node detects two successive values of the sequence number 1157 in the Agent Advertisements from the foreign agent with which it is 1158 registered, the second of which is less than the first and inside the 1159 range 0 to 255, the mobile node SHOULD register again. If the second 1160 value is less than the first but is greater than or equal to 256, 1161 the mobile node SHOULD assume that the sequence number has rolled 1162 over past its maximum value (0xffff), and that reregistration is not 1163 necessary (Section 2.3). 1165 3. Registration 1167 Mobile IP registration provides a flexible mechanism for mobile nodes 1168 to communicate their current reachability information to their home 1169 agent. It is the method by which mobile nodes: 1171 - request forwarding services when visiting a foreign network, 1173 - inform their home agent of their current care-of address, 1175 - renew a registration which is due to expire, and/or 1177 - deregister when they return home. 1179 Registration messages exchange information between a mobile node, 1180 (optionally) a foreign agent, and the home agent. Registration 1181 creates or modifies a mobility binding at the home agent, associating 1182 the mobile node's home address with its care-of address for the 1183 specified Lifetime. 1185 Several other (optional) capabilities are available through the 1186 registration procedure, which enable a mobile node to: 1188 - discover its home address, if the mobile node is not configured 1189 with this information. 1191 - maintain multiple simultaneous registrations, so that a copy of 1192 each datagram will be tunneled to each active care-of address 1194 - deregister specific care-of addresses while retaining other 1195 mobility bindings, and 1197 - discover the address of a home agent if the mobile node is not 1198 configured with this information. 1200 3.1. Registration Overview 1202 Mobile IP defines two different registration procedures, one via 1203 a foreign agent that relays the registration to the mobile node's 1204 home agent, and one directly with the mobile node's home agent. The 1205 following rules determine which of these two registration procedures 1206 to use in any particular circumstance: 1208 - If a mobile node is registering a foreign agent care-of address, 1209 the mobile node MUST register via that foreign agent. 1211 - If a mobile node is using a co-located care-of address, and 1212 receives an Agent Advertisement from a foreign agent on the 1213 link on which it is using this care-of address, the mobile node 1214 SHOULD register via that foreign agent (or via another foreign 1215 agent on this link) if the 'R' bit is set in the received Agent 1216 Advertisement message. 1218 - If a mobile node is otherwise using a co-located care-of address, 1219 the mobile node MUST register directly with its home agent. 1221 - If a mobile node has returned to its home network and is 1222 (de)registering with its home agent, the mobile node MUST 1223 register directly with its home agent. 1225 Both registration procedures involve the exchange of Registration 1226 Request and Registration Reply messages (Sections 3.3 and 3.4). When 1227 registering via a foreign agent, the registration procedure requires 1228 the following four messages: 1230 a) The mobile node sends a Registration Request to the 1231 prospective foreign agent to begin the registration process. 1233 b) The foreign agent processes the Registration Request and then 1234 relays it to the home agent. 1236 c) The home agent sends a Registration Reply to the foreign 1237 agent to grant or deny the Request. 1239 d) The foreign agent processes the Registration Reply and then 1240 relays it to the mobile node to inform it of the disposition 1241 of its Request. 1243 When the mobile node instead registers directly with its home agent, 1244 the registration procedure requires only the following two messages: 1246 a) The mobile node sends a Registration Request to the home 1247 agent. 1249 b) The home agent sends a Registration Reply to the mobile node, 1250 granting or denying the Request. 1252 The registration messages defined in Sections 3.3 and 3.4 use the 1253 User Datagram Protocol (UDP) [30]. A nonzero UDP checksum SHOULD 1254 be included in the header, and MUST be checked by the recipient. A 1255 zero UDP checksum SHOULD be accepted by the recipient. The behavior 1256 of the mobile node and the home agent with respect to their mutual 1257 acceptance of packets with zero UDP checksums SHOULD be defined as 1258 part of the mobility security association which exists between them. 1260 3.2. Authentication 1262 Each mobile node, foreign agent, and home agent MUST be able to 1263 support a mobility security association for mobile entities, indexed 1264 by their SPI and IP address. In the case of the mobile node, 1265 this must be its Home Address. See Section 5.1 for requirements 1266 for support of authentication algorithms. Registration messages 1267 between a mobile node and its home agent MUST be authenticated 1268 with an authorization-enabling extension, e.g. the Mobile-Home 1269 Authentication Extension (Section 3.5.2). This extension MUST be 1270 the first authentication extension; other foreign agent-specific 1271 extensions MAY be added to the message after the mobile node computes 1272 the authentication. 1274 3.3. Registration Request 1276 A mobile node registers with its home agent using a Registration 1277 Request message so that its home agent can create or modify a 1278 mobility binding for that mobile node (e.g., with a new lifetime). 1279 The Request may be relayed to the home agent by the foreign agent 1280 through which the mobile node is registering, or it may be sent 1281 directly to the home agent in the case in which the mobile node is 1282 registering a co-located care-of address. 1284 IP fields: 1286 Source Address Typically the interface address from which the 1287 message is sent. 1289 Destination Address Typically that of the foreign agent or the 1290 home agent. 1292 See Sections 3.6.1.1 and 3.7.2.2 for details. 1294 UDP fields: 1296 Source Port variable 1298 Destination Port 434 1300 The UDP header is followed by the Mobile IP fields shown below: 1302 0 1 2 3 1303 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 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Type |S|B|D|M|G|r|T|x| Lifetime | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Home Address | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Home Agent | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Care-of Address | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | | 1314 + Identification + 1315 | | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | Extensions ... 1318 +-+-+-+-+-+-+-+- 1320 Type 1 (Registration Request) 1322 S Simultaneous bindings. If the 'S' bit is set, the mobile 1323 node is requesting that the home agent retain its prior 1324 mobility bindings, as described in Section 3.6.1.2. 1326 B Broadcast datagrams. If the 'B' bit is set, the mobile 1327 node requests that the home agent tunnel to it any 1328 broadcast datagrams that it receives on the home network, 1329 as described in Section 4.3. 1331 D Decapsulation by mobile node. If the 'D' bit is set, the 1332 mobile node will itself decapsulate datagrams which are 1333 sent to the care-of address. That is, the mobile node is 1334 using a co-located care-of address. 1336 M Minimal encapsulation. If the 'M' bit is set, the 1337 mobile node requests that its home agent use minimal 1338 encapsulation [25] for datagrams tunneled to the mobile 1339 node. 1341 G GRE encapsulation. If the 'G' bit is set, the 1342 mobile node requests that its home agent use GRE 1343 encapsulation [13] for datagrams tunneled to the mobile 1344 node. 1346 r Sent as zero; ignored on reception. SHOULD NOT be 1347 allocated for any other uses. 1349 T Reverse Tunneling requested; see [21]. 1351 x Sent as zero; ignored on reception. 1353 Lifetime 1354 The number of seconds remaining before the registration 1355 is considered expired. A value of zero indicates a 1356 request for deregistration. A value of 0xffff indicates 1357 infinity. 1359 Home Address 1360 The IP address of the mobile node. 1362 Home Agent 1363 The IP address of the mobile node's home agent. 1365 Care-of Address 1366 The IP address for the end of the tunnel. 1368 Identification 1369 A 64-bit number, constructed by the mobile node, used for 1370 matching Registration Requests with Registration Replies, 1371 and for protecting against replay attacks of registration 1372 messages. See Sections 5.4 and 5.6. 1374 Extensions 1375 The fixed portion of the Registration Request is followed 1376 by one or more of the Extensions listed in Section 3.5. 1377 An authorization-enabling extension MUST be included 1378 in all Registration Requests. See Sections 3.6.1.3 1379 and 3.7.2.2 for information on the relative order in 1380 which different extensions, when present, MUST be placed 1381 in a Registration Request message. 1383 3.4. Registration Reply 1385 A mobility agent returns a Registration Reply message to a mobile 1386 node which has sent a Registration Request (Section 3.3) message. 1387 If the mobile node is requesting service from a foreign agent, 1388 that foreign agent will receive the Reply from the home agent and 1389 subsequently relay it to the mobile node. The Reply message contains 1390 the necessary codes to inform the mobile node about the status of its 1391 Request, along with the lifetime granted by the home agent, which MAY 1392 be smaller than the original Request. 1394 The foreign agent MUST NOT increase the Lifetime selected by the 1395 mobile node in the Registration Request, since the Lifetime is 1396 covered by an authentication extension which enables authorization by 1397 the home agent. Such an extension contains authentication data which 1398 cannot be correctly (re)computed by the foreign agent. The home 1399 agent MUST NOT increase the Lifetime selected by the mobile node in 1400 the Registration Request, since doing so could increase it beyond the 1401 maximum Registration Lifetime allowed by the foreign agent. If the 1402 Lifetime received in the Registration Reply is greater than that in 1403 the Registration Request, the Lifetime in the Request MUST be used. 1404 When the Lifetime received in the Registration Reply is less than 1405 that in the Registration Request, the Lifetime in the Reply MUST be 1406 used. 1408 IP fields: 1410 Source Address Typically copied from the destination 1411 address of the Registration Request to which 1412 the agent is replying. See Sections 3.7.2.3 1413 and 3.8.3.1 for complete details. 1415 Destination Address Copied from the source address of the 1416 Registration Request to which the agent is 1417 replying 1419 UDP fields: 1421 Source Port 1423 Destination Port Copied from the source port of the 1424 corresponding Registration Request 1425 (Section 3.7.1). 1427 The UDP header is followed by the Mobile IP fields shown below: 1429 0 1 2 3 1430 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 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Type | Code | Lifetime | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | Home Address | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Home Agent | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | | 1439 + Identification + 1440 | | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Extensions ... 1443 +-+-+-+-+-+-+-+- 1445 Type 3 (Registration Reply) 1447 Code A value indicating the result of the Registration 1448 Request. See below for a list of currently defined Code 1449 values. 1451 Lifetime 1452 If the Code field indicates that the registration was 1453 accepted, the Lifetime field is set to the number of 1454 seconds remaining before the registration is considered 1455 expired. A value of zero indicates that the mobile node 1456 has been deregistered. A value of 0xffff indicates 1457 infinity. If the Code field indicates that the 1458 registration was denied, the contents of the Lifetime 1459 field are unspecified and MUST be ignored on reception. 1461 Home Address 1462 The IP address of the mobile node. 1464 Home Agent 1465 The IP address of the mobile node's home agent. 1467 Identification 1468 A 64-bit number used for matching Registration Requests 1469 with Registration Replies, and for protecting against 1470 replay attacks of registration messages. The value is 1471 based on the Identification field from the Registration 1472 Request message from the mobile node, and on the style of 1473 replay protection used in the security context between 1474 the mobile node and its home agent (defined by the 1475 mobility security association between them, and SPI 1476 value in the authorization-enabling extension). See 1477 Sections 5.4 and 5.6. 1479 Extensions 1480 The fixed portion of the Registration Reply is followed 1481 by one or more of the Extensions listed in Section 3.5. 1482 An authorization-enabling extension MUST be included in 1483 all Registration Replies returned by the home agent. See 1484 Sections 3.7.2.2 and 3.8.3.3 for rules on placement of 1485 extensions to Reply messages. 1487 The following values are defined for use within the Code field. 1488 Registration successful: 1490 0 registration accepted 1491 1 registration accepted, but simultaneous mobility 1492 bindings unsupported 1494 Registration denied by the foreign agent: 1496 64 reason unspecified 1497 65 administratively prohibited 1498 66 insufficient resources 1499 67 mobile node failed authentication 1500 68 home agent failed authentication 1501 69 requested Lifetime too long 1502 70 poorly formed Request 1503 71 poorly formed Reply 1504 72 requested encapsulation unavailable 1505 73 reserved and unavailable 1506 77 invalid care-of address 1507 78 registration timeout 1508 80 home network unreachable (ICMP error received) 1509 81 home agent host unreachable (ICMP error received) 1510 82 home agent port unreachable (ICMP error received) 1511 88 home agent unreachable (other ICMP error received) 1513 Registration denied by the home agent: 1515 128 reason unspecified 1516 129 administratively prohibited 1517 130 insufficient resources 1518 131 mobile node failed authentication 1519 132 foreign agent failed authentication 1520 133 registration Identification mismatch 1521 134 poorly formed Request 1522 135 too many simultaneous mobility bindings 1523 136 unknown home agent address 1525 Up-to-date values of the Code field are specified in the most recent 1526 "Assigned Numbers" [33]. 1528 3.5. Registration Extensions 1530 3.5.1. Computing Authentication Extension Values 1532 The Authenticator value computed for each authentication Extension 1533 MUST protect the following fields from the registration message: 1535 - the UDP payload (that is, the Registration Request or 1536 Registration Reply data), 1538 - all prior Extensions in their entirety, and 1540 - the Type, Length, and SPI of this Extension. 1542 The default authentication algorithm uses keyed-MD5 [34] in 1543 "prefix+suffix" mode to compute a 128-bit "message digest" of the 1544 registration message. The default authenticator is a 128-bit value 1545 computed as the MD5 checksum over the the following stream of bytes: 1547 - the shared secret defined by the mobility security association 1548 between the nodes and by the SPI value specified in the 1549 authentication Extension, followed by 1551 - the protected fields from the registration message, in the order 1552 specified above, followed by 1554 - the shared secret again. 1556 Note that the Authenticator field itself and the UDP header are NOT 1557 included in the computation of the default Authenticator value. 1558 See Section 5.1 for information about support requirements for 1559 message authentication codes, which are to be used with the various 1560 authentication Extensions. 1562 The Security Parameter Index (SPI) within any of the authentication 1563 Extensions defines the security context which is used to compute 1564 the Authenticator value and which MUST be used by the receiver to 1565 check that value. In particular, the SPI selects the authentication 1566 algorithm and mode (Section 5.1) and secret (a shared key, or 1567 appropriate public/private key pair) used in computing the 1568 Authenticator. In order to ensure interoperability between different 1569 implementations of the Mobile IP protocol, an implementation MUST be 1570 able to associate any SPI value with any authentication algorithm 1571 and mode which it implements. In addition, all implementations 1572 of Mobile IP MUST implement the default authentication algorithm 1573 (keyed-MD5) and mode ("prefix+suffix") defined above. 1575 3.5.2. Mobile-Home Authentication Extension 1577 Exactly one authorization-enabling extension MUST be present in all 1578 Registration Requests, and also in all Registration Replies generated 1579 by the Home Agent. The Mobile-Home Authentication Extension is 1580 always an authorization-enabling for registration messages specified 1581 in this document. This requirement is intended to eliminate 1582 problems [1] which result from the uncontrolled propagation of remote 1583 redirects in the Internet. The location of the extension marks the 1584 end of the authenticated data. 1586 0 1 2 3 1587 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 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Type | Length | SPI .... 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 ... SPI (cont.) | Authenticator ... 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 Type 32 1596 Length 4 plus the number of bytes in the Authenticator. 1598 SPI Security Parameter Index (4 bytes). An opaque 1599 identifier (see Section 1.6). 1601 Authenticator (variable length) (See Section 3.5.1.) 1603 3.5.3. Mobile-Foreign Authentication Extension 1605 This Extension MAY be included in Registration Requests and Replies 1606 in cases in which a mobility security association exists between the 1607 mobile node and the foreign agent. See Section 5.1 for information 1608 about support requirements for message authentication codes. 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Type | Length | SPI .... 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 ... SPI (cont.) | Authenticator ... 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 Type 33 1620 Length 4 plus the number of bytes in the Authenticator. 1622 SPI Security Parameter Index (4 bytes). An opaque 1623 identifier (see Section 1.6). 1625 Authenticator (variable length) (See Section 3.5.1.) 1627 3.5.4. Foreign-Home Authentication Extension 1629 This Extension MAY be included in Registration Requests and Replies 1630 in cases in which a mobility security association exists between the 1631 foreign agent and the home agent. See Section 5.1 for information 1632 about support requirements for message authentication codes. 1634 0 1 2 3 1635 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 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Type | Length | SPI .... 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 ... SPI (cont.) | Authenticator ... 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 Type 34 1644 Length 4 plus the number of bytes in the Authenticator. 1646 SPI Security Parameter Index (4 bytes). An opaque 1647 identifier (see Section 1.6). 1649 Authenticator (variable length) (See Section 3.5.1.) 1651 3.6. Mobile Node Considerations 1653 A mobile node MUST be configured with a netmask and a mobility 1654 security association for its home agents. In addition, a mobile node 1655 MAY be configured with its home address, and the IP address of one or 1656 more of its home agents; otherwise, the mobile node MAY discover a 1657 home agent using the procedures described in Section 3.6.1.2. 1659 If the mobile node is not configured with a home address, it MAY use 1660 the Mobile Node NAI extension [4] to identify itself, and set the 1661 Home Address field of the Registration Request to 0.0.0.0. In this 1662 case, the mobile node MUST be able to assign its home address after 1663 extracting this information from the Registration Reply from the home 1664 agent. 1666 For each pending registration, the mobile node maintains the 1667 following information: 1669 - the link-layer address of the foreign agent to which the 1670 Registration Request was sent, if applicable, 1671 - the IP destination address of the Registration Request, 1672 - the care-of address used in the registration, 1673 - the Identification value sent in the registration, 1674 - the originally requested Lifetime, and 1675 - the remaining Lifetime of the pending registration. 1677 A mobile node SHOULD initiate a registration whenever it detects a 1678 change in its network connectivity. See Section 2.4.2 for methods by 1679 which mobile nodes MAY make such a determination. When it is away 1680 from home, the mobile node's Registration Request allows its home 1681 agent to create or modify a mobility binding for it. When it is at 1682 home, the mobile node's (de)Registration Request allows its home 1683 agent to delete any previous mobility binding(s) for it. A mobile 1684 node operates without the support of mobility functions when it is at 1685 home. 1687 There are other conditions under which the mobile node SHOULD 1688 (re)register with its foreign agent, such as when the mobile 1689 node detects that the foreign agent has rebooted (as specified in 1690 Section 2.4.4) and when the current registration's Lifetime is near 1691 expiration. 1693 In the absence of link-layer indications of changes in point 1694 of attachment, Agent Advertisements from new agents SHOULD NOT 1695 cause a mobile node to attempt a new registration, if its current 1696 registration has not expired and it is still also receiving Agent 1697 Advertisements from the foreign agent with which it is currently 1698 registered. In the absence of link-layer indications, a mobile node 1699 MUST NOT attempt to register more often than once per second. 1701 A mobile node MAY register with a different agent when 1702 transport-layer protocols indicate excessive retransmissions. 1703 A mobile node MUST NOT consider reception of an ICMP Redirect from 1704 a foreign agent that is currently providing service to it as reason 1705 to register with a new foreign agent. Within these constraints, the 1706 mobile node MAY register again at any time. 1708 Appendix D shows some examples of how the fields in registration 1709 messages would be set up in some typical registration scenarios. 1711 3.6.1. Sending Registration Requests 1713 The following sections specify details for the values the mobile node 1714 MUST supply in the fields of Registration Request messages. 1716 3.6.1.1. IP Fields 1718 This section provides the specific rules by which mobile nodes pick 1719 values for the IP header fields of a Registration Request. 1721 IP Source Address: 1723 - When registering on a foreign network with a co-located care-of 1724 address, the IP source address MUST be the care-of address. 1726 - In all other circumstances, the IP source address MUST be the 1727 mobile node's home address. 1729 IP Destination Address: 1731 - When the mobile node has discovered the agent with which it is 1732 registering, through some means (e.g., link-layer) that does not 1733 provide the IP address of the agent (the IP address of the agent 1734 is unknown to the mobile node), then the "All Mobility Agents" 1735 multicast address (224.0.0.11) MUST be used. In this case, the 1736 mobile node MUST use the agent's link-layer unicast address in 1737 order to deliver the datagram to the correct agent. 1739 - When registering with a foreign agent, the address of the agent 1740 as learned from the IP source address of the corresponding Agent 1741 Advertisement MUST be used. In addition, when transmitting 1742 this Registration Request message, the mobile node MUST use a 1743 link-layer destination address copied from the link-layer source 1744 address of the Agent Advertisement message in which it learned 1745 this foreign agent's IP address. 1747 - When the mobile node is registering directly with its home 1748 agent and knows the (unicast) IP address of its home agent, the 1749 destination address MUST be set to this address. 1751 - If the mobile node is registering directly with its home 1752 agent, but does not know the IP address of its home agent, 1753 the mobile node may use dynamic home agent address resolution 1754 to automatically determine the IP address of its home agent 1755 (Section 3.6.1.2). In this case, the IP destination address is 1756 set to the subnet-directed broadcast address of the mobile node's 1757 home network. This address MUST NOT be used as the destination 1758 IP address if the mobile node is registering via a foreign agent, 1759 although it MAY be used as the Home Agent address in the body of 1760 the Registration Request when registering via a foreign agent. 1762 IP Time to Live: 1764 - The IP TTL field MUST be set to 1 if the IP destination address 1765 is set to the "All Mobility Agents" multicast address as 1766 described above. Otherwise a suitable value should be chosen in 1767 accordance with standard IP practice [31]. 1769 3.6.1.2. Registration Request Fields 1771 This section provides specific rules by which mobile nodes pick 1772 values for the fields within the fixed portion of a Registration 1773 Request. 1775 A mobile node MAY set the 'S' bit in order to request that the 1776 home agent maintain prior mobility binding(s). Otherwise, the 1777 home agent deletes any previous binding(s) and replaces them with 1778 the new binding specified in the Registration Request. Multiple 1779 simultaneous mobility bindings are likely to be useful when a mobile 1780 node using at least one wireless network interface moves within 1781 wireless transmission range of more than one foreign agent. IP 1782 explicitly allows duplication of datagrams. When the home agent 1783 allows simultaneous bindings, it will tunnel a separate copy of each 1784 arriving datagram to each care-of address, and the mobile node will 1785 receive multiple copies of datagrams destined to it. 1787 The mobile node SHOULD set the 'D' bit if it is registering with a 1788 co-located care-of address. Otherwise, the 'D' bit MUST NOT be set. 1790 A mobile node MAY set the 'B' bit to request its home agent to 1791 forward to it, a copy of broadcast datagrams received by its home 1792 agent from the home network. The method used by the home agent to 1793 forward broadcast datagrams depends on the type of care-of address 1794 registered by the mobile node, as determined by the 'D' bit in the 1795 mobile node's Registration Request: 1797 - If the 'D' bit is set, then the mobile node has indicated that it 1798 will decapsulate any datagrams tunneled to this care-of address 1799 itself (the mobile node is using a co-located care-of address). 1800 In this case, to forward such a received broadcast datagram to 1801 the mobile node, the home agent MUST tunnel it to this care-of 1802 address. The mobile node de-tunnels the received datagram in the 1803 same way as any other datagram tunneled directly to it. 1805 - If the 'D' bit is NOT set, then the mobile node has indicated 1806 that it is using a foreign agent care-of address, and that the 1807 foreign agent will thus decapsulate arriving datagrams before 1808 forwarding them to the mobile node. In this case, to forward 1809 such a received broadcast datagram to the mobile node, the home 1810 agent MUST first encapsulate the broadcast datagram in a unicast 1811 datagram addressed to the mobile node's home address, and then 1812 MUST tunnel this resulting datagram to the mobile node's care-of 1813 address. 1815 When decapsulated by the foreign agent, the inner datagram will 1816 thus be a unicast IP datagram addressed to the mobile node, 1817 identifying to the foreign agent the intended destination of the 1818 encapsulated broadcast datagram, and will be delivered to the 1819 mobile node in the same way as any tunneled datagram arriving 1820 for the mobile node. The foreign agent MUST NOT decapsulate the 1821 encapsulated broadcast datagram and MUST NOT use a local network 1822 broadcast to transmit it to the mobile node. The mobile node 1823 thus MUST decapsulate the encapsulated broadcast datagram itself, 1824 and thus MUST NOT set the 'B' bit in its Registration Request in 1825 this case unless it is capable of decapsulating datagrams. 1827 The mobile node MAY request alternative forms of encapsulation by 1828 setting the 'M' bit and/or the 'G' bit, but only if the mobile node 1829 is decapsulating its own datagrams (the mobile node is using a 1830 co-located care-of address) or if its foreign agent has indicated 1831 support for these forms of encapsulation by setting the corresponding 1832 bits in the Mobility Agent Advertisement Extension of an Agent 1833 Advertisement received by the mobile node. Otherwise, the mobile 1834 node MUST NOT set these bits. 1836 The Lifetime field is chosen as follows: 1838 - If the mobile node is registering with a foreign agent, the 1839 Lifetime SHOULD NOT exceed the value in the Registration Lifetime 1840 field of the Agent Advertisement message received from the 1841 foreign agent. When the method by which the care-of address is 1842 learned does not include a Lifetime, the default ICMP Router 1843 Advertisement Lifetime (1800 seconds) MAY be used. 1845 - The mobile node MAY ask a home agent to delete a particular 1846 mobility binding, by sending a Registration Request with the 1847 care-of address for this binding, with the Lifetime field set to 1848 zero (Section 3.8.2). 1850 - Similarly, a Lifetime of zero is used when the mobile node 1851 deregisters all care-of addresses, such as upon returning home. 1853 The Home Address field MUST be set to the mobile node's home address, 1854 if it knows this information. Otherwise, the Home Address MUST be 1855 set to zeroes. 1857 The Home Agent field MUST be set to the address of the mobile node's 1858 home agent, if the mobile node knows this address. Otherwise, the 1859 mobile node MAY use dynamic home agent address resolution to learn 1860 the address of its home agent. In this case, the mobile node MUST 1861 set the Home Agent field to the subnet-directed broadcast address 1862 of the mobile node's home network. Each home agent receiving such 1863 a Registration Request with a broadcast destination address MUST 1864 reject the mobile node's registration and SHOULD return a rejection 1865 Registration Reply indicating its unicast IP address for use by the 1866 mobile node in a future registration attempt. 1868 The Care-of Address field MUST be set to the value of the particular 1869 care-of address that the mobile node wishes to (de)register. In the 1870 special case in which a mobile node wishes to deregister all care-of 1871 addresses, it MUST set this field to its home address. 1873 The mobile node chooses the Identification field in accordance with 1874 the style of replay protection it uses with its home agent. This is 1875 part of the mobility security association the mobile node shares with 1876 its home agent. See Section 5.6 for the method by which the mobile 1877 node computes the Identification field. 1879 3.6.1.3. Extensions 1881 This section describes the ordering of any mandatory and any optional 1882 Extensions that a mobile node appends to a Registration Request. 1883 This following ordering MUST be followed: 1885 a) The IP header, followed by the UDP header, followed by the 1886 fixed-length portion of the Registration Request, followed by 1888 b) If present, any non-authentication Extensions expected to be 1889 used by the home agent (which may or may not also be useful 1890 to the foreign agent), followed by 1892 c) An authorization-enabling extension, followed by 1894 d) If present, any non-authentication Extensions used only by 1895 the foreign agent, followed by 1897 e) The Mobile-Foreign Authentication Extension, if present. 1899 Note that items (a) and (c) MUST appear in every Registration Request 1900 sent by the mobile node. Items (b), (d), and (e) are optional. 1901 However, item (e) MUST be included when the mobile node and the 1902 foreign agent share a mobility security association. 1904 3.6.2. Receiving Registration Replies 1906 Registration Replies will be received by the mobile node in response 1907 to its Registration Requests. Registration Replies generally fall 1908 into three categories: 1910 - the registration was accepted, 1911 - the registration was denied by the foreign agent, or 1912 - the registration was denied by the home agent. 1914 The remainder of this section describes the Registration Reply 1915 handling by a mobile node in each of these three categories. 1917 3.6.2.1. Validity Checks 1919 Registration Replies with an invalid, non-zero UDP checksum MUST be 1920 silently discarded. 1922 In addition, the low-order 32 bits of the Identification field in the 1923 Registration Reply MUST be compared to the low-order 32 bits of the 1924 Identification field in the most recent Registration Request sent to 1925 the replying agent. If they do not match, the Reply MUST be silently 1926 discarded. 1928 Also, the Registration Reply MUST be checked for presence of an 1929 authorization-enabling extension. For all Registration Reply 1930 messages containing a Status Code indicating status from the 1931 Home Agent, the mobile node MUST check for the presence of an 1932 authorization-enabling extension, acting in accordance with the Code 1933 field in the Reply. The rules are as follows: 1935 a) If the mobile node and the foreign agent share a 1936 mobility security association, exactly one Mobile-Foreign 1937 Authentication Extension MUST be present in the Registration 1938 Reply, and the mobile node MUST check the Authenticator 1939 value in the Extension. If no Mobile-Foreign Authentication 1940 Extension is found, or if more than one Mobile-Foreign 1941 Authentication Extension is found, or if the Authenticator is 1942 invalid, the mobile node MUST silently discard the Reply and 1943 SHOULD log the event as a security exception. 1945 b) If the Code field indicates that service is denied by 1946 the home agent, or if the Code field indicates that the 1947 registration was accepted by the home agent, exactly one 1948 Mobile-Home Authentication Extension MUST be present in 1949 the Registration Reply, and the mobile node MUST check the 1950 Authenticator value in the Extension. If the Registration 1951 Reply was generated by the home agent but no Mobile-Home 1952 Authentication Extension is found, or if more than one 1953 Mobile-Home Authentication Extension is found, or if the 1954 Authenticator is invalid, the mobile node MUST silently 1955 discard the Reply and SHOULD log the event as a security 1956 exception. 1958 If the Code field indicates an authentication failure, either at the 1959 foreign agent or the home agent, then it is quite possible that any 1960 authenticators in the Registration Reply will also be in error. This 1961 could happen, for example, if the shared secret between the mobile 1962 node and home agent was erroneously configured. The mobile node 1963 SHOULD log such errors as security exceptions. 1965 3.6.2.2. Registration Request Accepted 1967 If the Code field indicates that the request has been accepted, the 1968 mobile node SHOULD configure its routing table appropriately for its 1969 current point of attachment (Section 4.2.1). 1971 If the mobile node is returning to its home network and that 1972 network is one which implements ARP, the mobile node MUST follow the 1973 procedures described in Section 4.6 with regard to ARP, proxy ARP, 1974 and gratuitous ARP. 1976 If the mobile node has registered on a foreign network, it 1977 SHOULD re-register before the expiration of the Lifetime of its 1978 registration. As described in Section 3.6, for each pending 1979 Registration Request, the mobile node MUST maintain the remaining 1980 lifetime of this pending registration, as well as the original 1981 Lifetime from the Registration Request. When the mobile node 1982 receives a valid Registration Reply, the mobile node MUST decrease 1983 its view of the remaining lifetime of the registration by the amount 1984 by which the home agent decreased the originally requested Lifetime. 1985 This procedure is equivalent to the mobile node starting a timer for 1986 the granted Lifetime at the time it sent the Registration Request, 1987 even though the granted Lifetime is not known to the mobile node 1988 until the Registration Reply is received. Since the Registration 1989 Request is certainly sent before the home agent begins timing the 1990 registration Lifetime (also based on the granted Lifetime), this 1991 procedure ensures that the mobile node will re-register before the 1992 home agent expires and deletes the registration, in spite of possibly 1993 non-negligible transmission delays for the original Registration 1994 Request and Reply that started the timing of the Lifetime at the 1995 mobile node and its home agent. 1997 3.6.2.3. Registration Request Denied 1999 If the Code field indicates that service is being denied, the mobile 2000 node SHOULD log the error. In certain cases the mobile node may be 2001 able to "repair" the error. These include: 2003 Code 69: (Denied by foreign agent, Lifetime too long) 2005 In this case, the Lifetime field in the Registration Reply will 2006 contain the maximum Lifetime value which that foreign agent is 2007 willing to accept in any Registration Request. The mobile node 2008 MAY attempt to register with this same agent, using a Lifetime 2009 in the Registration Request that MUST be less than or equal to 2010 the value specified in the Reply. 2012 Code 133: (Denied by home agent, Identification mismatch) 2014 In this case, the Identification field in the Registration 2015 Reply will contain a value that allows the mobile node to 2016 synchronize with the home agent, based upon the style of replay 2017 protection in effect (Section 5.6). The mobile node MUST 2018 adjust the parameters it uses to compute the Identification 2019 field based upon the information in the Registration Reply, 2020 before issuing any future Registration Requests. 2022 Code 136: (Denied by home agent, Unknown home agent address) 2024 This code is returned by a home agent when the mobile node is 2025 performing dynamic home agent address resolution as described 2026 in Sections 3.6.1.1 and 3.6.1.2. In this case, the Home Agent 2027 field within the Reply will contain the unicast IP address of 2028 the home agent returning the Reply. The mobile node MAY then 2029 attempt to register with this home agent in future Registration 2030 Requests. In addition, the mobile node SHOULD adjust the 2031 parameters it uses to compute the Identification field based 2032 upon the corresponding field in the Registration Reply, before 2033 issuing any future Registration Requests. 2035 3.6.3. Registration Retransmission 2037 When no Registration Reply has been received within a reasonable 2038 time, another Registration Request MAY be transmitted. When 2039 timestamps are used, a new registration Identification is chosen for 2040 each retransmission; thus it counts as a new registration. When 2041 nonces are used, the unanswered Request is retransmitted unchanged; 2042 thus the retransmission does not count as a new registration 2043 (Section 5.6). In this way a retransmission will not require the 2044 home agent to resynchronize with the mobile node by issuing another 2045 nonce in the case in which the original Registration Request (rather 2046 than its Registration Reply) was lost by the network. 2048 The maximum time until a new Registration Request is sent SHOULD be 2049 no greater than the requested Lifetime of the Registration Request. 2050 The minimum value SHOULD be large enough to account for the size 2051 of the messages, twice the round trip time for transmission to the 2052 home agent, and at least an additional 100 milliseconds to allow for 2053 processing the messages before responding. The round trip time for 2054 transmission to the home agent will be at least as large as the time 2055 required to transmit the messages at the link speed of the mobile 2056 node's current point of attachment. Some circuits add another 200 2057 milliseconds of satellite delay in the total round trip time to the 2058 home agent. The minimum time between Registration Requests MUST NOT 2059 be less than 1 second. Each successive retransmission timeout period 2060 SHOULD be at least twice the previous period, as long as that is less 2061 than the maximum as specified above. 2063 3.7. Foreign Agent Considerations 2065 The foreign agent plays a mostly passive role in Mobile IP 2066 registration. It relays Registration Requests between mobile 2067 nodes and home agents, and, when it provides the care-of address, 2068 decapsulates datagrams for delivery to the mobile node. It SHOULD 2069 also send periodic Agent Advertisement messages to advertise its 2070 presence as described in Section 2.3, if not detectable by link-layer 2071 means. 2073 A foreign agent MUST NOT transmit a Registration Request except when 2074 relaying a Registration Request received from a mobile node, to 2075 the mobile node's home agent. A foreign agent MUST NOT transmit a 2076 Registration Reply except when relaying a Registration Reply received 2077 from a mobile node's home agent, or when replying to a Registration 2078 Request received from a mobile node in the case in which the foreign 2079 agent is denying service to the mobile node. In particular, a 2080 foreign agent MUST NOT generate a Registration Request or Reply 2081 because a mobile node's registration Lifetime has expired. A foreign 2082 agent also MUST NOT originate a Registration Request message that 2083 asks for deregistration of a mobile node; however, it MUST relay 2084 valid (de)Registration Requests originated by a mobile node. 2086 3.7.1. Configuration and Registration Tables 2088 Each foreign agent MUST be configured with a care-of address. In 2089 addition, for each pending or current registration the foreign 2090 agent MUST maintain a visitor list entry containing the following 2091 information obtained from the mobile node's Registration Request: 2093 - the link-layer source address of the mobile node 2094 - the IP Source Address (the mobile node's Home Address) or its 2095 co-located care-of address (see description of the 'R' bit in 2096 section 2.1.1) 2097 - the IP Destination Address (as specified in 3.6.2.3) 2098 - the UDP Source Port 2099 - the Home Agent address 2100 - the Identification field 2101 - the requested registration Lifetime, and 2102 - the remaining Lifetime of the pending or current registration. 2104 If the mobile node's Home Address is zero in the Registration Request 2105 message, then the foreign agent MUST follow the procedures specified 2106 in RFC 2794 [4]. In particular, if the foreign agent cannot manage 2107 pending registration request records with such a zero Home Address 2108 for the mobile node, the foreign agent MUST return a Registration 2109 Reply with Code indicating NONZERO_HOMEADDR_REQD (see [4]). 2111 The foreign agent MAY configure a maximum number of pending 2112 registrations that it is willing to maintain (typically 5). 2113 Additional registrations SHOULD then be rejected by the foreign agent 2114 with code 66. The foreign agent MAY delete any pending Registration 2115 Request after the request has been pending for more than 7 seconds; 2116 in this case, the foreign agent SHOULD reject the Request with code 2117 78 (registration timeout). 2119 As with any node on the Internet, a foreign agent MAY also share 2120 mobility security associations with any other nodes. When relaying 2121 a Registration Request from a mobile node to its home agent, if the 2122 foreign agent shares a mobility security association with the home 2123 agent, it MUST add a Foreign-Home Authentication Extension to the 2124 Request and MUST check the required Foreign-Home Authentication 2125 Extension in the Registration Reply from the home agent (Sections 3.3 2126 and 3.4). Similarly, when receiving a Registration Request from 2127 a mobile node, if the foreign agent shares a mobility security 2128 association with the mobile node, it MUST check the required 2129 Mobile-Foreign Authentication Extension in the Request and MUST add a 2130 Mobile-Foreign Authentication Extension to the Registration Reply to 2131 the mobile node. 2133 3.7.2. Receiving Registration Requests 2135 If the foreign agent accepts a Registration Request from a mobile 2136 node, it checks to make sure that the indicated home agent address 2137 does not belong to any network interface of the foreign agent. If 2138 not, the foreign agent then MUST relay the Request to the indicated 2139 home agent. Otherwise, if the foreign agent denies the Request, it 2140 MUST send a Registration Reply to the mobile node with an appropriate 2141 denial Code, except in cases where the foreign agent would be 2142 required to send out more than one such denial per second to the same 2143 mobile node. The following sections describe this behavior in more 2144 detail. 2146 If the foreign agent has configured one of its network interfaces 2147 with the IP address specified by the mobile node as its home agent 2148 address, the foreign agent MUST NOT forward the request again. If 2149 the foreign agent serves the mobile node as a home agent, the foreign 2150 agent follows the procedures specified in section 3.8.2. Otherwise, 2151 if the foreign agent does not serve the mobile node as a home agent, 2152 the foreign agent rejects the Registration Request with code 136 2153 (unknown home agent address). 2155 If a foreign agent receives a Registration Request from a mobile 2156 node in its visitor list, the existing visitor list entry for the 2157 mobile node SHOULD NOT be deleted or modified until the foreign 2158 agent receives a valid Registration Reply from the home agent with 2159 a Code indicating success. The foreign agent MUST record the new 2160 pending Request as a separate part of the existing visitor list 2161 entry for the mobile node. If the Registration Request requests 2162 deregistration, the existing visitor list entry for the mobile 2163 node SHOULD NOT be deleted until the foreign agent has received a 2164 successful Registration Reply. If the Registration Reply indicates 2165 that the Request (for registration or deregistration) was denied by 2166 the home agent, the existing visitor list entry for the mobile node 2167 MUST NOT be modified as a result of receiving the Registration Reply. 2169 3.7.2.1. Validity Checks 2171 Registration Requests with an invalid, non-zero UDP checksum MUST be 2172 silently discarded. Requests with non-zero bits in reserved fields 2173 MUST be rejected with code 70 (poorly formed request). Requests with 2174 the 'D' bit set to 0, and specifying a care-of address not offered 2175 by the foreign agent, MUST be rejected with code 77 (invalid care-of 2176 address). 2178 Also, the authentication in the Registration Request MUST be checked. 2179 If the foreign agent and the mobile node share a mobility security 2180 association, exactly one Mobile-Foreign Authentication Extension MUST 2181 be present in the Registration Request, and the foreign agent MUST 2182 check the Authenticator value in the Extension. If no Mobile-Foreign 2183 Authentication Extension is found, or if more than one Mobile-Foreign 2184 Authentication Extension is found, or if the Authenticator is 2185 invalid, the foreign agent MUST silently discard the Request and 2186 SHOULD log the event as a security exception. The foreign agent also 2187 SHOULD send a Registration Reply to the mobile node with Code 67. 2189 3.7.2.2. Forwarding a Valid Request to the Home Agent 2191 If the foreign agent accepts the mobile node's Registration Request, 2192 it MUST relay the Request to the mobile node's home agent as 2193 specified in the Home Agent field of the Registration Request. The 2194 foreign agent MUST NOT modify any of the fields beginning with the 2195 fixed portion of the Registration Request up through and including 2196 the Mobile-Home Authentication Extension or other authentication 2197 extension supplied by the mobile node as an authorization-enabling 2198 extension for the home agent. Otherwise, an authentication failure 2199 is very likely to occur at the home agent. In addition, the foreign 2200 agent proceeds as follows: 2202 - It MUST process and remove any Extensions following the 2203 Mobile-Home Authentication Extension, 2204 - It MAY append any of its own non-authentication Extensions of 2205 relevance to the home agent, if applicable, and 2206 - It MUST append the Foreign-Home Authentication Extension, if the 2207 foreign agent shares a mobility security association with the home 2208 agent. 2210 Specific fields within the IP header and the UDP header of the 2211 relayed Registration Request MUST be set as follows: 2213 IP Source Address 2214 The foreign agent's address on the interface from which 2215 the message will be sent. 2217 IP Destination Address 2218 Copied from the Home Agent field within the Registration 2219 Request. 2221 UDP Source Port 2222 2224 UDP Destination Port 2225 434 2227 After forwarding a valid Registration Request to the home agent, the 2228 foreign agent MUST begin timing the remaining lifetime of the pending 2229 registration based on the Lifetime in the Registration Request. If 2230 this lifetime expires before receiving a valid Registration Reply, 2231 the foreign agent MUST delete its visitor list entry for this pending 2232 registration. 2234 3.7.2.3. Denying Invalid Requests 2236 If the foreign agent denies the mobile node's Registration Request 2237 for any reason, it SHOULD send the mobile node a Registration Reply 2238 with a suitable denial Code. In such a case, the Home Address, Home 2239 Agent, and Identification fields within the Registration Reply are 2240 copied from the corresponding fields of the Registration Request. 2242 If the Reserved field is nonzero, the foreign agent MUST deny the 2243 Request and SHOULD return a Registration Reply with status code 70 2244 to the mobile node. If the Request is being denied because the 2245 requested Lifetime is too long, the foreign agent sets the Lifetime 2246 in the Reply to the maximum Lifetime value it is willing to accept in 2247 any Registration Request, and sets the Code field to 69. Otherwise, 2248 the Lifetime SHOULD be copied from the Lifetime field in the Request. 2250 Specific fields within the IP header and the UDP header of the 2251 Registration Reply MUST be set as follows: 2253 IP Source Address 2254 Copied from the IP Destination Address of Registration 2255 Request, unless the "All Agents Multicast" address was 2256 used. In this case, the foreign agent's address (on the 2257 interface from which the message will be sent) MUST be 2258 used. 2260 IP Destination Address 2261 Copied from the IP Source Address of the Registration 2262 Request. 2264 UDP Source Port 2265 434 2267 UDP Destination Port 2268 Copied from the UDP Source Port of the Registration 2269 Request. 2271 3.7.3. Receiving Registration Replies 2273 The foreign agent updates its visitor list when it receives a 2274 valid Registration Reply from a home agent. It then relays the 2275 Registration Reply to the mobile node. The following sections 2276 describe this behavior in more detail. 2278 If upon relaying a Registration Request to a home agent, the foreign 2279 agent receives an ICMP error message instead of a Registration Reply, 2280 then the foreign agent SHOULD send to the mobile node a Registration 2281 Reply with an appropriate "Home Agent Unreachable" failure Code 2282 (within the range 80-95, inclusive). See Section 3.7.2.3 for details 2283 on building the Registration Reply. 2285 3.7.3.1. Validity Checks 2287 Registration Replies with an invalid, non-zero UDP checksum MUST be 2288 silently discarded. 2290 When a foreign agent receives a Registration Reply message, it MUST 2291 search its visitor list for a pending Registration Request with the 2292 same mobile node home address as indicated in the Reply. If no 2293 such pending Request is found, and if the Registration Reply does 2294 not correspond with any pending Registration Request with a zero 2295 mobile node home address (see section 3.7.1), the foreign agent MUST 2296 silently discard the Reply. The foreign agent MUST also silently 2297 discard the Reply if the low-order 32 bits of the Identification 2298 field in the Reply do not match those in the Request. 2300 Also, the authentication in the Registration Reply MUST be checked. 2301 If the foreign agent and the home agent share a mobility security 2302 association, exactly one Foreign-Home Authentication Extension MUST 2303 be present in the Registration Reply, and the foreign agent MUST 2304 check the Authenticator value in the Extension. If no Foreign-Home 2305 Authentication Extension is found, or if more than one Foreign-Home 2306 Authentication Extension is found, or if the Authenticator is 2307 invalid, the foreign agent MUST silently discard the Reply and SHOULD 2308 log the event as a security exception. The foreign agent also MUST 2309 reject the mobile node's registration and SHOULD send a Registration 2310 Reply to the mobile node with Code 68. 2312 3.7.3.2. Forwarding Replies to the Mobile Node 2314 A Registration Reply which satisfies the validity checks of 2315 Section 3.8.2.1 is relayed to the mobile node. The foreign agent 2316 MUST also update its visitor list entry for the mobile node to 2317 reflect the results of the Registration Request, as indicated by the 2318 Code field in the Reply. If the Code indicates that the home agent 2319 has accepted the registration and the Lifetime field is nonzero, the 2320 foreign agent SHOULD set the Lifetime in the visitor list entry to 2321 the minumum of the following two values: 2323 - the value specified in the Lifetime field of the Registration 2324 Reply, and 2326 - the foreign agent's own maximum value for allowable registration 2327 lifetime. 2329 If, instead, the Code indicates that the Lifetime field is zero, 2330 the foreign agent MUST delete its visitor list entry for the mobile 2331 node. Finally, if the Code indicates that the registration was 2332 denied by the home agent, the foreign agent MUST delete its pending 2333 registration list entry, but not its visitor list entry, for the 2334 mobile node. 2336 The foreign agent MUST NOT modify any of the fields beginning 2337 with the fixed portion of the Registration Reply up through and 2338 including the Mobile-Home Authentication Extension. Otherwise, 2339 an authentication failure is very likely to occur at the mobile 2340 node. In addition, the foreign agent SHOULD perform the following 2341 additional procedures: 2343 - It MUST process and remove any Extensions following the 2344 Mobile-Home Authentication Extension, 2345 - It MAY append its own non-authentication Extensions of relevance 2346 to the mobile node, if applicable, and 2347 - It MUST append the Mobile-Foreign Authentication Extension, if 2348 the foreign agent shares a mobility security association with the 2349 mobile node. 2351 Specific fields within the IP header and the UDP header of the 2352 relayed Registration Reply are set according to the same rules 2353 specified in Section 3.7.2.3. 2355 After forwarding a valid Registration Reply to the mobile node, 2356 the foreign agent MUST update its visitor list entry for this 2357 registration as follows. If the Registration Reply indicates that 2358 the registration was accepted by the home agent, the foreign agent 2359 resets its timer of the lifetime of the registration to the Lifetime 2360 granted in the Registration Reply; unlike the mobile node's timing 2361 of the registration lifetime as described in Section 3.6.2.2, the 2362 foreign agent considers this lifetime to begin when it forwards the 2363 Registration Reply message, ensuring that the foreign agent will not 2364 expire the registration before the mobile node does. On the other 2365 hand, if the Registration Reply indicates that the registration was 2366 rejected by the home agent, the foreign agent deletes its visitor 2367 list entry for this attempted registration. 2369 3.8. Home Agent Considerations 2371 Home agents play a reactive role in the registration process. The 2372 home agent receives Registration Requests from the mobile node 2373 (perhaps relayed by a foreign agent), updates its record of the 2374 mobility bindings for this mobile node, and issues a suitable 2375 Registration Reply in response to each. 2377 A home agent MUST NOT transmit a Registration Reply except when 2378 replying to a Registration Request received from a mobile node. In 2379 particular, the home agent MUST NOT generate a Registration Reply to 2380 indicate that the Lifetime has expired. 2382 3.8.1. Configuration and Registration Tables 2384 Each home agent MUST be configured with an IP address and with the 2385 prefix size for the home network. The home agent MUST be configured 2386 with the mobility security association of each authorized mobile node 2387 that it is serving as a home agent. 2389 When the home agent accepts a valid Registration Request from a 2390 mobile node that it serves as a home agent, the home agent MUST 2391 create or modify the entry for this mobile node in its mobility 2392 binding list containing: 2394 - the mobile node's home address 2395 - the mobile node's care-of address 2396 - the Identification field from the Registration Reply 2397 - the remaining Lifetime of the registration 2399 The home agent MAY optionally offer the capability to dynamically 2400 associate a home address to a mobile node upon receiving a 2401 Registration Request from that mobile node. The method by which a 2402 home address is allocated to the mobile node is beyond the scope 2403 of this document, but see [4]. After the home agent makes the 2404 association of the home address to the mobile node, the home agent 2405 MUST put that home address into the Home Address field of the 2406 Registration Reply. 2408 The home agent MAY also maintain mobility security associations 2409 with various foreign agents. When receiving a Registration Request 2410 from a foreign agent, if the home agent shares a mobility security 2411 association with the foreign agent, the home agent MUST check the 2412 Authenticator in the required Foreign-Home Authentication Extension 2413 in the message, based on this mobility security association. 2414 Similarly, when sending a Registration Reply to a foreign agent, 2415 if the home agent shares a mobility security association with 2416 the foreign agent, the home agent MUST include a Foreign-Home 2417 Authentication Extension in the message, based on this mobility 2418 security association. 2420 3.8.2. Receiving Registration Requests 2422 If the home agent accepts an incoming Registration Request, it MUST 2423 update its record of the the mobile node's mobility binding(s) and 2424 SHOULD send a Registration Reply with a suitable Code. Otherwise 2425 (the home agent denies the Request), it SHOULD send a Registration 2426 Reply with an appropriate Code specifying the reason the Request 2427 was denied. The following sections describe this behavior in 2428 more detail. If the home agent does not support broadcasts (see 2429 section 4.3), it MUST ignore the 'B' bit (as opposed to rejecting the 2430 Registration Request). 2432 3.8.2.1. Validity Checks 2434 Registration Requests with an invalid, non-zero UDP checksum MUST be 2435 silently discarded by the home agent. 2437 The authentication in the Registration Request MUST be checked. This 2438 involves the following operations: 2440 a) The home agent MUST check for the presence of an 2441 authorization-enabling extension, and perform the indicated 2442 authentication. Exactly one authorization-enabling extension 2443 MUST be present in the Registration Request; and the home 2444 agent MUST either check the Authenticator value in the 2445 extension. or verify that the authenticator value has 2446 been checked by another agent with which it has a security 2447 association. If no authorization-enabling extension is 2448 found, or if more than one authorization-enabling extension 2449 is found, or if the Authenticator is invalid, the home agent 2450 MUST reject the mobile node's registration and SHOULD send 2451 a Registration Reply to the mobile node with Code 131. The 2452 home agent MUST then discard the Request and SHOULD log the 2453 error as a security exception. 2455 b) The home agent MUST check that the registration 2456 Identification field is correct using the context selected 2457 by the SPI within the authorization-enabling extension. See 2458 Section 5.6 for a description of how this is performed. If 2459 incorrect, the home agent MUST reject the Request and SHOULD 2460 send a Registration Reply to the mobile node with Code 133, 2461 including an Identification field computed in accordance with 2462 the rules specified in Section 5.6. The home agent MUST do 2463 no further processing with such a Request, though it SHOULD 2464 log the error as a security exception. 2466 c) If the home agent shares a mobility security association with 2467 the foreign agent, the home agent MUST check for the presence 2468 of a valid Foreign-Home Authentication Extension. Exactly 2469 one Foreign-Home Authentication Extension MUST be present in 2470 the Registration Request in this case, and the home agent 2471 MUST check the Authenticator value in the Extension. If no 2472 Foreign-Home Authentication Extension is found, or if more 2473 than one Foreign-Home Authentication Extension is found, or 2474 if the Authenticator is invalid, the home agent MUST reject 2475 the mobile node's registration and SHOULD send a Registration 2476 Reply to the mobile node with Code 132. The home agent 2477 MUST then discard the Request and SHOULD log the error as a 2478 security exception. 2480 In addition to checking the authentication in the Registration 2481 Request, home agents MUST deny Registration Requests that are sent to 2482 the subnet-directed broadcast address of the home network (as opposed 2483 to being unicast to the home agent). The home agent MUST discard 2484 the Request and SHOULD returning a Registration Reply with a Code 2485 of 136. In this case, the Registration Reply will contain the home 2486 agent's unicast address, so that the mobile node can re-issue the 2487 Registration Request with the correct home agent address. 2489 Note that some routers change the IP destination address of a 2490 datagram from a subnet-directed broadcast address to 255.255.255.255 2491 before injecting it into the destination subnet. In this case, home 2492 agents that attempt to pick up dynamic home agent discovery requests 2493 by binding a socket explicitly to the subnet-directed broadcast 2494 address will not see such packets. Home agent implementors should 2495 be prepared for both the subnet-directed broadcast address and 2496 255.255.255.255 if they wish to support dynamic home agent discovery. 2498 3.8.2.2. Accepting a Valid Request 2500 If the Registration Request satisfies the validity checks in 2501 Section 3.8.2.1, and the home agent is able to accommodate the 2502 Request, the home agent MUST update its mobility binding list for 2503 the requesting mobile node and MUST return a Registration Reply to 2504 the mobile node. In this case, the Reply Code will be either 0 if 2505 the home agent supports simultaneous mobility bindings, or 1 if it 2506 does not. See Section 3.8.3 for details on building the Registration 2507 Reply message. 2509 The home agent updates its record of the mobile node's mobility 2510 bindings as follows, based on the fields in the Registration Request: 2512 - If the Lifetime is zero and the Care-of Address equals the mobile 2513 node's home address, the home agent deletes all of the entries in 2514 the mobility binding list for the requesting mobile node. This 2515 is how a mobile node requests that its home agent cease providing 2516 mobility services. 2518 - If the Lifetime is zero and the Care-of Address does not equal 2519 the mobile node's home address, the home agent deletes only the 2520 entry containing the specified Care-of Address from the mobility 2521 binding list for the requesting mobile node. Any other active 2522 entries containing other care-of addresses will remain active. 2524 - If the Lifetime is nonzero, the home agent adds an entry 2525 containing the requested Care-of Address to the mobility binding 2526 list for the mobile node. If the 'S' bit is set and the home 2527 agent supports simultaneous mobility bindings, the previous 2528 mobility binding entries are retained. Otherwise, the home agent 2529 removes all previous entries in the mobility binding list for the 2530 mobile node. 2532 In all cases, the home agent MUST send a Registration Reply to 2533 the source of the Registration Request, which might indeed be a 2534 different foreign agent than that whose care-of address is being 2535 (de)registered. If the home agent shares a mobility security 2536 association with the foreign agent whose care-of address is being 2537 deregistered, and that foreign agent is different from the one which 2538 relayed the Registration Request, the home agent MAY additionally 2539 send a Registration Reply to the foreign agent whose care-of address 2540 is being deregistered. The home agent MUST NOT send such a Reply if 2541 it does not share a mobility security association with the foreign 2542 agent. If no Reply is sent, the foreign agent's visitor list will 2543 expire naturally when the original Lifetime expires. 2545 The home agent MUST NOT increase the Lifetime above that specified 2546 by the mobile node in the Registration Request. However, it is not 2547 an error for the mobile node to request a Lifetime longer than the 2548 home agent is willing to accept. In this case, the home agent simply 2549 reduces the Lifetime to a permissible value and returns this value in 2550 the Registration Reply. The Lifetime value in the Registration Reply 2551 informs the mobile node of the granted lifetime of the registration, 2552 indicating when it SHOULD re-register in order to maintain continued 2553 service. After the expiration of this registration lifetime, 2554 the home agent MUST delete its entry for this registration in its 2555 mobility binding list. 2557 If the Registration Request duplicates an accepted current 2558 Registration Request, the new Lifetime MUST NOT extend beyond the 2559 Lifetime originally granted. A Registration Request is a duplicate 2560 if the home address, care-of address, and Identification fields all 2561 equal those of an accepted current registration. 2563 In addition, if the home network implements ARP [29], and the 2564 Registration Request asks the home agent to create a mobility binding 2565 for a mobile node which previously had no binding (the mobile node 2566 was previously assumed to be at home), then the home agent MUST 2567 follow the procedures described in Section 4.6 with regard to ARP, 2568 proxy ARP, and gratuitous ARP. If the mobile node already had a 2569 previous mobility binding, the home agent MUST continue to follow the 2570 rules for proxy ARP described in Section 4.6. 2572 3.8.2.3. Denying an Invalid Request 2574 If the Registration Reply does not satisfy all of the validity checks 2575 in Section 3.8.2.1, or the home agent is unable to accommodate the 2576 Request, the home agent SHOULD return a Registration Reply to the 2577 mobile node with a Code that indicates the reason for the error. If 2578 a foreign agent was involved in relaying the Request, this allows the 2579 foreign agent to delete its pending visitor list entry. Also, this 2580 informs the mobile node of the reason for the error such that it may 2581 attempt to fix the error and issue another Request. 2583 This section lists a number of reasons the home agent might reject a 2584 Request, and provides the Code value it should use in each instance. 2585 See Section 3.8.3 for additional details on building the Registration 2586 Reply message. 2588 Many reasons for rejecting a registration are administrative 2589 in nature. For example, a home agent can limit the number of 2590 simultaneous registrations for a mobile node, by rejecting any 2591 registrations that would cause its limit to be exceeded, and 2592 returning a Registration Reply with error code 135. Similarly, a 2593 home agent may refuse to grant service to mobile nodes which have 2594 entered unauthorized service areas by returning a Registration Reply 2595 with a Code of 129. 2597 Requests with non-zero bits in reserved fields MUST be rejected with 2598 code 134 (poorly formed request). 2600 3.8.3. Sending Registration Replies 2602 If the home agent accepts a Registration Request, it then MUST update 2603 its record of the mobile node's mobility binding(s) and SHOULD send a 2604 Registration Reply with a suitable Code. Otherwise (the home agent 2605 has denied the Request), it SHOULD send a Registration Reply with an 2606 appropriate Code specifying the reason the Request was denied. The 2607 following sections provide additional detail for the values the home 2608 agent MUST supply in the fields of Registration Reply messages. 2610 3.8.3.1. IP/UDP Fields 2612 This section provides the specific rules by which mobile nodes pick 2613 values for the IP and UDP header fields of a Registration Reply. 2615 IP Source Address 2616 Copied from the IP Destination Address of Registration 2617 Request, unless a multicast or broadcast address was 2618 used. If the IP Destination Address of the Registration 2619 Request was a broadcast or multicast address, the IP 2620 Source Address of the Registration Reply MUST be set to 2621 the home agent's (unicast) IP address. 2623 IP Destination Address 2624 Copied from the IP Source Address of the Registration 2625 Request. 2627 UDP Source Port 2628 Copied from the UDP Destination Port of the Registration 2629 Request. 2631 UDP Destination Port 2632 Copied from the UDP Source Port of the Registration 2633 Request. 2635 When sending a Registration Reply in response to a Registration 2636 Request that requested deregistration of the mobile node (the 2637 Lifetime is zero and the Care-of Address equals the mobile node's 2638 home address) and in which the IP Source Address was also set to 2639 the mobile node's home address (this is the normal method used by a 2640 mobile node to deregister when it returns to its home network), the 2641 IP Destination Address in the Registration Reply will be set to the 2642 mobile node's home address, as copied from the IP Source Address of 2643 the Request. 2645 In this case, when transmitting the Registration Reply, the home 2646 agent MUST transmit the Reply directly onto the home network as if 2647 the mobile node were at home, bypassing any mobility binding list 2648 entry that may still exist at the home agent for the destination 2649 mobile node. In particular, for a mobile node returning home 2650 after being registered with a care-of address, if the mobile node's 2651 new Registration Request is not accepted by the home agent, the 2652 mobility binding list entry for the mobile node will still indicate 2653 that datagrams addressed to the mobile node should be tunneled to 2654 the mobile node's registered care-of address; when sending the 2655 Registration Reply indicating the rejection of this Request, this 2656 existing binding list entry MUST be ignored, and the home agent MUST 2657 transmit this Reply as if the mobile node were at home. 2659 3.8.3.2. Registration Reply Fields 2661 This section provides specific rules by which home agents pick values 2662 for the fields within the fixed portion of a Registration Reply. 2664 The Code field of the Registration Reply is chosen in accordance with 2665 the rules specified in the previous sections. When replying to an 2666 accepted registration, a home agent SHOULD respond with Code 1 if it 2667 does not support simultaneous registrations. 2669 The Lifetime field MUST be copied from the corresponding field in 2670 the Registration Request, unless the requested value is greater than 2671 the maximum length of time the home agent is willing to provide the 2672 requested service. In such a case, the Lifetime MUST be set to the 2673 length of time that service will actually be provided by the home 2674 agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed 2675 by the home agent (for this mobile node and care-of address). 2677 The Home Address field MUST be copied from the corresponding field in 2678 the Registration Request. 2680 If the Home Agent field in the Registration Request contains a 2681 unicast address of this home agent, then that field MUST be copied 2682 into the Home Agent field of the Registration Reply. Otherwise, the 2683 home agent MUST set the Home Agent field in the Registration Reply to 2684 its unicast address. In this latter case, the home agent MUST reject 2685 the registration with a suitable code (e.g., Code 136) to prevent the 2686 mobile node from possibly being simultaneously registered with two or 2687 more home agents. 2689 3.8.3.3. Extensions 2691 This section describes the ordering of any required and any optional 2692 Mobile IP Extensions that a home agent appends to a Registration 2693 Reply. The following ordering MUST be followed: 2695 a) The IP header, followed by the UDP header, followed by the 2696 fixed-length portion of the Registration Reply, 2698 b) If present, any non-authentication Extensions used by the 2699 mobile node (which may or may not also be used by the foreign 2700 agent), 2702 c) The Mobile-Home Authentication Extension, 2704 d) If present, any non-authentication Extensions used only by 2705 the foreign agent, and 2707 e) The Foreign-Home Authentication Extension, if present. 2709 Note that items (a) and (c) MUST appear in every Registration Reply 2710 sent by the home agent. Items (b), (d), and (e) are optional. 2711 However, item (e) MUST be included when the home agent and the 2712 foreign agent share a mobility security association. 2714 4. Routing Considerations 2716 This section describes how mobile nodes, home agents, and (possibly) 2717 foreign agents cooperate to route datagrams to/from mobile nodes that 2718 are connected to a foreign network. The mobile node informs its 2719 home agent of its current location using the registration procedure 2720 described in Section 3. See the protocol overview in Section 1.7 for 2721 the relative locations of the mobile node's home address with respect 2722 to its home agent, and the mobile node itself with respect to any 2723 foreign agent with which it might attempt to register. 2725 4.1. Encapsulation Types 2727 Home agents and foreign agents MUST support tunneling datagrams 2728 using IP in IP encapsulation [23]. Any mobile node that uses a 2729 co-located care-of address MUST support receiving datagrams tunneled 2730 using IP in IP encapsulation. Minimal encapsulation [25] and GRE 2731 encapsulation [13] are alternate encapsulation methods which MAY 2732 optionally be supported by mobility agents and mobile nodes. The use 2733 of these alternative forms of encapsulation, when requested by the 2734 mobile node, is otherwise at the discretion of the home agent. 2736 4.2. Unicast Datagram Routing 2738 4.2.1. Mobile Node Considerations 2740 When connected to its home network, a mobile node operates without 2741 the support of mobility services. That is, it operates in the same 2742 way as any other (fixed) host or router. The method by which a 2743 mobile node selects a default router when connected to its home 2744 network, or when away from home and using a co-located care-of 2745 address, is outside the scope of this document. ICMP Router 2746 Advertisement [7] is one such method. 2748 When registered on a foreign network, the mobile node chooses a 2749 default router by the following rules: 2751 - If the mobile node is registered using a foreign agent care-of 2752 address, it MAY use its foreign agent as a first-hop router. 2753 The foreign agent's MAC address can be learned from Agent 2754 Advertisement. Otherwise, the mobile node MUST choose its 2755 default router from among the Router Addresses advertised in the 2756 ICMP Router Advertisement portion of that Agent Advertisement 2757 message. 2759 - If the mobile node is registered directly with its home agent 2760 using a co-located care-of address, then the mobile node SHOULD 2761 choose its default router from among those advertised in any 2762 ICMP Router Advertisement message that it receives for which 2763 its externally obtained care-of address and the Router Address 2764 match under the network prefix. If the mobile node's externally 2765 obtained care-of address matches the IP source address of the 2766 Agent Advertisement under the network prefix, the mobile node MAY 2767 also consider that IP source address as another possible choice 2768 for the IP address of a default router. The network prefix MAY 2769 be obtained from the Prefix-Lengths Extension in the Router 2770 Advertisement, if present. The prefix MAY also be obtained 2771 through other mechanisms beyond the scope of this document. 2773 While they are away from the home network, mobile nodes MUST NOT 2774 broadcast ARP packets to find the MAC address of another Internet 2775 node. Thus, the (possibly empty) list of Router Addresses from the 2776 ICMP Router Advertisement portion of the message is not useful for 2777 selecting a default router, unless the mobile node has some means 2778 not involving broadcast ARP and not specified within this document 2779 for obtaining the MAC address of one of the routers in the list. 2780 Similarly, in the absence of unspecified mechanisms for obtaining MAC 2781 addresses on foreign networks, the mobile node MUST ignore redirects 2782 to other routers on foreign networks. 2784 4.2.2. Foreign Agent Considerations 2786 Upon receipt of an encapsulated datagram sent to its advertised 2787 care-of address, a foreign agent MUST compare the inner destination 2788 address to those entries in its visitor list. When the destination 2789 does not match the address of any mobile node currently in the 2790 visitor list, the foreign agent MUST NOT forward the datagram without 2791 modifications to the original IP header, because otherwise a routing 2792 loop is likely to result. The datagram SHOULD be silently discarded. 2793 ICMP Destination Unreachable MUST NOT be sent when a foreign agent 2794 is unable to forward an incoming tunneled datagram. Otherwise, the 2795 foreign agent forwards the decapsulated datagram to the mobile node. 2797 The foreign agent MUST NOT advertise to other routers in its routing 2798 domain, nor to any other mobile node, the presence of a mobile router 2799 (Section 4.5) or mobile node in its visitor list. 2801 The foreign agent MUST route datagrams it receives from registered 2802 mobile nodes. At a minimum, this means that the foreign agent 2803 must verify the IP Header Checksum, decrement the IP Time To Live, 2804 recompute the IP Header Checksum, and forward such datagrams to a 2805 default router. 2807 A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC 2808 address on a foreign network. It may obtain the MAC address by 2809 copying the information from an Agent Solicitation or a Registration 2810 Request transmitted from a mobile node. A foreign agent's ARP cache 2811 for the mobile node's IP address MUST NOT be allowed to expire before 2812 the mobile node's visitor list entry expires, unless the foreign 2813 agent has some way other than broadcast ARP to refresh its MAC 2814 address associated to the mobile node's IP address. 2816 Each foreign agent SHOULD support the mandatory features for reverse 2817 tunneling [21]. 2819 4.2.3. Home Agent Considerations 2821 The home agent MUST be able to intercept any datagrams on the 2822 home network addressed to the mobile node while the mobile node is 2823 registered away from home. Proxy and gratuitous ARP MAY be used in 2824 enabling this interception, as specified in Section 4.6. 2826 The home agent must examine the IP Destination Address of all 2827 arriving datagrams to see if it is equal to the home address of any 2828 of its mobile nodes registered away from home. If so, the home 2829 agent tunnels the datagram to the mobile node's currently registered 2830 care-of address or addresses. If the home agent supports the 2831 optional capability of multiple simultaneous mobility bindings, it 2832 tunnels a copy to each care-of address in the mobile node's mobility 2833 binding list. If the mobile node has no current mobility bindings, 2834 the home agent MUST NOT attempt to intercept datagrams destined for 2835 the mobile node, and thus will not in general receive such datagrams. 2836 However, if the home agent is also a router handling common IP 2837 traffic, it is possible that it will receive such datagrams for 2838 forwarding onto the home network. In this case, the home agent MUST 2839 assume the mobile node is at home and simply forward the datagram 2840 directly onto the home network. 2842 For multihomed home agents, the source address in the outer IP header 2843 of the encapsulated datagram MUST be the address that the mobile 2844 node used in the home agent field of the registration request. That 2845 is, the home agent cannot use the the address of some other network 2846 interface as the source address. 2848 See Section 4.1 regarding methods of encapsulation that may be used 2849 for tunneling. Nodes implementing tunneling SHOULD also implement 2850 the "tunnel soft state" mechanism [23], which allows ICMP error 2851 messages returned from the tunnel to correctly be reflected back to 2852 the original senders of the tunneled datagrams. 2854 Home agents MUST decapsulate packets addressed to themselves, sent 2855 by a mobile node for the purpose of maintaining location privacy, as 2856 described in Section 5.5. This feature is also required for support 2857 of reverse tunneling [21]. 2859 If the Lifetime for a given mobility binding expires before the 2860 home agent has received another valid Registration Request for that 2861 mobile node, then that binding is deleted from the mobility binding 2862 list. The home agent MUST NOT send any Registration Reply message 2863 simply because the mobile node's binding has expired. The entry in 2864 the visitor list of the mobile node's current foreign agent will 2865 expire naturally, probably at the same time as the binding expired 2866 at the home agent. When a mobility binding's lifetime expires, the 2867 home agent MUST delete the binding, but it MUST retain any other 2868 (non-expired) simultaneous mobility bindings that it holds for the 2869 mobile node. 2871 When a home agent receives a datagram, intercepted for one of its 2872 mobile nodes registered away from home, the home agent MUST examine 2873 the datagram to check if it is already encapsulated. If so, special 2874 rules apply in the forwarding of that datagram to the mobile node: 2876 - If the inner (encapsulated) Destination Address is the same 2877 as the outer Destination Address (the mobile node), then the 2878 home agent MUST also examine the outer Source Address of the 2879 encapsulated datagram (the source address of the tunnel). If 2880 this outer Source Address is the same as the mobile node's 2881 current care-of address, the home agent MUST silently discard 2882 that datagram in order to prevent a likely routing loop. If, 2883 instead, the outer Source Address is NOT the same as the mobile 2884 node's current care-of address, then the home agent SHOULD 2885 forward the datagram to the mobile node. In order to forward 2886 the datagram in this case, the home agent MAY simply alter the 2887 outer Destination Address to the care-of address, rather than 2888 re-encapsulating the datagram. 2890 - Otherwise (the inner Destination Address is NOT the same as the 2891 outer Destination Address), the home agent SHOULD encapsulate 2892 the datagram again (nested encapsulation), with the new outer 2893 Destination Address set equal to the mobile node's care-of 2894 address. That is, the home agent forwards the entire datagram 2895 to the mobile node in the same way as any other datagram 2896 (encapsulated already or not). 2898 4.3. Broadcast Datagrams 2900 When a home agent receives a broadcast datagram, it MUST NOT forward 2901 the datagram to any mobile nodes in its mobility binding list other 2902 than those that have requested forwarding of broadcast datagrams. A 2903 mobile node MAY request forwarding of broadcast datagrams by setting 2904 the 'B' bit in its Registration Request message (Section 3.3). For 2905 each such registered mobile node, the home agent SHOULD forward 2906 received broadcast datagrams to the mobile node, although it is 2907 a matter of configuration at the home agent as to which specific 2908 categories of broadcast datagrams will be forwarded to such mobile 2909 nodes. 2911 If the 'D' bit was set in the mobile node's Registration Request 2912 message, indicating that the mobile node is using a co-located 2913 care-of address, the home agent simply tunnels appropriate broadcast 2914 IP datagrams to the mobile node's care-of address. Otherwise (the 2915 'D' bit was NOT set), the home agent first encapsulates the broadcast 2916 datagram in a unicast datagram addressed to the mobile node's home 2917 address, and then tunnels this encapsulated datagram to the foreign 2918 agent. This extra level of encapsulation is required so that the 2919 foreign agent can determine which mobile node should receive the 2920 datagram after it is decapsulated. When received by the foreign 2921 agent, the unicast encapsulated datagram is detunneled and delivered 2922 to the mobile node in the same way as any other datagram. In either 2923 case, the mobile node must decapsulate the datagram it receives in 2924 order to recover the original broadcast datagram. 2926 4.4. Multicast Datagram Routing 2928 As mentioned previously, a mobile node that is connected to its 2929 home network functions in the same way as any other (fixed) host 2930 or router. Thus, when it is at home, a mobile node functions 2931 identically to other multicast senders and receivers. This section 2932 therefore describes the behavior of a mobile node that is visiting a 2933 foreign network. 2935 In order receive multicasts, a mobile node MUST join the multicast 2936 group in one of two ways. First, a mobile node MAY join the group 2937 via a (local) multicast router on the visited subnet. This option 2938 assumes that there is a multicast router present on the visited 2939 subnet. If the mobile node is using a co-located care-of address, 2940 it SHOULD use this address as the source IP address of its IGMP [8] 2941 messages. Otherwise, it MAY use its home address. 2943 Alternatively, a mobile node which wishes to receive multicasts MAY 2944 join groups via a bi-directional tunnel to its home agent, assuming 2945 that its home agent is a multicast router. The mobile node tunnels 2946 IGMP messages to its home agent and the home agent forwards multicast 2947 datagrams down the tunnel to the mobile node. For packets tunneled 2948 to the home agent, the source address in the IP header SHOULD be the 2949 mobile node's home address. 2951 The rules for multicast datagram delivery to mobile nodes in this 2952 case are identical to those for broadcast datagrams (Section 4.3). 2953 Namely, if the mobile node is using a co-located care-of address (the 2954 'D' bit was set in the mobile node's Registration Request), then 2955 the home agent SHOULD tunnel the datagram to this care-of address; 2956 otherwise, the home agent MUST first encapsulate the datagram in a 2957 unicast datagram addressed to the mobile node's home address and then 2958 MUST tunnel the resulting datagram (nested tunneling) to the mobile 2959 node's care-of address. For this reason, the mobile node MUST be 2960 capable of decapsulating packets sent to its home address in order to 2961 receive multicast datagrams using this method. 2963 A mobile node that wishes to send datagrams to a multicast group 2964 also has two options: (1) send directly on the visited network; or 2965 (2) send via a tunnel to its home agent. Because multicast routing 2966 in general depends upon the IP source address, a mobile node which 2967 sends multicast datagrams directly on the visited network MUST use a 2968 co-located care-of address as the IP source address. Similarly, a 2969 mobile node which tunnels a multicast datagram to its home agent MUST 2970 use its home address as the IP source address of both the (inner) 2971 multicast datagram and the (outer) encapsulating datagram. This 2972 second option assumes that the home agent is a multicast router. 2974 4.5. Mobile Routers 2976 A mobile node can be a router, which is responsible for the mobility 2977 of one or more entire networks moving together, perhaps on an 2978 airplane, a ship, a train, an automobile, a bicycle, or a kayak. 2979 The nodes connected to a network served by the mobile router may 2980 themselves be fixed nodes or mobile nodes or routers. In this 2981 document, such networks are called "mobile networks". 2983 A mobile router MAY act as a foreign agent and provide a foreign 2984 agent care-of address to mobile nodes connected to the mobile 2985 network. Typical routing to a mobile node via a mobile router in 2986 this case is illustrated by the following example: 2988 a) A laptop computer is disconnected from its home network and 2989 later attached to a network port in the seat back of an 2990 aircraft. The laptop computer uses Mobile IP to register on 2991 this foreign network, using a foreign agent care-of address 2992 discovered through an Agent Advertisement from the aircraft's 2993 foreign agent. 2995 b) The aircraft network is itself mobile. Suppose the node 2996 serving as the foreign agent on the aircraft also serves as 2997 the default router that connects the aircraft network to the 2998 rest of the Internet. When the aircraft is at home, this 2999 router is attached to some fixed network at the airline's 3000 headquarters, which is the router's home network. While 3001 the aircraft is in flight, this router registers from time 3002 to time over its radio link with a series of foreign agents 3003 below it on the ground. This router's home agent is a node 3004 on the fixed network at the airline's headquarters. 3006 c) Some correspondent node sends a datagram to the laptop 3007 computer, addressing the datagram to the laptop's home 3008 address. This datagram is initially routed to the laptop's 3009 home network. 3011 d) The laptop's home agent intercepts the datagram on the home 3012 network and tunnels it to the laptop's care-of address, which 3013 in this example is an address of the node serving as router 3014 and foreign agent on the aircraft. Normal IP routing will 3015 route the datagram to the fixed network at the airline's 3016 headquarters. 3018 e) The aircraft router and foreign agent's home agent there 3019 intercepts the datagram and tunnels it to its current care-of 3020 address, which in this example is some foreign agent on the 3021 ground below the aircraft. The original datagram from the 3022 correspondent node has now been encapsulated twice: once 3023 by the laptop's home agent and again by the aircraft's home 3024 agent. 3026 f) The foreign agent on the ground decapsulates the datagram, 3027 yielding a datagram still encapsulated by the laptop's home 3028 agent, with a destination address of the laptop's care-of 3029 address. The ground foreign agent sends the resulting 3030 datagram over its radio link to the aircraft. 3032 g) The foreign agent on the aircraft decapsulates the datagram, 3033 yielding the original datagram from the correspondent node, 3034 with a destination address of the laptop's home address. 3035 The aircraft foreign agent delivers the datagram over the 3036 aircraft network to the laptop's link-layer address. 3038 This example illustrated the case in which a mobile node is attached 3039 to a mobile network. That is, the mobile node is mobile with respect 3040 to the network, which itself is also mobile (here with respect to 3041 the ground). If, instead, the node is fixed with respect to the 3042 mobile network (the mobile network is the fixed node's home network), 3043 then either of two methods may be used to cause datagrams from 3044 correspondent nodes to be routed to the fixed node. 3046 A home agent MAY be configured to have a permanent registration for 3047 the fixed node, that indicates the mobile router's address as the 3048 fixed host's care-of address. The mobile router's home agent will 3049 usually be used for this purpose. The home agent is then responsible 3050 for advertising connectivity using normal routing protocols to the 3051 fixed node. Any datagrams sent to the fixed node will thus use 3052 nested tunneling as described above. 3054 Alternatively, the mobile router MAY advertise connectivity to the 3055 entire mobile network using normal IP routing protocols through a 3056 bi-directional tunnel to its own home agent. This method avoids the 3057 need for nested tunneling of datagrams. 3059 4.6. ARP, Proxy ARP, and Gratuitous ARP 3061 The use of ARP [29] requires special rules for correct operation when 3062 wireless or mobile nodes are involved. The requirements specified 3063 in this section apply to all home networks in which ARP is used for 3064 address resolution. 3066 In addition to the normal use of ARP for resolving a target node's 3067 link-layer address from its IP address, this document distinguishes 3068 two special uses of ARP: 3070 - A Proxy ARP [32] is an ARP Reply sent by one node on behalf 3071 of another node which is either unable or unwilling to answer 3072 its own ARP Requests. The sender of a Proxy ARP reverses the 3073 Sender and Target Protocol Address fields as described in [29], 3074 but supplies some configured link-layer address (generally, its 3075 own) in the Sender Hardware Address field. The node receiving 3076 the Reply will then associate this link-layer address with the 3077 IP address of the original target node, causing it to transmit 3078 future datagrams for this target node to the node with that 3079 link-layer address. 3081 - A Gratuitous ARP [38] is an ARP packet sent by a node in order to 3082 spontaneously cause other nodes to update an entry in their ARP 3083 cache. A gratuitous ARP MAY use either an ARP Request or an ARP 3084 Reply packet. In either case, the ARP Sender Protocol Address 3085 and ARP Target Protocol Address are both set to the IP address 3086 of the cache entry to be updated, and the ARP Sender Hardware 3087 Address is set to the link-layer address to which this cache 3088 entry should be updated. When using an ARP Reply packet, the 3089 Target Hardware Address is also set to the link-layer address to 3090 which this cache entry should be updated (this field is not used 3091 in an ARP Request packet). 3093 In either case, for a gratuitous ARP, the ARP packet MUST be 3094 transmitted as a local broadcast packet on the local link. As 3095 specified in [29], any node receiving any ARP packet (Request or 3096 Reply) MUST update its local ARP cache with the Sender Protocol 3097 and Hardware Addresses in the ARP packet, if the receiving node 3098 has an entry for that IP address already in its ARP cache. This 3099 requirement in the ARP protocol applies even for ARP Request 3100 packets, and for ARP Reply packets that do not match any ARP 3101 Request transmitted by the receiving node [29]. 3103 While a mobile node is registered on a foreign network, its home 3104 agent uses proxy ARP [32] to reply to ARP Requests it receives that 3105 seek the mobile node's link-layer address. When receiving an ARP 3106 Request, the home agent MUST examine the target IP address of the 3107 Request, and if this IP address matches the home address of any 3108 mobile node for which it has a registered mobility binding, the home 3109 agent MUST transmit an ARP Reply on behalf of the mobile node. After 3110 exchanging the sender and target addresses in the packet [32], the 3111 home agent MUST set the sender link-layer address in the packet to 3112 the link-layer address of its own interface over which the Reply will 3113 be sent. 3115 When a mobile node leaves its home network and registers a binding on 3116 a foreign network, its home agent uses gratuitous ARP to update the 3117 ARP caches of nodes on the home network. This causes such nodes to 3118 associate the link-layer address of the home agent with the mobile 3119 node's home (IP) address. When registering a binding for a mobile 3120 node for which the home agent previously had no binding (the mobile 3121 node was assumed to be at home), the home agent MUST transmit a 3122 gratuitous ARP on behalf of the mobile node. This gratuitous ARP 3123 packet MUST be transmitted as a broadcast packet on the link on which 3124 the mobile node's home address is located. Since broadcasts on the 3125 local link (such as Ethernet) are typically not guaranteed to be 3126 reliable, the gratuitous ARP packet SHOULD be retransmitted a small 3127 number of times to increase its reliability. 3129 When a mobile node returns to its home network, the mobile node 3130 and its home agent use gratuitous ARP to cause all nodes on the 3131 mobile node's home network to update their ARP caches to once again 3132 associate the mobile node's own link-layer address with the mobile 3133 node's home (IP) address. Before transmitting the (de)Registration 3134 Request message to its home agent, the mobile node MUST transmit this 3135 gratuitous ARP on its home network as a local broadcast on this link. 3136 The gratuitous ARP packet SHOULD be retransmitted a small number of 3137 times to increase its reliability, but these retransmissions SHOULD 3138 proceed in parallel with the transmission and processing of its 3139 (de)Registration Request. 3141 When the mobile node's home agent receives and accepts this 3142 (de)Registration Request, the home agent MUST also transmit a 3143 gratuitous ARP on the mobile node's home network. This gratuitous 3144 ARP also is used to associate the mobile node's home address with 3145 the mobile node's own link-layer address. A gratuitous ARP is 3146 transmitted by both the mobile node and its home agent, since in the 3147 case of wireless network interfaces, the area within transmission 3148 range of the mobile node will likely differ from that within range 3149 of its home agent. Th ARP packet from the home agent MUST be 3150 transmitted as a local broadcast on the mobile node's home link, 3151 and SHOULD be retransmitted a small number of times to increase 3152 its reliability; these retransmissions, however, SHOULD proceed in 3153 parallel with the transmission and processing of its (de)Registration 3154 Reply. 3156 While the mobile node is away from home, it MUST NOT transmit any 3157 broadcast ARP Request or ARP Reply messages. Finally, while the 3158 mobile node is away from home, it MUST NOT reply to ARP Requests in 3159 which the target IP address is its own home address. unless the 3160 ARP Request is unicast by a foreign agent with which the mobile 3161 node is attempting to register or a foreign agent with which the 3162 mobile node has an unexpired registration. In the latter case, the 3163 mobile node MUST use a unicast ARP Reply to respond to the foreign 3164 agent. Note that if the mobile node is using a co-located care-of 3165 address and receives an ARP Request in which the target IP address is 3166 this care-of address, then the mobile node SHOULD reply to this ARP 3167 Request. Note also that, when transmitting a Registration Request on 3168 a foreign network, a mobile node may discover the link-layer address 3169 of a foreign agent by storing the address as it is received from the 3170 Agent Advertisement from that foreign agent, but not by transmitting 3171 a broadcast ARP Request message. 3173 The specific order in which each of the above requirements for the 3174 use of ARP, proxy ARP, and gratuitous ARP are applied, relative to 3175 the transmission and processing of the mobile node's Registration 3176 Request and Registration Reply messages when leaving home or 3177 returning home, are important to the correct operation of the 3178 protocol. 3180 To summarize the above requirements, when a mobile node leaves its 3181 home network, the following steps, in this order, MUST be performed: 3183 - The mobile node decides to register away from home, perhaps 3184 because it has received an Agent Advertisement from a foreign 3185 agent and has not recently received one from its home agent. 3187 - Before transmitting the Registration Request, the mobile node 3188 disables its own future processing of any ARP Requests it 3189 may subsequently receive requesting the link-layer address 3190 corresponding to its home address, except insofar as necessary to 3191 communicate with foreign agents on visited networks. 3193 - The mobile node transmits its Registration Request. 3195 - When the mobile node's home agent receives and accepts the 3196 Registration Request, it performs a gratuitous ARP on behalf 3197 of the mobile node, and begins using proxy ARP to reply to ARP 3198 Requests that it receives requesting the mobile node's link-layer 3199 address. If, instead, the home agent rejects the Registration 3200 Request, no ARP processing (gratuitous nor proxy) is performed by 3201 the home agent. 3203 When a mobile node later returns to its home network, the following 3204 steps, in this order, MUST be performed: 3206 - The mobile node decides to register at home, perhaps because it 3207 has received an Agent Advertisement from its home agent. 3209 - Before transmitting the Registration Request, the mobile node 3210 re-enables its own future processing of any ARP Requests it may 3211 subsequently receive requesting its link-layer address. 3213 - The mobile node performs a gratuitous ARP for itself. 3215 - The mobile node transmits its Registration Request. 3217 - When the mobile node's home agent receives and accepts the 3218 Registration Request, it stops using proxy ARP to reply to 3219 ARP Requests that it receives requesting the mobile node's 3220 link-layer address, and then performs a gratuitous ARP on behalf 3221 of the mobile node. If, instead, the home agent rejects the 3222 Registration Request, no ARP processing (gratuitous nor proxy) is 3223 performed by the home agent. 3225 5. Security Considerations 3227 The mobile computing environment is potentially very different from 3228 the ordinary computing environment. In many cases, mobile computers 3229 will be connected to the network via wireless links. Such links 3230 are particularly vulnerable to passive eavesdropping, active replay 3231 attacks, and other active attacks. 3233 5.1. Message Authentication Codes 3235 Home agents and mobile nodes MUST be able to perform authentication. 3236 The default algorithm is keyed MD5 [34], with a key size of 128 3237 bits. The default mode of operation is to both precede and follow 3238 the data to be hashed, by the 128-bit key; that is, MD5 is to be 3239 used in "prefix+suffix" mode. The foreign agent MUST also support 3240 authentication using keyed MD5 and key sizes of 128 bits or greater, 3241 with manual key distribution. Keys with arbitrary binary values MUST 3242 be supported. More authentication algorithms, algorithm modes, key 3243 distribution methods, and key sizes MAY also be supported. 3245 5.2. Areas of Security Concern in this Protocol 3247 The registration protocol described in this document will result 3248 in a mobile node's traffic being tunneled to its care-of address. 3249 This tunneling feature could be a significant vulnerability if the 3250 registration were not authenticated. Such remote redirection, for 3251 instance as performed by the mobile registration protocol, is widely 3252 understood to be a security problem in the current Internet if not 3253 authenticated [1]. Moreover, the Address Resolution Protocol (ARP) 3254 is not authenticated, and can potentially be used to steal another 3255 host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings 3256 with it all of the risks associated with the use of ARP. 3258 5.3. Key Management 3260 This specification requires a strong authentication mechanism 3261 (keyed MD5) which precludes many potential attacks based on the 3262 Mobile IP registration protocol. However, because key distribution 3263 is difficult in the absence of a network key management protocol, 3264 messages with the foreign agent are not all required to be 3265 authenticated. In a commercial environment it might be important 3266 to authenticate all messages between the foreign agent and the home 3267 agent, so that billing is possible, and service providers do not 3268 provide service to users that are not legitimate customers of that 3269 service provider. 3271 5.4. Picking Good Random Numbers 3273 The strength of any authentication mechanism depends on several 3274 factors, including the innate strength of the authentication 3275 algorithm, the secrecy of the key used, the strength of the key used, 3276 and the quality of the particular implementation. This specification 3277 requires implementation of keyed MD5 for authentication, but does not 3278 preclude the use of other authentication algorithms and modes. For 3279 keyed MD5 authentication to be useful, the 128-bit key must be both 3280 secret (that is, known only to authorized parties) and pseudo-random. 3281 If nonces are used in connection with replay protection, they must 3282 also be selected carefully. Eastlake, et al. [11] provides more 3283 information on generating pseudo-random numbers. 3285 5.5. Privacy 3287 Users who have sensitive data that they do not wish others to see 3288 should use mechanisms outside the scope of this document (such as 3289 encryption) to provide appropriate protection. Users concerned about 3290 traffic analysis should consider appropriate use of link encryption. 3291 If absolute location privacy is desired, the mobile node can create a 3292 tunnel to its home agent. Then, datagrams destined for correspondent 3293 nodes will appear to emanate from the home network, and it may be 3294 more difficult to pinpoint the location of the mobile node. Such 3295 mechanisms are all beyond the scope of this document. 3297 5.6. Replay Protection for Registration Requests 3299 The Identification field is used to let the home agent verify that a 3300 registration message has been freshly generated by the mobile node, 3301 not replayed by an attacker from some previous registration. Two 3302 methods are described in this section: timestamps (mandatory) and 3303 "nonces" (optional). All mobile nodes and home agents MUST implement 3304 timestamp-based replay protection. These nodes MAY also implement 3305 nonce-based replay protection (but see Appendix A.2 for a patent that 3306 may apply to nonce-based replay protection). 3308 The style of replay protection in effect between a mobile node 3309 and its home agent is part of the mobile security association. A 3310 mobile node and its home agent MUST agree on which method of replay 3311 protection will be used. The interpretation of the Identification 3312 field depends on the method of replay protection as described in the 3313 subsequent subsections. 3315 Whatever method is used, the low-order 32 bits of the Identification 3316 MUST be copied unchanged from the Registration Request to the 3317 Reply. The foreign agent uses those bits (and the mobile node's 3318 home address) to match Registration Requests with corresponding 3319 replies. The mobile node MUST verify that the low-order 32 bits 3320 of any Registration Reply are identical to the bits it sent in the 3321 Registration Request. 3323 The Identification in a new Registration Request MUST NOT be the same 3324 as in an immediately preceding Request, and SHOULD NOT repeat while 3325 the same security context is being used between the mobile node and 3326 the home agent. Retransmission as in Section 3.6.3 is allowed. 3328 5.6.1. Replay Protection using Timestamps 3330 The basic principle of timestamp replay protection is that the node 3331 generating a message inserts the current time of day, and the node 3332 receiving the message checks that this timestamp is sufficiently 3333 close to its own time of day. Unless specified differently in 3334 the security association between the nodes, a default value of 3335 7 seconds MAY be used to limit the time difference. This value 3336 SHOULD be greater than 3 seconds. Obviously the two nodes must have 3337 adequately synchronized time-of-day clocks. As with any messages, 3338 time synchronization messages may be protected against tampering 3339 by an authentication mechanism determined by the security context 3340 between the two nodes. 3342 If timestamps are used, the mobile node MUST set the Identification 3343 field to a 64-bit value formatted as specified by the Network Time 3344 Protocol [20]. The low-order 32 bits of the NTP format represent 3345 fractional seconds, and those bits which are not available from a 3346 time source SHOULD be generated from a good source of randomness. 3347 Note, however, that when using timestamps, the 64-bit Identification 3348 used in a Registration Request from the mobile node MUST be greater 3349 than that used in any previous Registration Request, as the home 3350 agent uses this field also as a sequence number. Without such a 3351 sequence number, it would be possible for a delayed duplicate of an 3352 earlier Registration Request to arrive at the home agent (within 3353 the clock synchronization required by the home agent), and thus be 3354 applied out of order, mistakenly altering the mobile node's current 3355 registered care-of address. 3357 Upon receipt of a Registration Request with an authorization-enabling 3358 extension, the home agent MUST check the Identification field for 3359 validity. In order to be valid, the timestamp contained in the 3360 Identification field MUST be close enough to the home agent's time 3361 of day clock and the timestamp MUST be greater than all previously 3362 accepted timestamps for the requesting mobile node. Time tolerances 3363 and resynchronization details are specific to a particular mobility 3364 security association. 3366 If the timestamp is valid, the home agent copies the entire 3367 Identification field into the Registration Reply it returns the Reply 3368 to the mobile node. If the timestamp is not valid, the home agent 3369 copies only the low-order 32 bits into the Registration Reply, and 3370 supplies the high-order 32 bits from its own time of day. In this 3371 latter case, the home agent MUST reject the registration by returning 3372 Code 133 (identification mismatch) in the Registration Reply. 3374 As described in Section 3.6.2.1, the mobile node MUST verify that the 3375 low-order 32 bits of the Identification in the Registration Reply are 3376 identical to those in the rejected registration attempt, before using 3377 the high-order bits for clock resynchronization. 3379 5.6.2. Replay Protection using Nonces 3381 Implementors of this optional mechanism should examine Appendix A.2 3382 for a patent that may be applicable to nonce-based replay protection. 3384 The basic principle of nonce replay protection is that node A 3385 includes a new random number in every message to node B, and 3386 checks that node B returns that same number in its next message to 3387 node A. Both messages use an authentication code to protect against 3388 alteration by an attacker. At the same time node B can send its own 3389 nonces in all messages to node A (to be echoed by node A), so that it 3390 too can verify that it is receiving fresh messages. 3392 The home agent may be expected to have resources for computing 3393 pseudo-random numbers useful as nonces [11]. It inserts a new nonce 3394 as the high-order 32 bits of the identification field of every 3395 Registration Reply. The home agent copies the low-order 32 bits 3396 of the Identification from the Registration Request message into 3397 the low-order 32 bits of the Identification in the Registration 3398 Reply. When the mobile node receives an authenticated Registration 3399 Reply from the home agent, it saves the high-order 32 bits of 3400 the identification for use as the high-order 32 bits of its next 3401 Registration Request. 3403 The mobile node is responsible for generating the low-order 32 bits 3404 of the Identification in each Registration Request. Ideally it 3405 should generate its own random nonces. However it may use any 3406 expedient method, including duplication of the random value sent by 3407 the home agent. The method chosen is of concern only to the mobile 3408 node, because it is the node that checks for valid values in the 3409 Registration Reply. The high-order and low-order 32 bits of the 3410 identification chosen SHOULD both differ from their previous values. 3411 The home agent uses a new high-order value and the mobile node uses 3412 a new low-order value for each registration message. The foreign 3413 agent uses the low-order value (and the mobile host's home address) 3414 to correctly match registration replies with pending Requests 3415 (Section 3.7.1). 3417 If a registration message is rejected because of an invalid nonce, 3418 the Reply always provides the mobile node with a new nonce to 3419 be used in the next registration. Thus the nonce protocol is 3420 self-synchronizing. 3422 6. IANA Considerations 3424 Mobile IP specifies several new number spaces for values to be used 3425 in various message fields. These number spaces are as follows: 3427 - types of messages sent to UDP port 434 3429 - types of extensions to router advertisements and solicitations 3430 (see section 2.1) 3432 - types of extensions to Registration Request and Registration 3433 Reply messages (see [21, 22] and, in this document, section 3.5) 3435 - values for the Code in the Registration Reply message 3436 (see [21, 22] and, in this document, section 3.4) 3438 See appendix G for the currently defined values for these parameter 3439 spaces. 3441 7. Acknowledgments 3443 Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp 3444 and John Ioannidis (JI) (Columbia), for forming the working group, 3445 chairing it, and putting so much effort into its early development. 3447 Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim 3448 Solomon, and Erik Nordmark for their contributions to the group while 3449 performing the duties of chairperson, as well as for their many 3450 useful comments. 3452 Thanks to the active members of the Mobile IP Working Group, 3453 particularly those who contributed text, including (in alphabetical 3454 order) 3456 - Ran Atkinson (Naval Research Lab), 3457 - Samita Chakrabarti (Sun Microsystems) 3458 - Dave Johnson (Carnegie Mellon University), 3459 - Frank Kastenholz (FTP Software), 3460 - Anders Klemets (KTH), 3461 - Chip Maguire (KTH), 3462 - Andrew Myles (Macquarie University), 3463 - Al Quirt (Bell Northern Research), 3464 - Yakov Rekhter (IBM), and 3465 - Fumio Teraoka (Sony). 3467 Thanks to Charlie Kunzinger and to Bill Simpson, the editors who 3468 produced the first drafts for of this document, reflecting the 3469 discussions of the Working Group. Much of the new text in the latest 3470 drafts is due to Jim Solomon and Dave Johnson. 3472 Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank 3473 Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for 3474 their generous support in hosting interim Working Group meetings. 3476 A. Patent Issues 3478 As of the time of publication, the IETF had been made aware of 3479 two patents that may be relevant to implementors of the protocol 3480 described in this technical specification. 3482 A.1. IBM Patent #5,159,592 3484 Charles Perkins, editor of this draft, is sole inventor of 3485 U.S. Patent No. 5,159,592, assigned to IBM. In a letter dated 3486 May 30, 1995, IBM brought this patent to the attention of the IETF, 3487 stating that this patent "relates to the Mobile IP." We understand 3488 that IBM did not intend to assert that any particular implementation 3489 of Mobile IP would or would not infringe the patent, but rather that 3490 IBM was meeting what it viewed as a duty to disclose information that 3491 could be relevant to the process of adopting a standard. 3493 Based on a review of the claims of the patent, IETF believes that 3494 a system of registering an address obtained from a foreign agent, 3495 as described in the draft, would not necessarily infringe any of 3496 the claims of the patent; and that a system in which an address is 3497 obtained elsewhere and then registered can be implemented without 3498 necessarily infringing any claims of the patent. Accordingly, 3499 our view is that the proposed protocol can be implemented without 3500 necessarily infringing the Perkins Patent. 3502 Parties considering adopting this protocol must be aware that 3503 some specific implementations, or features added to otherwise 3504 non-infringing implementations, may raise an issue of infringement 3505 with respect to this patent or to some other patent. 3507 This statement is for the IETF's assistance in its standard-setting 3508 procedure, and should not be relied upon by any party as an opinion 3509 or guarantee that any implementation it might make or use would 3510 not be covered by the Perkins Patent and any other patents. In 3511 particular, IBM might disagree with the interpretation of this patent 3512 described herein. 3514 A.2. IBM Patent #5,148,479 3516 This patent, also assigned to IBM, may be relevant to those 3517 who implement nonce-based replay protection as described in 3518 Section 5.6.2. Note that nonce-based replay protection is an 3519 optional feature of this specification. Timestamp-based replay 3520 protection, on the other hand, (Section 5.6.1) is a requirement of 3521 this specification. 3523 B. Link-Layer Considerations 3525 The mobile node MAY use link-layer mechanisms to decide that its 3526 point of attachment has changed. Such indications include the 3527 Down/Testing/Up interface status [18], and changes in cell or 3528 administration. The mechanisms will be specific to the particular 3529 link-layer technology, and are outside the scope of this document. 3531 The Point-to-Point-Protocol (PPP) [36] and its Internet Protocol 3532 Control Protocol (IPCP) [19], negotiates the use of IP addresses. 3534 The mobile node SHOULD first attempt to specify its home address, 3535 so that if the mobile node is attaching to its home network, the 3536 unrouted link will function correctly. When the home address is 3537 not accepted by the peer, but a transient IP address is dynamically 3538 assigned to the mobile node, and the mobile node is capable of 3539 supporting a co-located care-of address, the mobile node MAY 3540 register that address as a co-located care-of address. When the peer 3541 specifies its own IP address, that address MUST NOT be assumed to be 3542 a foreign agent care-of address or the IP address of a home agent. 3544 C. TCP Considerations 3546 C.1. TCP Timers 3548 Most hosts and routers which implement TCP/IP do not permit easy 3549 configuration of the TCP timer values. When high-delay (e.g., 3550 SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are 3551 in use, the default TCP timer values in many systems may cause 3552 retransmissions or timeouts, even when the link and network are 3553 actually operating properly with greater than usual delays because 3554 of the medium in use. This can cause an inability to create or 3555 maintain TCP connections over such links, and can also cause unneeded 3556 retransmissions which consume already scarce bandwidth. Vendors are 3557 encouraged to make TCP timers more configurable. Vendors of systems 3558 designed for the mobile computing markets should pick default timer 3559 values more suited to low-bandwidth, high-delay links. Users of 3560 mobile nodes should be sensitive to the possibility of timer-related 3561 difficulties. 3563 C.2. TCP Congestion Management 3565 Mobile nodes often use media which are more likely to introduce 3566 errors, effectively causing more packets to be dropped. This 3567 introduces a conflict with the mechanisms for congestion management 3568 found in modern versions of TCP [15]. Now, when a packet is dropped, 3569 the correspondent node's TCP implementation is likely to react as 3570 if there were a source of network congestion, and initiate the 3571 slow-start mechanisms [15] designed for controlling that problem. 3572 However, those mechanisms are inappropriate for overcoming errors 3573 introduced by the links themselves, and have the effect of magnifying 3574 the discontinuity introduced by the dropped packet. This problem 3575 has been analyzed by Caceres, et al. [3]; there is no easy solution 3576 available, and certainly no solution likely to be installed soon on 3577 all correspondent nodes. While this problem is beyond the scope 3578 of this document, it does illustrate that providing performance 3579 transparency to mobile nodes involves understanding mechanisms 3580 outside the network layer. It also indicates the need to avoid 3581 designs which systematically drop packets; such designs might 3582 otherwise be considered favorably when making engineering tradeoffs. 3584 D. Example Scenarios 3586 This section shows example Registration Requests for several common 3587 scenarios. 3589 D.1. Registering with a Foreign Agent Care-of Address 3591 The mobile node receives an Agent Advertisement from a foreign 3592 agent and wishes to register with that agent using the advertised 3593 foreign agent care-of address. The mobile node wishes only 3594 IP-in-IP encapsulation, does not want broadcasts, and does not want 3595 simultaneous mobility bindings: 3597 IP fields: 3598 Source Address = mobile node's home address 3599 Destination Address = copied from the IP source address of the 3600 Agent Advertisement 3601 Time to Live = 1 3602 UDP fields: 3603 Source Port = 3604 Destination Port = 434 3605 Registration Request fields: 3606 Type = 1 3607 S=0,B=0,D=0,M=0,G=0 3608 Lifetime = the Registration Lifetime copied from the 3609 Mobility Agent Advertisement Extension of the 3610 Router Advertisement message 3611 Home Address = the mobile node's home address 3612 Home Agent = IP address of mobile node's home agent 3613 Care-of Address = the Care-of Address copied from the 3614 Mobility Agent Advertisement Extension of the 3615 Router Advertisement message 3616 Identification = Network Time Protocol timestamp or Nonce 3617 Extensions: 3618 An authorization-enabling extension (e.g., the 3619 Mobile-Home Authentication Extension) 3621 D.2. Registering with a Co-Located Care-of Address 3623 The mobile node enters a foreign network that contains no foreign 3624 agents. The mobile node obtains an address from a DHCP server [10] 3625 for use as a co-located care-of address. The mobile node supports 3626 all forms of encapsulation (IP-in-IP, minimal encapsulation, and 3627 GRE), desires a copy of broadcast datagrams on the home network, and 3628 does not want simultaneous mobility bindings: 3630 IP fields: 3631 Source Address = care-of address obtained from DHCP server 3632 Destination Address = IP address of home agent 3633 Time to Live = 64 3634 UDP fields: 3635 Source Port = 3636 Destination Port = 434 3637 Registration Request fields: 3638 Type = 1 3639 S=0,B=1,D=1,M=1,G=1 3640 Lifetime = 1800 (seconds) 3641 Home Address = the mobile node's home address 3642 Home Agent = IP address of mobile node's home agent 3643 Care-of Address = care-of address obtained from DHCP server 3644 Identification = Network Time Protocol timestamp or Nonce 3645 Extensions: 3646 The Mobile-Home Authentication Extension 3648 D.3. Deregistration 3650 The mobile node returns home and wishes to deregister all care-of 3651 addresses with its home agent. 3653 IP fields: 3654 Source Address = mobile node's home address 3655 Destination Address = IP address of home agent 3656 Time to Live = 1 3657 UDP fields: 3658 Source Port = 3659 Destination Port = 434 3660 Registration Request fields: 3661 Type = 1 3662 S=0,B=0,D=0,M=0,G=0 3663 Lifetime = 0 3664 Home Address = the mobile node's home address 3665 Home Agent = IP address of mobile node's home agent 3666 Care-of Address = the mobile node's home address 3667 Identification = Network Time Protocol timestamp or Nonce 3668 Extensions: 3669 An authorization-enabling extension (e.g., the 3670 Mobile-Home Authentication Extension) 3672 E. Applicability of Prefix-Lengths Extension 3674 Caution is indicated with the use of the Prefix-Lengths Extension 3675 over wireless links, due to the irregular coverage areas provided by 3676 wireless transmitters. As a result, it is possible that two foreign 3677 agents advertising the same prefix might indeed provide different 3678 connectivity to prospective mobile nodes. The Prefix-Lengths 3679 Extension SHOULD NOT be included in the advertisements sent by agents 3680 in such a configuration. 3682 Foreign agents using different wireless interfaces would have to 3683 cooperate using special protocols to provide identical coverage 3684 in space, and thus be able to claim to have wireless interfaces 3685 situated on the same subnetwork. In the case of wired interfaces, 3686 a mobile node disconnecting and subsequently connecting to a new 3687 point of attachment, may well send in a new Registration Request 3688 no matter whether the new advertisement is on the same medium as 3689 the last recorded advertisement. And, finally, in areas with dense 3690 populations of foreign agents it would seem unwise to require the 3691 propagation via routing protocols of the subnet prefixes associated 3692 with each individual wireless foreign agent; such a strategy could 3693 lead to quick depletion of available space for routing tables, 3694 unwarranted increases in the time required for processing routing 3695 updates, and longer decision times for route selection if routes 3696 (which are almost always unnecessary) are stored for wireless 3697 "subnets". 3699 F. Changes since RFC 2002 3701 This section details differences between the original Mobile IP base 3702 specification (RFC 2002 and ff.) that have been made as part of this 3703 revised protocol specification for Mobile IP. 3705 F.1. Changes since revision 02 of RFC2002bis 3707 This section lists the changes between this version (...-03.txt) and 3708 the previous version of the document. 3710 - Added a separate item describing the reserved 'r' bit in the 3711 Agent Advertisement extension and the Registration Request 3712 message. 3713 - Changed "admissible authentication extension" to 3714 "authorization-enabling extension". This removes the 3715 ambiguity by which it might otherwise have been possible 3716 to interpret Mobile-Foreign or Foreign-Home authentication 3717 extensions as "inadmissible". 3719 - Inserted 'T' bit into its proper place in the Registration 3720 Request message format (section 3.3). Changed the 'rsv' tag for 3721 the reserved field to be labeled 'x' instead, to make room for 3722 the 'T' bit. 3723 - Changed the preconfiguration requirements in section 3.6 for the 3724 mobile node to reflect the capability, specified in RFC 2794 [4], 3725 for the mobile node to identify itself by using its NAI, and then 3726 getting a home address from the Registration Reply. 3727 - Changed section 3.7.3.1 so that a foreign agent is not required 3728 to discard Registration Replies that have a Home Address field 3729 that does not match any pending Registration Request. 3731 F.2. Changes Preceding Revision 02 of RFC2002bis 3733 This section lists the changes up to and including those contained 3734 in the previous version of the document, but not the changes made 3735 between the previous version and this version of the document. 3737 - Allowed registrations to be authenticated by use of a security 3738 association between the mobile node and a suitable authentication 3739 entity acceptable to the home agent. Defined "Admissible 3740 Authentication extension" to be an authentication extension that 3741 makes a registration message acceptable to the recipient. 3742 - Allowed registration replies to be processed by the mobile node, 3743 even in the absence of any Mobile-Home Authentication extension, 3744 when containing rejection code by the foreign agent. 3745 - Specified that the mobile node SHOULD take the first care-of 3746 address in a list offered by a foreign agent, and MAY try 3747 each subsequent advertised address in turn if the attempted 3748 registrations are rejected by the foreign agent 3749 - Eliminated Van-Jacobson Compression feature 3750 - Updated assigned numbers lists 3751 - Specification that foreign agents SHOULD support reverse 3752 tunneling, and home agents MUST support decapsulation of reverse 3753 tunnels. 3754 - Specification that foreign agents MAY send advertisements at 3755 a rate faster than once per second, but chosen so that the 3756 advertisements do not burden the capacity of the local link. For 3757 simplicity, the foreign agent now MAY send advertisements at an 3758 interval less than 1/3 the advertised ICMP Lifetime. 3759 - Clarification that a mobility agent MAY use different settings 3760 for each of the 'R', 'H', and 'F' bits on different network 3761 interfaces. 3762 - Clarification that a mobility agent SHOULD only put its own 3763 addresses into the initial (i.e., not mobility-related) list of 3764 routers in the mobility advertisement. RFC 2002 suggests that a 3765 mobility agent might advertise other default routers. 3767 - Specification that a mobile node MUST ignore reserved bits 3768 in Agent Advertisements, as opposed to discarding such 3769 advertisements. In this way, new bits can be defined later, 3770 without affecting the ability for mobile nodes to use the 3771 advertisements even when the newly defined bits are not 3772 understood. Furthermore, foreign agents can set the `R' bit to 3773 make sure that new bits are handled by themselves instead of some 3774 legacy mobility agent. 3775 - Specification that the SPI of the MN-HA authentication extension 3776 is to be used as part of the data over which the authentication 3777 algorithm must be computed. 3778 - Specification that the foreign agent MAY configure a maximum 3779 number of pending registrations that it is willing to maintain 3780 (typically 5). Additional registrations SHOULD then be rejected 3781 by the foreign agent with code 66. The foreign agent MAY delete 3782 any pending Registration Request after the request has been 3783 pending for more than 7 seconds; in this case, the foreign agent 3784 SHOULD reject the Request with code 78 (registration timeout). 3785 - Specification that the foreign agent checks to make sure that 3786 the indicated home agent address does not belong to any of its 3787 network interfaces before relaying a Registration Request. If 3788 the check fails, and the foreign agent is not the mobile node's 3789 home agent, then the foreign agent rejects the request with code 3790 136 (unknown home agent address). 3791 - Specification that Registration Requests with the 'D' bit set to 3792 0, and specifying a care-of address not offered by the foreign 3793 agent, MUST be rejected with code 77 (invalid care-of address). 3794 - Clarification that the foreign agent SHOULD consider its 3795 own maximum value when handling the Lifetime field of the 3796 Registration Reply. 3797 - Clarification that the home agent MUST ignore the setting of the 3798 'V' bit in any Registration Request, since it is only relevant to 3799 the foreign agent. 3800 - Clarification that the home agent MUST ignore the 'B' bit (as 3801 opposed to rejecting the Registration Request) if it does not 3802 support broadcasts. 3803 - Advice about the impossibility of using dynamic home agent 3804 discovery in the case when routers change the IP destination 3805 address of a datagram from a subnet-directed broadcast address to 3806 255.255.255.255 before injecting it into the destination subnet. 3807 - Specification that the mobile node MAY use the IP source address 3808 of an agent advertisement as its default router address. 3809 - Specification that, while they are away from the home network, 3810 mobile nodes MUST NOT broadcast ARP packets to find the MAC 3811 address of another Internet node. Thus, the (possibly empty) 3812 list of Router Addresses from the ICMP Router Advertisement 3813 portion of the message is not useful for selecting a default 3814 router, unless the mobile node has some means not involving 3815 broadcast ARP and not specified within this document for 3816 obtaining the MAC address of one of the routers in the list. 3817 Similarly, in the absence of unspecified mechanisms for obtaining 3818 MAC addresses on foreign networks, the mobile node MUST ignore 3819 redirects to other routers on foreign networks. 3820 - Specification that a foreign agent MUST NOT use broadcast ARP 3821 for a mobile node's MAC address on a foreign network. It may 3822 obtain the MAC address by copying the information from an Agent 3823 Solicitation or a Registration Request transmitted from a mobile 3824 node. 3825 - Specification that a foreign agent's ARP cache for the mobile 3826 node's IP address MUST NOT be allowed to expire before the mobile 3827 node's visitor list entry expires, unless the foreign agent has 3828 some way other than broadcast ARP to refresh its MAC address 3829 associated to the mobile node's IP address. 3830 - Relaxation of the requirement that, when a mobile node has joined 3831 multicast group at the router on the foreign network, the mobile 3832 node MUST use its home address as the source IP address for 3833 multicast packets, 3834 - Replacement of the terminology "recursive tunneling" by the 3835 terminology "nested tunneling". 3836 - Clarification that keys with arbitrary binary values MUST be 3837 supported as part of mobility security associations. 3838 - Specification that the default value may be chosen as 7 seconds, 3839 for allowable time skews between a home agent and mobile node 3840 using timestamps for replay protection. Further specification 3841 that this value SHOULD be greater than 3 seconds. 3842 - Specification that multihomed home agents MUST use the registered 3843 care-of address as the source address in the outer IP header of 3844 the encapsulated datagram. 3845 - Added IANA Considerations section 3846 - Added appendix with current number assignments, intended to 3847 update 3848 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers 3849 - Wordsmithing 3850 - Correction of syntactic editorial mistakes 3851 - Updated citations 3853 G. Number Assignments 3855 The information about assignment of numbers, given by IANA at 3856 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers 3857 from the various Mobile IP number spaces is out of date. It should 3858 be reorganized according to the recipe given in section 6. The 3859 current values are as given in the following subsections. All 3860 bracketed references are given in the bibliography. Unbracketed 3861 numbers refer to sections of this document. 3863 G.1. Mobile IP Message Types 3865 Mobile IP messages are defined to be those that are sent to a message 3866 recipient at port 434 (UDP or TCP). 3868 Type Name Reference 3869 ---- -------------------------------------------- --------- 3870 1 Registration Request [24] 3871 3 Registration Reply [24] 3873 G.2. Extensions to RFC 1256 Router Advertisement 3874 Type Name Reference 3875 ---- -------------------------------------------- --------- 3876 0 One-byte Padding 2.1.3 3877 16 Mobility Agent Advertisement 2.1.1 3878 19 Prefix-Lengths 2.1.2 3880 G.3. Extensions to Mobile IP Registration Messages 3881 Type Name Reference 3882 ---- -------------------------------------------- --------- 3883 0 One-byte Padding 3884 32 Mobile-Home Authentication 3.5.2 3885 33 Mobile-Foreign Authentication 3.5.3 3886 34 Foreign-Home Authentication 3.5.4 3887 129 Traversal Extension [22] 3888 130 Encapsulating Delivery Style Extension [21] 3889 131 The Mobile Node NAI Extension [4] 3891 G.4. Code Values for Mobile IP Registration Reply Messages 3893 The Code values in this section are divided in several major groups: 3895 0-8 Success Codes 3896 64-128 Error Codes from the Foreign Agent 3897 128-192 Error Codes from the Home Agent 3899 Type Description Reference 3900 ---- -------------------------------------------- --------- 3901 0 registration accepted 3902 1 registration accepted without simultaneous bindings 3904 64 reason unspecified 3905 65 administratively prohibited 3906 66 insufficient resources 3907 67 mobile node failed authentication 3908 68 home agent failed authentication 3909 69 requested Lifetime too long 3910 70 poorly formed Request 3911 71 poorly formed Reply 3912 72 requested encapsulation unavailable 3913 73 reserved and unavailable 3914 74 requested reverse tunnel unavailable [21] 3915 75 reverse tunnel is mandatory and 'T' bit not set [21] 3916 76 mobile node too distant [21] 3917 77 invalid care-of address 3918 78 registration timeout 3919 80 home network unreachable (ICMP error received) 3920 81 home agent host unreachable (ICMP error received) 3921 82 home agent port unreachable (ICMP error received) 3922 88 home agent unreachable (other ICMP error received) 3923 96 nonzero homeaddr required [4] 3924 97 missing NAI [4] 3925 98 missing home agent [4] 3926 99 missing home address [4] 3928 128 reason unspecified 3929 129 administratively prohibited 3930 130 insufficient resources 3931 131 mobile node failed authentication 3932 132 foreign agent failed authentication 3933 133 registration Identification mismatch 3934 134 poorly formed Request 3935 135 too many simultaneous mobility bindings 3936 136 unknown home agent address 3937 137 requested reverse tunnel unavailable [21] 3938 138 reverse tunnel is mandatory and 'T' bit not set [21] 3939 139 requested encapsulation unavailable [21] 3941 H. Proposed Number Assignments 3943 Several Internet Drafts are under consideration by the mobile-ip 3944 working group. In this section, the numbers that are suggested for 3945 use in those working group documents are listed. 3947 Notice that listing in this section DOES NOT indicate endorsement by 3948 the working group, or eventual adoption as standard. In fact, as of 3949 this writing, some of the values overlap, and other values remain 3950 unspecified in the working group document. All values are given for 3951 reference only, and should be considered TBD. 3953 H.1. Proposed Extensions to RFC 1256 Router Advertisement 3955 The numbers in this section are enumerated only as a courtesy to 3956 future writers of Internet Drafts. Authors of new Internet Drafts 3957 MAY, of course, use the numbers listed here, as deemed appropriate by 3958 the then-current members of the working group. Citations included in 3959 this section are NOT to be considered normative references. 3961 Type Name Reference 3962 ---- -------------------------------------------- --------- 3963 24 Challenge [5] 3965 H.2. Proposed New Mobile IP Message Types 3967 The following new messages types are proposed to be recognized by 3968 Mobile IP entities that receive them at port 434. 3970 Type Name Reference 3971 ---- -------------------------------------------- --------- 3972 2 Regional Registration Request message [12] 3973 4 Regional Registration Reply message [12] 3974 16 Binding Warning message [27] 3975 17 Binding Request message [27] 3976 18 Binding Update message [27] 3977 19 Binding Acknowledge message [27] 3978 20 Registration Update [14] 3979 21 Registration Acknowledge [14] 3981 Note that messages 20 and 21 are currently specified for delivery to 3982 port 697, which is not covered by this document. 3984 H.3. Proposed Extensions to Mobile IP Registration Messages 3986 Type Name Reference 3987 ---- -------------------------------------------- --------- 3988 16 Binding Warning [27] 3989 24 GFA IP Address [12] 3990 25 Hierarchical Foreign Agent [12] 3991 26 Replay Protection Style [12] 3992 36 Generalized Mobile IP Authentication [5] 3993 38 Critical Vendor/Organization Specific [9] 3994 39 Session Specific Extension [14] 3995 40 Generalized Registration Key Request [26] 3996 41 Generalized Mobile IP MN-FA Key Reply [26] 3997 43 Generalized Mobile IP MN-HA Key Reply [26] 3998 45 Generalized Mobile IP FA-HA Key Reply [26] 3999 46 Generalized Mobile IP FA-FA Key Reply [26] 4000 96 Previous Foreign Agent Notification [27] 4001 132 MN-FA Challenge [5] 4002 134 Normal Vendor/Organization Specific [9] 4004 H.4. Proposed Code Values for Mobile IP Registration Reply Messages 4006 Type Description Reference 4007 ---- -------------------------------------------- --------- 4009 90 Unknown GFA [12] 4010 91 GFA Unreachable [12] 4011 92 GFA Host Unreachable [12] 4012 93 GFA Port Unreachable [12] 4013 94 Replay Protection Unavailable [12] 4014 104 Unknown Challenge [5] 4015 105 Missing Challenge [5] 4016 106 Stale Challenge [5] 4017 107 Missing MN-FA Authentication [28] 4018 107 MN-FA Unsupported Vendor Ext [9] 4019 108 HA-FA Unsupported Vendor Ext [9] 4021 141 MN-HA Unsupported Vendor Ext [9] 4022 142 HA-MN Unsupported Vendor Ext [9] 4023 144 Zero Care-of Address [9] 4025 Notice that, for proposed Code 94, the issuing mobility agent is the 4026 "Gateway Foreign Agent" (GFA), which is a specific kind of foreign 4027 agent proposed in [12]. 4029 H.5. Proposed SPI Values for the Mobile IP Reserved SPIs 4031 Mobile IP uses 32-bit SPIs. The first 256 values have been reserved 4032 for specific uses, not for general use when identifying arbitrary 4033 security associations between mobile nodes and mobility agents. 4034 The values in the table have been proposed to be allocated for the 4035 indicated purposes. 4037 Type Description Reference 4038 ---- -------------------------------------------- --------- 4039 2 CHAP [5, 35] 4040 3 MD5/prefix+suffix [28, 24] 4041 4 HMAC MD5 [28, 17] 4043 H.6. Proposed Subtypes for the Generalized Authentication Extension 4045 A Generalized Authentication Extension [5] has been proposed for 4046 Mobile IP. The following values identify subtypes that have been 4047 proposed for the generalized extension. 4049 Type Description Reference 4050 ---- -------------------------------------------- --------- 4051 1 MN-AAA subtype [5] 4052 4 FA-FA subtype [12] 4053 5 MN-GFA subtype [12] 4055 I. Example Messages 4057 I.1. Example ICMP Agent Advertisement Message Format 4059 0 1 2 3 4060 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 4061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4062 | Type | Code | Checksum | 4063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4064 | Num Addrs |Addr Entry Size| Lifetime | 4065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4066 | Router Address[1] | 4067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4068 | Preference Level[1] | 4069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4070 | Router Address[2] | 4071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4072 | Preference Level[2] | 4073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4074 | .... | 4075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4076 | Type = 16 | Length | Sequence Number | 4077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4078 | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | 4079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4080 | Care-of Address[1] | 4081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4082 | Care-of Address[2] | 4083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4084 | .... | 4085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4086 : Optional Extensions : 4087 : .... ...... ...... : 4088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4090 I.2. Example Registration Request Message Format 4092 The UDP header is followed by the Mobile IP fields shown below: 4094 0 1 2 3 4095 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 4096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4097 | Type = 1 |S|B|D|M|G|r|T|x| Lifetime | 4098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4099 | Home Address | 4100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4101 | Home Agent | 4102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4103 | Care-of Address | 4104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4105 | | 4106 + Identification + 4107 | | 4108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4109 | Optional Non-Auth Extensions for HA ... | 4110 | ( variable length ) | 4111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4112 | Type =32 | Length | SPI | 4113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4114 | SPI (cont..) | | 4115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4116 : MN-HA Authenticator ( variable length ) : 4117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4118 : Optional Non-Auth Extensions for FA ......... 4119 : Optional MN-FA Authentication Extension... 4120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4122 I.3. Example Registration Reply Message Format 4124 The UDP header is followed by the Mobile IP fields shown below: 4126 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 4127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4128 | Type = 3 | Code | Lifetime | 4129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4130 | Home Address | 4131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4132 | Home Agent | 4133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4134 | | 4135 + Identification + 4136 | | 4137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4138 | Optional HA Non-Auth Extensions ... | 4139 | ( variable length ) | 4140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4141 | Type =32 | Length | SPI | 4142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4143 | SPI (cont...) | | 4144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4145 : MN-HA Authenticator ( variable length ) : 4146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4147 : Optional Extensions used by FA......... 4148 : Optional MN-FA Authentication Extension... 4149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4151 References 4153 [1] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. 4154 ACM Computer Communications Review, 19(2), March 1989. 4156 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 4157 Levels. Request for Comments (Best Current Practice) 2119, 4158 Internet Engineering Task Force, March 1997. 4160 [3] Ramon Caceres and Liviu Iftode. Improving the Performance 4161 of Reliable Transport Protocols in Mobile Computing 4162 Environments. IEEE Journal on Selected Areas in Communications, 4163 13(5):850--857, June 1995. 4165 [4] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 4166 Extension for IPv4. Request for Comments (Proposed Standard) 4167 2794, Internet Engineering Task Force, January 2000. 4169 [5] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 4170 Challenge/Response Extension (work in progress). 4171 draft-ietf-mobileip-challenge-13.txt, June 2000. 4173 [6] D. Cong, M. Hamlen, and C. Perkins. The Definitions of Managed 4174 Objects for IP Mobility Support using SMIv2. Request for 4175 Comments (Proposed Standard) 2006, Internet Engineering Task 4176 Force, October 1996. 4178 [7] S. Deering. ICMP Router Discovery Messages. Request for 4179 Comments (Proposed Standard) 1256, Internet Engineering Task 4180 Force, September 1991. 4182 [8] S. E. Deering. Host extensions for IP multicasting. Request 4183 for Comments (Standard) 1112, Internet Engineering Task Force, 4184 August 1989. 4186 [9] Gopal Dommety and Kent Leung. Mobile IP Vendor/ 4187 Organization-Specific Extensions (work in progress). 4188 draft-ietf-mobileip-vendor-ext-09.txt, November 1999. 4190 [10] R. Droms. Dynamic Host Configuration Protocol. Request for 4191 Comments (Draft Standard) 2131, Internet Engineering Task Force, 4192 March 1997. 4194 [11] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 4195 Recommendations for Security. Request for Comments 4196 (Informational) 1750, Internet Engineering Task Force, December 4197 1994. 4199 [12] Eva Gustafsson, A. Jonsson, and C. Perkins. Mobile IP Regional 4200 Registration. draft-ietf-mobileip-regtun-03.txt, July 2000. 4201 (work in progress). 4203 [13] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 4204 Encapsulation (GRE). Request for Comments (Informational) 1701, 4205 Internet Engineering Task Force, October 1994. 4207 [14] T. Hiller, C. Lo, P. Walsh, A. Hameed, M. Munson, B. Lim, 4208 A. Casati, P. McCann, J. Wang, B. Hirschman, P. Roberts, 4209 S. Manning, R. Hsu, K. Singh, M. Lipford, P. Calhoun, 4210 E. Campbell, K. Peirce, and Y. Xu. 3G Wireless Data Provider 4211 Architecture Using Mobile IP and AAA. Internet Draft, Internet 4212 Engineering Task Force, March 1999. 4214 [15] Van Jacobson. Congestion Avoidance and Control. In 4215 Proceedings, SIGCOMM '88 Workshop, pages 314--329. ACM Press, 4216 August 1988. Stanford, CA. 4218 [16] S. Kent and R. Atkinson. IP Authentication Header. Request for 4219 Comments (Proposed Standard) 2402, Internet Engineering Task 4220 Force, November 1998. 4222 [17] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 4223 for Message Authentication. Request for Comments 4224 (Informational) 2104, Internet Engineering Task Force, 4225 February 1997. 4227 [18] K. McCloghrie and F. Kastenholz. Evolution of the Interfaces 4228 Group of MIB-II. Request for Comments (Proposed Standard) 1573, 4229 Internet Engineering Task Force, January 1994. 4231 [19] G. McGregor. The PPP Internet Protocol Control Protocol 4232 (IPCP). Request for Comments (Proposed Standard) 1332, Internet 4233 Engineering Task Force, May 1992. 4235 [20] David L. Mills. Network Time Protocol (Version 3) 4236 Specification, Implementation. Request for Comments (Draft 4237 Standard) 1305, Internet Engineering Task Force, March 1992. 4239 [21] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 4240 Comments (Proposed Standard) 2344, Internet Engineering Task 4241 Force, May 1998. 4243 [22] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 4244 Mobile IP. Request for Comments (Informational) 2356, Internet 4245 Engineering Task Force, June 1998. 4247 [23] C. Perkins. IP Encapsulation within IP. Request for Comments 4248 (Proposed Standard) 2003, Internet Engineering Task Force, 4249 October 1996. 4251 [24] C. Perkins. IP Mobility Support. Request for Comments 4252 (Proposed Standard) 2002, Internet Engineering Task Force, 4253 October 1996. 4255 [25] C. Perkins. Minimal Encapsulation within IP. Request for 4256 Comments (Proposed Standard) 2004, Internet Engineering Task 4257 Force, October 1996. 4259 [26] C. Perkins and P. Calhoun. Generalized Key Distribution 4260 Extensions for Mobile IP (work in progress). 4261 draft-ietf-mobileip-gen-key-02.txt, July 2000. 4263 [27] C. E. Perkins and D. Johnson. Route Optimization in Mobile IP 4264 (work in progress). 4265 draft-ietf-mobileip-optim-09.txt, February 2000. 4267 [28] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys 4268 for Mobile IP (work in progress). 4269 draft-ietf-mobileip-aaa-key-03.txt, September 2000. 4271 [29] D. C. Plummer. Ethernet Address Resolution Protocol: Or 4272 converting network protocol addresses to 48.bit Ethernet address 4273 for transmission on Ethernet hardware. Request for Comments 4274 (Standard) 826, Internet Engineering Task Force, November 1982. 4276 [30] J. Postel. User Datagram Protocol. Request for Comments 4277 (Standard) 768, Internet Engineering Task Force, August 1980. 4279 [31] J. Postel. Internet Protocol. Request for Comments (Standard) 4280 791, Internet Engineering Task Force, September 1981. 4282 [32] J. Postel. Multi-LAN address resolution. Request for Comments 4283 925, Internet Engineering Task Force, October 1984. 4285 [33] J. Reynolds and J. Postel. Assigned Numbers. Request for 4286 Comments (Standard) 1700, Internet Engineering Task Force, 4287 October 1994. 4289 [34] R. Rivest. The MD5 Message-Digest Algorithm. Request for 4290 Comments (Informational) 1321, Internet Engineering Task Force, 4291 April 1992. 4293 [35] W. Simpson. PPP Challenge Handshake Authentication Protocol 4294 (CHAP). Request for Comments (Draft Standard) 1994, Internet 4295 Engineering Task Force, August 1996. 4297 [36] W. Simpson and Editor. The Point-to-Point Protocol (PPP). 4298 Request for Comments (Standard) 1661, Internet Engineering Task 4299 Force, July 1994. 4301 [37] J. Solomon. Applicability Statement for IP Mobility Support. 4302 Request for Comments (Proposed Standard) 2005, Internet 4303 Engineering Task Force, October 1996. 4305 [38] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The 4306 Protocols. Addison-Wesley, Reading, Massachusetts, 1994. 4308 Addresses 4310 The working group can be contacted via the current chairs: 4312 Basavaraj Patil Phil Roberts 4313 Nokia Corporation Motorola 4314 6000 Connection Drive 1501 West Shure Drive 4315 M/S M8-540 4316 Irving, Texas 75039 Arlington Heights, IL 60004 4317 USA USA 4318 Phone: +1 972-894-6709 Phone: +1 847-632-3148 4319 Fax : +1 972-894-5349 4320 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com 4322 Questions about this memo can also be directed to the editor: 4324 Charles E. Perkins 4325 Communications Systems Lab 4326 Nokia Research Center 4327 313 Fairchild Drive 4328 Mountain View, California 94043 4329 USA 4330 Phone: +1-650 625-2986 4331 EMail: charliep@iprg.nokia.com 4332 Fax: +1 650 625-2502