idnits 2.17.1 draft-ietf-mip4-rfc3344bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4679. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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 (July 9, 2007) is 6134 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) -- Looks like a reference, but probably isn't: 'M' on line 3777 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '10') ** Obsolete normative reference: RFC 1305 (ref. '11') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (ref. '14') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Unknown state RFC: RFC 925 (ref. '20') -- Possible downref: Non-RFC (?) normative reference: ref. '21' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '22') -- Obsolete informational reference (is this intentional?): RFC 2988 (ref. '27') (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 1573 (ref. '39') (Obsoleted by RFC 2233) -- Obsolete informational reference (is this intentional?): RFC 2002 (ref. '42') (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '43') (Obsoleted by RFC 5944) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group C. Perkins, Ed. 3 Internet-Draft NSN 4 Intended status: Standards Track July 9, 2007 5 Expires: January 10, 2008 7 IP Mobility Support for IPv4, revised 8 draft-ietf-mip4-rfc3344bis-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 any 24 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. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 10, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies protocol enhancements that allow transparent 42 routing of IP datagrams to mobile nodes in the Internet. Each mobile 43 node is always identified by its home address, regardless of its 44 current point of attachment to the Internet. While situated away 45 from its home, a mobile node is also associated with a care-of 46 address, which provides information about its current point of 47 attachment to the Internet. The protocol provides for registering 48 the care-of address with a home agent. The home agent sends 49 datagrams destined for the mobile node through a tunnel to the 50 care-of address. After arriving at the end of the tunnel, each 51 datagram is then delivered to the mobile node. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 5 57 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 59 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 60 1.5. New Architectural Entities . . . . . . . . . . . . . . . 7 61 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 62 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10 63 1.8. Message Format and Protocol Extensibility . . . . . . . . 14 64 1.9. Type-Length-Value Extension Format for Mobile IP 65 Extensions . . . . . . . . . . . . . . . . . . . . . . . 16 66 1.10. Long Extension Format . . . . . . . . . . . . . . . . . . 17 67 1.11. Short Extension Format . . . . . . . . . . . . . . . . . 18 68 2. Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . 19 69 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 19 70 2.1.1. Mobility Agent Advertisement Extension . . . . . . . 21 71 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . . . 23 72 2.1.3. One-byte Padding Extension . . . . . . . . . . . . . 24 73 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 25 74 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 25 75 2.3.1. Advertised Router Addresses . . . . . . . . . . . . . 26 76 2.3.2. Sequence Numbers and Rollover Handling . . . . . . . 26 77 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 27 78 2.4.1. Registration Required . . . . . . . . . . . . . . . . 28 79 2.4.2. Move Detection . . . . . . . . . . . . . . . . . . . 28 80 2.4.3. Returning Home . . . . . . . . . . . . . . . . . . . 29 81 2.4.4. Sequence Numbers and Rollover Handling . . . . . . . 29 82 3. Registration . . . . . . . . . . . . . . . . . . . . . . . . 31 83 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 31 84 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 33 85 3.3. Registration Request . . . . . . . . . . . . . . . . . . 33 86 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 36 87 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 39 88 3.5.1. Computing Authentication Extension Values . . . . . . 39 89 3.5.2. Mobile-Home Authentication Extension . . . . . . . . 40 90 3.5.3. Mobile-Foreign Authentication Extension . . . . . . . 41 91 3.5.4. Foreign-Home Authentication Extension . . . . . . . . 42 92 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 43 93 3.6.1. Sending Registration Requests . . . . . . . . . . . . 44 94 3.6.2. Receiving Registration Replies . . . . . . . . . . . 48 95 3.6.3. Registration Retransmission . . . . . . . . . . . . . 51 96 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 52 97 3.7.1. Configuration and Registration Tables . . . . . . . . 52 98 3.7.2. Receiving Registration Requests . . . . . . . . . . . 53 99 3.7.3. Receiving Registration Replies . . . . . . . . . . . 56 100 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 58 101 3.8.1. Configuration and Registration Tables . . . . . . . . 59 102 3.8.2. Receiving Registration Requests . . . . . . . . . . . 60 103 3.8.3. Sending Registration Replies . . . . . . . . . . . . 64 104 4. Routing Considerations . . . . . . . . . . . . . . . . . . . 67 105 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 67 106 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 67 107 4.2.1. Mobile Node Considerations . . . . . . . . . . . . . 67 108 4.2.2. Foreign Agent Considerations . . . . . . . . . . . . 68 109 4.2.3. Home Agent Considerations . . . . . . . . . . . . . . 69 110 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 70 111 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 71 112 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 72 113 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 74 114 5. Security Considerations . . . . . . . . . . . . . . . . . . . 78 115 5.1. Message Authentication Codes . . . . . . . . . . . . . . 78 116 5.2. Areas of Security Concern in this Protocol . . . . . . . 78 117 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 78 118 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 79 119 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 79 120 5.6. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 79 121 5.7. Replay Protection for Registration Requests . . . . . . . 80 122 5.7.1. Replay Protection using Timestamps . . . . . . . . . 80 123 5.7.2. Replay Protection using Nonces . . . . . . . . . . . 81 124 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 125 6.1. Mobile IP Message Types . . . . . . . . . . . . . . . . . 83 126 6.2. Extensions to RFC 1256 Router Advertisement . . . . . . . 84 127 6.3. Extensions to Mobile IP Registration Messages . . . . . . 84 128 6.4. Code Values for Mobile IP Registration Reply Messages . . 84 129 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 130 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 131 8.1. Normative References . . . . . . . . . . . . . . . . . . 88 132 8.2. Informative References . . . . . . . . . . . . . . . . . 89 133 Appendix A. Patent Issues . . . . . . . . . . . . . . . . . . . 92 134 Appendix B. Link-Layer Considerations . . . . . . . . . . . . . 93 135 Appendix C. TCP Considerations . . . . . . . . . . . . . . . . . 94 136 C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 94 137 C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 94 138 Appendix D. Example Scenarios . . . . . . . . . . . . . . . . . 95 139 D.1. Registering with a Foreign Agent Care-of Address . . . . 95 140 D.2. Registering with a Co-Located Care-of Address . . . . . . 95 141 D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 96 142 Appendix E. Applicability of Prefix-Lengths Extension . . . . . 97 143 Appendix F. Interoperability Considerations . . . . . . . . . . 98 144 Appendix G. Changes since RFC 2002 . . . . . . . . . . . . . . . 99 145 G.1. Recent Changes . . . . . . . . . . . . . . . . . . . . . 99 146 G.2. Major Changes . . . . . . . . . . . . . . . . . . . . . . 100 147 G.3. Minor Changes . . . . . . . . . . . . . . . . . . . . . . 102 148 G.4. Changes since RFC3344 . . . . . . . . . . . . . . . . . . 103 149 Appendix H. Example Messages . . . . . . . . . . . . . . . . . . 104 150 H.1. Example ICMP Agent Advertisement Message Format . . . . . 104 151 H.2. Example Registration Request Message Format . . . . . . . 104 152 H.3. Example Registration Reply Message Format . . . . . . . . 105 153 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 107 154 Intellectual Property and Copyright Statements . . . . . . . . . 108 156 1. Introduction 158 IP version 4 assumes that a node's IP address uniquely identifies the 159 node's point of attachment to the Internet. Therefore, a node must 160 be located on the network indicated by its IP address in order to 161 receive datagrams destined to it; otherwise, datagrams destined to 162 the node would be undeliverable. For a node to change its point of 163 attachment without losing its ability to communicate, currently one 164 of the two following mechanisms must typically be employed: 166 o the node must change its IP address whenever it changes its point 167 of attachment, or 169 o host-specific routes must be propagated throughout much of the 170 Internet routing fabric. 172 Both of these alternatives are often unacceptable. The first makes 173 it impossible for a node to maintain transport and higher-layer 174 connections when the node changes location. The second has obvious 175 and severe scaling problems, especially relevant considering the 176 explosive growth in sales of notebook (mobile) computers. 178 A new, scalable, mechanism is required for accommodating node 179 mobility within the Internet. This document defines such a 180 mechanism, which enables nodes to change their point of attachment to 181 the Internet without changing their IP address. 183 Changes between this revised specification for Mobile IP and the 184 original specifications (see [42],[15],[16],[23],[4]) are detailed in 185 Appendix G. 187 1.1. Protocol Requirements 189 A mobile node must be able to communicate with other nodes after 190 changing its link-layer point of attachment to the Internet, yet 191 without changing its IP address. 193 A mobile node must be able to communicate with other nodes that do 194 not implement these mobility functions. No protocol enhancements are 195 required in hosts or routers that are not acting as any of the new 196 architectural entities introduced in Section 1.5. 198 All messages used to update another node as to the location of a 199 mobile node must be authenticated in order to protect against remote 200 redirection attacks. 202 1.2. Goals 204 The link by which a mobile node is directly attached to the Internet 205 may often be a wireless link. This link may thus have a 206 substantially lower bandwidth and higher error rate than traditional 207 wired networks. Moreover, mobile nodes are likely to be battery 208 powered, and minimizing power consumption is important. Therefore, 209 the number of administrative messages sent over the link by which a 210 mobile node is directly attached to the Internet should be minimized, 211 and the size of these messages should be kept as small as is 212 reasonably possible. 214 1.3. Assumptions 216 The protocols defined in this document place no additional 217 constraints on the assignment of IP addresses. That is, a mobile 218 node can be assigned an IP address by the organization that owns the 219 machine. 221 This protocol assumes that mobile nodes will generally not change 222 their point of attachment to the Internet more frequently than once 223 per second. 225 This protocol assumes that IP unicast datagrams are routed based on 226 the destination address in the datagram header (and not, for example, 227 by source address). 229 1.4. Applicability 231 Mobile IP is intended to enable nodes to move from one IP subnet to 232 another. It is just as suitable for mobility across homogeneous 233 media as it is for mobility across heterogeneous media. That is, 234 Mobile IP facilitates node movement from one Ethernet segment to 235 another as well as it accommodates node movement from an Ethernet 236 segment to a wireless LAN, as long as the mobile node's IP address 237 remains the same after such a movement. 239 One can think of Mobile IP as solving the "macro" mobility management 240 problem. It is less well suited for more "micro" mobility management 241 applications -- for example, handoff amongst wireless transceivers, 242 each of which covers only a very small geographic area. As long as 243 node movement does not occur between points of attachment on 244 different IP subnets, link-layer mechanisms for mobility (i.e., link- 245 layer handoff) may offer faster convergence and far less overhead 246 than Mobile IP. 248 1.5. New Architectural Entities 250 Mobile IP introduces the following new functional entities: 252 Mobile Node 254 A host or router that changes its point of attachment from one 255 network or subnetwork to another. A mobile node may change its 256 location without changing its IP address; it may continue to 257 communicate with other Internet nodes at any location using its 258 (constant) IP address, assuming link-layer connectivity to a point 259 of attachment is available. 261 Home Agent 263 A router on a mobile node's home network which tunnels datagrams 264 for delivery to the mobile node when it is away from home, and 265 maintains current location information for the mobile node. 267 Foreign Agent 269 A router on a mobile node's visited network which provides routing 270 services to the mobile node while registered. The foreign agent 271 detunnels and delivers datagrams to the mobile node that were 272 tunneled by the mobile node's home agent. For datagrams sent by a 273 mobile node, the foreign agent may serve as a default router for 274 registered mobile nodes. 276 A mobile node is given a long-term IP address on a home network. 277 This home address is administered in the same way as a "permanent" IP 278 address is provided to a stationary host. When away from its home 279 network, a "care-of address" is associated with the mobile node and 280 reflects the mobile node's current point of attachment. The mobile 281 node uses its home address as the source address of all IP datagrams 282 that it sends, except where otherwise described in this document for 283 datagrams sent for certain mobility management functions (e.g., as in 284 Section 3.6.1.1). 286 1.6. Terminology 288 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 289 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 290 document are to be interpreted as described in RFC 2119 [1]. 292 In addition, this document frequently uses the following terms: 294 Authorization-enabling extension 296 An authentication which makes a (registration) message acceptable 297 to the ultimate recipient of the registration message. An 298 authorization-enabling extension MUST contain an SPI. 300 In this document, all uses of authorization-enabling extension 301 refer to authentication extensions that enable the Registration 302 Request message to be acceptable to the home agent. Using 303 additional protocol structures specified outside of this document, 304 it may be possible for the mobile node to provide authentication 305 of its registration to the home agent, by way of another 306 authenticating entity within the network that is acceptable to the 307 home agent (for example, see RFC 2794 [2]). 309 Agent Advertisement 311 An advertisement message constructed by attaching a special 312 Extension to a router advertisement [5] message. 314 Authentication 316 The process of verifying (using cryptographic techniques, for all 317 applications in this specification) the identity of the originator 318 of a message. 320 Care-of Address 322 The termination point of a tunnel toward a mobile node, for 323 datagrams forwarded to the mobile node while it is away from home. 324 The protocol can use two different types of care-of address: a 325 "foreign agent care-of address" is an address of a foreign agent 326 with which the mobile node is registered, and a "co-located 327 care-of address" is an externally obtained local address which the 328 mobile node has associated with one of its own network interfaces. 330 Correspondent Node 332 A peer with which a mobile node is communicating. A correspondent 333 node may be either mobile or stationary. 335 Foreign Network 337 Any network other than the mobile node's Home Network. 339 Gratuitous ARP 341 An ARP packet sent by a node in order to spontaneously cause other 342 nodes to update an entry in their ARP cache [44]. See 343 Section 4.6. 345 Home Address 347 An IP address that is assigned for an extended period of time to a 348 mobile node. It remains unchanged regardless of where the node is 349 attached to the Internet. 351 Home Network 353 A network, possibly virtual, having a network prefix matching that 354 of a mobile node's home address. Note that standard IP routing 355 mechanisms will deliver datagrams destined to a mobile node's Home 356 Address to the mobile node's Home Network. 358 Link 360 A facility or medium over which nodes can communicate at the link 361 layer. A link underlies the network layer. 363 Link-Layer Address 365 The address used to identify an endpoint of some communication 366 over a physical link. Typically, the Link-Layer address is an 367 interface's Media Access Control (MAC) address. 369 Mobility Agent 371 Either a home agent or a foreign agent. 373 Mobility Binding 375 The association of a home address with a care-of address, along 376 with the remaining lifetime of that association. 378 Mobility Security Association 380 A collection of security contexts, between a pair of nodes, which 381 may be applied to Mobile IP protocol messages exchanged between 382 them. Each context indicates an authentication algorithm and mode 383 (Section 5.1), a secret (a shared key, or appropriate public/ 384 private key pair), and a style of replay protection in use 385 (Section 5.7). 387 Node 389 A host or a router. 391 Nonce 393 A randomly chosen value, different from previous choices, inserted 394 in a message to protect against replays. 396 Security Parameter Index (SPI) 398 An index identifying a security context between a pair of nodes 399 among the contexts available in the Mobility Security Association. 400 SPI values 0 through 255 are reserved and MUST NOT be used in any 401 Mobility Security Association. 403 Tunnel 405 The path followed by a datagram while it is encapsulated. The 406 model is that, while it is encapsulated, a datagram is routed to a 407 knowledgeable decapsulating agent, which decapsulates the datagram 408 and then correctly delivers it to its ultimate destination. 410 Virtual Network 412 A network with no physical instantiation beyond a router (with a 413 physical network interface on another network). The router (e.g., 414 a home agent) generally advertises reachability to the virtual 415 network using conventional routing protocols. 417 Visited Network 419 A network other than a mobile node's Home Network, to which the 420 mobile node is currently connected. 422 Visitor List 424 The list of mobile nodes visiting a foreign agent. 426 1.7. Protocol Overview 428 The following support services are defined for Mobile IP: 430 Agent Discovery 432 Home agents and foreign agents may advertise their availability on 433 each link for which they provide service. A newly arrived mobile 434 node can send a solicitation on the link to learn if any 435 prospective agents are present. 437 Registration 439 When the mobile node is away from home, it registers its care-of 440 address with its home agent. Depending on its method of 441 attachment, the mobile node will register either directly with its 442 home agent, or through a foreign agent which forwards the 443 registration to the home agent. 445 silently discard 447 The implementation discards the datagram without further 448 processing, and without indicating an error to the sender. The 449 implementation SHOULD provide the capability of logging the error, 450 including the contents of the discarded datagram, and SHOULD 451 record the event in a statistics counter. 453 The following steps provide a rough outline of operation of the 454 Mobile IP protocol: 456 o Mobility agents (i.e., foreign agents and home agents) advertise 457 their presence via Agent Advertisement messages (Section 2). A 458 mobile node may optionally solicit an Agent Advertisement message 459 from any locally attached mobility agents through an Agent 460 Solicitation message. 462 o A mobile node receives these Agent Advertisements and determines 463 whether it is on its home network or a foreign network. 465 o When the mobile node detects that it is located on its home 466 network, it operates without mobility services. If returning to 467 its home network from being registered elsewhere, the mobile node 468 deregisters with its home agent, through exchange of a 469 Registration Request and Registration Reply message with it. 471 o When a mobile node detects that it has moved to a foreign network, 472 it obtains a care-of address on the foreign network. The care-of 473 address can either be determined from a foreign agent's 474 advertisements (a foreign agent care-of address), or by some 475 external assignment mechanism such as DHCP [32] (a co-located 476 care-of address). 478 o The mobile node operating away from home then registers its new 479 care-of address with its home agent through exchange of a 480 Registration Request and Registration Reply message with it, 481 possibly via a foreign agent (Section 3). 483 o Datagrams sent to the mobile node's home address are intercepted 484 by its home agent, tunneled by the home agent to the mobile node's 485 care-of address, received at the tunnel endpoint (either at a 486 foreign agent or at the mobile node itself), and finally delivered 487 to the mobile node (Section 4.2.3). 489 o In the reverse direction, datagrams sent by the mobile node are 490 generally delivered to their destination using standard IP routing 491 mechanisms, not necessarily passing through the home agent. 493 When away from home, Mobile IP uses protocol tunneling to hide a 494 mobile node's home address from intervening routers between its home 495 network and its current location. The tunnel terminates at the 496 mobile node's care-of address. The care-of address must be an 497 address to which datagrams can be delivered via conventional IP 498 routing. At the care-of address, the original datagram is removed 499 from the tunnel and delivered to the mobile node. 501 Mobile IP provides two alternative modes for the acquisition of a 502 care-of address: 504 a. A "foreign agent care-of address" is a care-of address provided 505 by a foreign agent through its Agent Advertisement messages. In 506 this case, the care-of address is an IP address of the foreign 507 agent. In this mode, the foreign agent is the endpoint of the 508 tunnel and, upon receiving tunneled datagrams, decapsulates them 509 and delivers the inner datagram to the mobile node. This mode of 510 acquisition is preferred because it allows many mobile nodes to 511 share the same care-of address and therefore does not place 512 unnecessary demands on the already limited IPv4 address space. 514 b. A "co-located care-of address" is a care-of address acquired by 515 the mobile node as a local IP address through some external 516 means, which the mobile node then associates with one of its own 517 network interfaces. The address may be dynamically acquired as a 518 temporary address by the mobile node such as through DHCP [32], 519 or may be owned by the mobile node as a long-term address for its 520 use only while visiting some foreign network. Specific external 521 methods of acquiring a local IP address for use as a co-located 522 care-of address are beyond the scope of this document. When 523 using a co-located care-of address, the mobile node serves as the 524 endpoint of the tunnel and itself performs decapsulation of the 525 datagrams tunneled to it. 527 The mode of using a co-located care-of address has the advantage that 528 it allows a mobile node to function without a foreign agent, for 529 example, in networks that have not yet deployed a foreign agent. It 530 does, however, place additional burden on the IPv4 address space 531 because it requires a pool of addresses within the foreign network to 532 be made available to visiting mobile nodes. It is difficult to 533 efficiently maintain pools of addresses for each subnet that may 534 permit mobile nodes to visit. 536 It is important to understand the distinction between the care-of 537 address and the foreign agent functions. The care-of address is 538 simply the endpoint of the tunnel. It might indeed be an address of 539 a foreign agent (a foreign agent care-of address), but it might 540 instead be an address temporarily acquired by the mobile node (a co- 541 located care-of address). A foreign agent, on the other hand, is a 542 mobility agent that provides services to mobile nodes. See 543 Section 3.7 and Section 4.2.2 for additional details. 545 A home agent MUST be able to attract and intercept datagrams that are 546 destined to the home address of any of its registered mobile nodes. 547 Using the proxy and gratuitous ARP mechanisms described in 548 Section 4.6, this requirement can be satisfied if the home agent has 549 a network interface on the link indicated by the mobile node's home 550 address. Other placements of the home agent relative to the mobile 551 node's home location MAY also be possible using other mechanisms for 552 intercepting datagrams destined to the mobile node's home address. 553 Such placements are beyond the scope of this document. 555 Similarly, a mobile node and a prospective or current foreign agent 556 MUST be able to exchange datagrams without relying on standard IP 557 routing mechanisms; that is, those mechanisms which make forwarding 558 decisions based upon the network-prefix of the destination address in 559 the IP header. This requirement can be satisfied if the foreign 560 agent and the visiting mobile node have an interface on the same 561 link. In this case, the mobile node and foreign agent simply bypass 562 their normal IP routing mechanism when sending datagrams to each 563 other, addressing the underlying link-layer packets to their 564 respective link-layer addresses. Other placements of the foreign 565 agent relative to the mobile node MAY also be possible using other 566 mechanisms to exchange datagrams between these nodes, but such 567 placements are beyond the scope of this document. 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 Figure 1: Operation of Mobile IPv4 589 If a mobile node is using a co-located care-of address (as described 590 in (b) above), the mobile node MUST be located on the link identified 591 by the network prefix of this care-of address. Otherwise, datagrams 592 destined to the care-of address would be undeliverable. 594 For example, Figure 1 illustrates the routing of datagrams to and 595 from a mobile node away from home, once the mobile node has 596 registered with its home agent. In figure 1, the mobile node is 597 using a foreign agent care-of address, not a co-located care-of 598 address. 600 1.8. Message Format and Protocol Extensibility 602 Mobile IP defines a set of new control messages, sent with UDP [18] 603 using well-known port number 434. The following two message types 604 are defined in this document: 606 1 Registration Request 608 3 Registration Reply 610 Up-to-date values for the message types for Mobile IP control 611 messages are specified in the IANA online database [21]. 613 In addition, for Agent Discovery, Mobile IP makes use of the existing 614 Router Advertisement and Router Solicitation messages defined for 615 ICMP Router Discovery [5]. 617 Mobile IP defines a general Extension mechanism to allow optional 618 information to be carried by Mobile IP control messages or by ICMP 619 Router Discovery messages. Some extensions have been specified to be 620 encoded in the simple Type-Length-Value format described in 621 Section 1.9. 623 Extensions allow variable amounts of information to be carried within 624 each datagram. The end of the list of Extensions is indicated by the 625 total length of the IP datagram. 627 Two separately maintained sets of numbering spaces, from which 628 Extension Type values are allocated, are used in Mobile IP: 630 o The first set consists of those Extensions which may appear only 631 in Mobile IP control messages (those sent to and from UDP port 632 number 434). In this document, the following Types are defined 633 for Extensions appearing in Mobile IP control messages: 635 32 Mobile-Home Authentication 636 33 Mobile-Foreign Authentication 637 34 Foreign-Home Authentication 639 o The second set consists of those extensions which may appear only 640 in ICMP Router Discovery messages [5]. In this document, the 641 following Types are defined for Extensions appearing in ICMP 642 Router Discovery messages: 644 0 One-byte Padding (encoded with no Length nor Data field) 645 16 Mobility Agent Advertisement 646 19 Prefix-Lengths 648 Each individual Extension is described in detail in a separate 649 section later in this document. Up-to-date values for these 650 Extension Type numbers are specified in the IANA online database 651 [21]. 653 Due to the separation (orthogonality) of these sets, it is 654 conceivable that two Extensions that are defined at a later date 655 could have identical Type values, so long as one of the Extensions 656 may be used only in Mobile IP control messages and the other may be 657 used only in ICMP Router Discovery messages. 659 The type field in the Mobile IP extension structure can support up to 660 255 (skippable and not skippable) uniquely identifiable extensions. 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 the 666 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 Unless additional structure is utilized for the extension types, new 671 developments or additions to Mobile IP might require so many new 672 extensions that the available space for extension types might run 673 out. Two new extension structures are proposed to solve this 674 problem. Certain types of extensions can be aggregated, using 675 subtypes to identify the precise extension, for example as has been 676 done with the Generic Authentication Keys extensions [45]. In many 677 cases, this may reduce the rate of allocation for new values of the 678 type field. 680 Since the new extension structures will cause an efficient usage of 681 the extension type space, it is recommended that new Mobile IP 682 extensions follow one of the two new extension formats whenever there 683 may be the possibility to group related extensions together. 685 The following subsections provide details about three distinct 686 structures for Mobile IP extensions: 688 o The simple extension format 689 o The long extension format 690 o The short extension format 692 1.9. Type-Length-Value Extension Format for Mobile IP Extensions 694 The Type-Length-Value format illustrated in Figure 2 is used for 695 extensions which are specified in this document. Since this simple 696 extension structure does not encourage the most efficient usage of 697 the extension type space, it is recommended that new Mobile IP 698 extensions follow one of the two new extension formats specified in 699 Section 1.10 or Section 1.11 whenever there may be the possibility to 700 group related extensions together. 702 0 1 2 703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 705 | Type | Length | Data ... 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 708 Figure 2: Type-Length-Value extension format for Mobile IPv4 710 Type 712 Indicates the particular type of Extension. 714 Length 716 Indicates the length (in bytes) of the data field within this 717 Extension. The length does NOT include the Type and Length bytes. 719 Data 721 The particular data associated with this Extension. This field 722 may be zero or more bytes in length. The format and length of the 723 data field is determined by the type and length fields. 725 1.10. Long Extension Format 727 This format is applicable for non-skippable extensions which carry 728 information more than 256 bytes. 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Type | Sub-Type | Length | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Data ..... 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 The Long Extension format requires that the following fields be 739 specified as the first fields of the extension. 741 Type 743 is the type, which describes a collection of extensions having a 744 common data type. 746 Sub-Type 748 is a unique number given to each member in the aggregated type. 750 Length 752 indicates the length (in bytes) of the data field within this 753 Extension. It does NOT include the Type, Length and Sub-Type 754 bytes. 756 Data 758 is the data associated with the subtype of this extension. This 759 specification does not place any additional structure on the 760 subtype data. 762 Since the length field is 16 bits wide, the extension data can exceed 763 256 bytes in length. 765 1.11. Short Extension Format 767 This format is compatible with the skippable extensions defined in 768 Section 1.9. It is not applicable for extensions which require more 769 than 256 bytes of data; for such extensions, use the format described 770 in Section 1.10. 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Type | Length | Sub-Type | Data .... 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 The Short Extension format requires that the following fields be 779 specified as the first fields of the extension: 781 Type 783 is the type, which describes a collection of extensions having a 784 common data type. 786 Sub-Type 788 is a unique number given to each member in the aggregated type. 790 Length 792 8-bit unsigned integer. Length of the extension, in bytes, 793 excluding the extension Type and the extension Length fields. 794 This field MUST be set to 1 plus the total length of the data 795 field. 797 Data 799 is the data associated with this extension. This specification 800 does not place any additional structure on the subtype data. 802 2. Agent Discovery 804 Agent Discovery is the method by which a mobile node determines 805 whether it is currently connected to its home network or to a foreign 806 network, and by which a mobile node can detect when it has moved from 807 one network to another. When connected to a foreign network, the 808 methods specified in this section also allow the mobile node to 809 determine the foreign agent care-of address being offered by each 810 foreign agent on that network. 812 Mobile IP extends ICMP Router Discovery [5] as its primary mechanism 813 for Agent Discovery. An Agent Advertisement is formed by including a 814 Mobility Agent Advertisement Extension in an ICMP Router 815 Advertisement message (Section 2.1). An Agent Solicitation message 816 is identical to an ICMP Router Solicitation, except that its IP TTL 817 MUST be set to 1 (Section 2.2). This section describes the message 818 formats and procedures by which mobile nodes, foreign agents, and 819 home agents cooperate to realize Agent Discovery. 821 Agent Advertisement and Agent Solicitation may not be necessary for 822 link layers that already provide this functionality. The method by 823 which mobile nodes establish link-layer connections with prospective 824 agents is outside the scope of this document (but see Appendix B). 825 The procedures described below assume that such link-layer 826 connectivity has already been established. 828 No authentication is required for Agent Advertisement and Agent 829 Solicitation messages. They MAY be authenticated using the IP 830 Authentication Header [9], which is unrelated to the messages 831 described in this document. Further specification of the way in 832 which Advertisement and Solicitation messages may be authenticated is 833 outside of the scope of this document. 835 2.1. Agent Advertisement 837 Agent Advertisements are transmitted by a mobility agent to advertise 838 its services on a link. Mobile nodes use these advertisements to 839 determine their current point of attachment to the Internet. An 840 Agent Advertisement is an ICMP Router Advertisement that has been 841 extended to also carry an Mobility Agent Advertisement Extension 842 (Section 2.1.1) and, optionally, a Prefix-Lengths Extension 843 (Section 2.1.2), One-byte Padding Extension (Section 2.1.3, or other 844 Extensions that might be defined in the future. 846 Within an Agent Advertisement message, ICMP Router Advertisement 847 fields of the message are required to conform to the following 848 additional specifications: 850 Link-Layer Fields 852 Destination Address 854 The link-layer destination address of a unicast Agent 855 Advertisement MUST be the same as the source link-layer address 856 of the Agent Solicitation which prompted the Advertisement. 858 IP Fields 860 TTL 862 The TTL for all Agent Advertisements MUST be set to 1. 864 Destination Address 866 As specified for ICMP Router Discovery [5], the IP destination 867 address of an multicast Agent Advertisement MUST be either the 868 "all systems on this link" multicast address (224.0.0.1) [6] or 869 the "limited broadcast" address (255.255.255.255). The subnet- 870 directed broadcast address of the form .<-1> cannot be 871 used since mobile nodes will not generally know the prefix of 872 the foreign network. When the Agent Advertisement is unicast 873 to a mobile node, the IP home address of the mobile node SHOULD 874 be used as the Destination Address. 876 ICMP Fields 878 Code 880 The Code field of the agent advertisement is interpreted as 881 follows: 883 0 The mobility agent handles common traffic -- that is, it 884 acts as a router for IP datagrams not necessarily related to 885 mobile nodes. 887 16 The mobility agent does not route common traffic. 888 However, all foreign agents MUST (minimally) forward to a 889 default router any datagrams received from a registered 890 mobile node (Section 4.2.2). 892 Lifetime 894 The maximum length of time that the Advertisement is considered 895 valid in the absence of further Advertisements. 897 Router Address(es) 899 See Section 2.3.1 for a discussion of the addresses that may 900 appear in this portion of the Agent Advertisement. 902 Num Addrs 904 The number of Router Addresses advertised in this message. 905 Note that in an Agent Advertisement message, the number of 906 router addresses specified in the ICMP Router Advertisement 907 portion of the message MAY be set to 0. See Section 2.3.1 for 908 details. 910 If sent periodically, the nominal interval at which Agent 911 Advertisements are sent SHOULD be no longer than 1/3 of the 912 advertisement Lifetime given in the ICMP header. This interval MAY 913 be shorter than 1/3 the advertised Lifetime. This allows a mobile 914 node to miss three successive advertisements before deleting the 915 agent from its list of valid agents. The actual transmission time 916 for each advertisement SHOULD be slightly randomized [5] in order to 917 avoid synchronization and subsequent collisions with other Agent 918 Advertisements that may be sent by other agents (or with other Router 919 Advertisements sent by other routers). Note that this field has no 920 relation to the "Registration Lifetime" field within the Mobility 921 Agent Advertisement Extension defined below. 923 2.1.1. Mobility Agent Advertisement Extension 925 The Mobility Agent Advertisement Extension follows the ICMP Router 926 Advertisement fields. It is used to indicate that an ICMP Router 927 Advertisement message is also an Agent Advertisement being sent by a 928 mobility agent. The Mobility Agent Advertisement Extension is 929 defined as follows: 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Type | Length | Sequence Number | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | zero or more Care-of Addresses | 939 | ... | 941 Type 943 16 945 Length 947 (6 + 4*N), where 6 accounts for the number of bytes in the 948 Sequence Number, Registration Lifetime, flags, and reserved 949 fields, and N is the number of care-of addresses advertised. 951 Sequence Number 953 The count of Agent Advertisement messages sent since the agent was 954 initialized (Section 2.3.2). 956 Registration Lifetime 958 The longest lifetime (measured in seconds) that this agent is 959 willing to accept in any Registration Request. A value of 0xffff 960 indicates infinity. This field has no relation to the "Lifetime" 961 field within the ICMP Router Advertisement portion of the Agent 962 Advertisement. 964 R 966 Registration required. Registration with this foreign agent (or 967 another foreign agent on this link) is required even when using a 968 co-located care-of address. 970 B 972 Busy. The foreign agent will not accept registrations from 973 additional mobile nodes. 975 H 977 Home agent. This agent offers service as a home agent on the link 978 on which this Agent Advertisement message is sent. 980 F 982 Foreign agent. This agent offers service as a foreign agent on 983 the link on which this Agent Advertisement message is sent. 985 M 987 Minimal encapsulation. This agent implements receiving tunneled 988 datagrams that use minimal encapsulation [16]. 990 G 992 GRE encapsulation. This agent implements receiving tunneled 993 datagrams that use GRE encapsulation [13]. 995 r 997 Sent as zero; ignored on reception. SHOULD NOT be allocated for 998 any other uses. 1000 T 1002 Foreign agent supports reverse tunneling [12]. 1004 reserved 1006 Sent as zero; ignored on reception. 1008 Care-of Address(es) 1010 The advertised foreign agent care-of address(es) provided by this 1011 foreign agent. An Agent Advertisement MUST include at least one 1012 care-of address if the 'F' bit is set. The number of care-of 1013 addresses present is determined by the Length field in the 1014 Extension. 1016 A home agent MUST always be prepared to serve the mobile nodes for 1017 which it is the home agent. A foreign agent may at times be too busy 1018 to serve additional mobile nodes; even so, it must continue to send 1019 Agent Advertisements, so that any mobile nodes already registered 1020 with it will know that they have not moved out of range of the 1021 foreign agent and that the foreign agent has not failed. A foreign 1022 agent may indicate that it is "too busy" to allow new mobile nodes to 1023 register with it, by setting the 'B' bit in its Agent Advertisements. 1024 An Agent Advertisement message MUST NOT have the 'B' bit set if the 1025 'F' bit is not also set. Furthermore, at least one of the 'F' bit 1026 and the 'H' bit MUST be set in any Agent Advertisement message sent. 1028 When a foreign agent wishes to require registration even from those 1029 mobile nodes which have acquired a co-located care-of address, it 1030 sets the 'R' bit to one. Because this bit applies only to foreign 1031 agents, an agent MUST NOT set the 'R' bit to one unless the 'F' bit 1032 is also set to one. 1034 2.1.2. Prefix-Lengths Extension 1036 The Prefix-Lengths Extension MAY follow the Mobility Agent 1037 Advertisement Extension. It is used to indicate the number of bits 1038 of network prefix that applies to each Router Address listed in the 1039 ICMP Router Advertisement portion of the Agent Advertisement. Note 1040 that the prefix lengths given DO NOT apply to care-of address(es) 1041 listed in the Mobility Agent Advertisement Extension. The Prefix- 1042 Lengths Extension is defined as follows: 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Type | Length | Prefix Length | .... 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Type 1052 19 (Prefix-Lengths Extension) 1054 Length 1056 N, where N is the value (possibly zero) of the Num Addrs field in 1057 the ICMP Router Advertisement portion of the Agent Advertisement. 1059 Prefix Length(s) 1061 The number of leading bits that define the network number of the 1062 corresponding Router Address listed in the ICMP Router 1063 Advertisement portion of the message. The prefix length for each 1064 Router Address is encoded as a separate byte, in the order that 1065 the Router Addresses are listed in the ICMP Router Advertisement 1066 portion of the message. 1068 See Section 2.4.2 for information about how the Prefix-Lengths 1069 Extension MAY be used by a mobile node when determining whether it 1070 has moved. See Appendix E for implementation details about the use 1071 of this Extension. 1073 2.1.3. One-byte Padding Extension 1075 Some IP protocol implementations insist upon padding ICMP messages to 1076 an even number of bytes. If the ICMP length of an Agent 1077 Advertisement is odd, this Extension MAY be included in order to make 1078 the ICMP length even. Note that this Extension is NOT intended to be 1079 a general-purpose Extension to be included in order to word- or long- 1080 align the various fields of the Agent Advertisement. An Agent 1081 Advertisement SHOULD NOT include more than one One-byte Padding 1082 Extension and if present, this Extension SHOULD be the last Extension 1083 in the Agent Advertisement. 1085 Note that unlike other Extensions used in Mobile IP, the One-byte 1086 Padding Extension is encoded as a single byte, with no "Length" nor 1087 "Data" field present. The One-byte Padding Extension is defined as 1088 follows: 1090 0 1 2 3 4 5 6 7 1091 +-+-+-+-+-+-+-+-+ 1092 | Type | 1093 +-+-+-+-+-+-+-+-+ 1095 Type 0 (One-byte Padding Extension) 1097 2.2. Agent Solicitation 1099 An Agent Solicitation is identical to an ICMP Router Solicitation 1100 with the further restriction that the IP TTL Field MUST be set to 1. 1102 2.3. Foreign Agent and Home Agent Considerations 1104 Any mobility agent which cannot be discovered by a link-layer 1105 protocol MUST send Agent Advertisements. An agent which can be 1106 discovered by a link-layer protocol SHOULD also implement Agent 1107 Advertisements. However, the Advertisements need not be sent, except 1108 when the site policy requires registration with the agent (i.e., when 1109 the 'R' bit is set), or as a response to a specific Agent 1110 Solicitation. All mobility agents MUST process packets that they 1111 receive addressed to the Mobile-Agents multicast group, at address 1112 224.0.0.11. A mobile node MAY send an Agent Solicitation to 1113 224.0.0.11. All mobility agents SHOULD respond to Agent 1114 Solicitations. 1116 The same procedures, defaults, and constants are used in Agent 1117 Advertisement messages and Agent Solicitation messages as specified 1118 for ICMP Router Discovery [5], except that: 1120 o a mobility agent MUST limit the rate at which it sends broadcast 1121 or multicast Agent Advertisements; the maximum rate SHOULD be 1122 chosen so that the Advertisements do not consume a significant 1123 amount of network bandwidth, AND 1125 o a mobility agent that receives a Router Solicitation MUST NOT 1126 require that the IP Source Address is the address of a neighbor 1127 (i.e., an address that matches one of the router's own addresses 1128 on the arrival interface, under the subnet mask associated with 1129 that address of the router). 1131 o a mobility agent MAY be configured to send Agent Advertisements 1132 only in response to an Agent Solicitation message. 1134 If the home network is not a virtual network, then the home agent for 1135 any mobile node SHOULD be located on the link identified by the 1136 mobile node's home address, and Agent Advertisement messages sent by 1137 the home agent on this link MUST have the 'H' bit set. In this way, 1138 mobile nodes on their own home network will be able to determine that 1139 they are indeed at home. Any Agent Advertisement messages sent by 1140 the home agent on another link to which it may be attached (if it is 1141 a mobility agent serving more than one link), MUST NOT have the 'H' 1142 bit set unless the home agent also serves as a home agent (to other 1143 mobile nodes) on that other link. A mobility agent MAY use different 1144 settings for each of the 'R', 'H', and 'F' bits on different network 1145 interfaces. 1147 If the home network is a virtual network, the home network has no 1148 physical realization external to the home agent itself. In this 1149 case, there is no physical network link on which to send Agent 1150 Advertisement messages advertising the home agent. Mobile nodes for 1151 which this is the home network are always treated as being away from 1152 home. 1154 On a particular subnet, either all mobility agents MUST include the 1155 Prefix-Lengths Extension or all of them MUST NOT include this 1156 Extension. Equivalently, it is prohibited for some agents on a given 1157 subnet to include the Extension but for others not to include it. 1158 Otherwise, one of the move detection algorithms designed for mobile 1159 nodes will not function properly (Section 2.4.2). 1161 2.3.1. Advertised Router Addresses 1163 The ICMP Router Advertisement portion of the Agent Advertisement MAY 1164 contain one or more router addresses. An agent SHOULD only put its 1165 own addresses, if any, in the advertisement. Whether or not its own 1166 address appears in the Router Addresses, a foreign agent MUST route 1167 datagrams it receives from registered mobile nodes (Section 3.7). 1169 2.3.2. Sequence Numbers and Rollover Handling 1171 The sequence number in Agent Advertisements ranges from 0 to 0xffff. 1172 After booting, an agent MUST use the number 0 for its first 1173 advertisement. Each subsequent advertisement MUST use the sequence 1174 number one greater, with the exception that the sequence number 1175 0xffff MUST be followed by sequence number 256. In this way, mobile 1176 nodes can distinguish a reduction in the sequence number that occurs 1177 after a reboot from a reduction that results in rollover of the 1178 sequence number after it attains the value 0xffff. 1180 2.4. Mobile Node Considerations 1182 Every mobile node MUST implement Agent Solicitation. Solicitations 1183 SHOULD only be sent in the absence of Agent Advertisements and when a 1184 care-of address has not been determined through a link-layer protocol 1185 or other means. The mobile node uses the same procedures, defaults, 1186 and constants for Agent Solicitation as specified for ICMP Router 1187 Solicitation messages [5], except that the mobile node MAY solicit 1188 more often than once every three seconds, and that a mobile node that 1189 is currently not connected to any foreign agent MAY solicit more 1190 times than MAX_SOLICITATIONS. 1192 The rate at which a mobile node sends Solicitations MUST be limited 1193 by the mobile node. The mobile node MAY send three initial 1194 Solicitations at a maximum rate of one per second while searching for 1195 an agent. After this, the rate at which Solicitations are sent MUST 1196 be reduced so as to limit the overhead on the local link. Subsequent 1197 Solicitations MUST be sent using a binary exponential backoff 1198 mechanism, doubling the interval between consecutive Solicitations, 1199 up to a maximum interval. The maximum interval SHOULD be chosen 1200 appropriately based upon the characteristics of the media over which 1201 the mobile node is soliciting. This maximum interval SHOULD be at 1202 least one minute between Solicitations. 1204 While still searching for an agent, the mobile node MUST NOT increase 1205 the rate at which it sends Solicitations unless it has received a 1206 positive indication that it has moved to a new link. After 1207 successfully registering with an agent, the mobile node SHOULD also 1208 increase the rate at which it will send Solicitations when it next 1209 begins searching for a new agent with which to register. The 1210 increased solicitation rate MAY revert to the maximum rate, but then 1211 MUST be limited in the manner described above. In all cases, the 1212 recommended solicitation intervals are nominal values. Mobile nodes 1213 MUST randomize their solicitation times around these nominal values 1214 as specified for ICMP Router Discovery [5]. 1216 Mobile nodes MUST process received Agent Advertisements. A mobile 1217 node can distinguish an Agent Advertisement message from other uses 1218 of the ICMP Router Advertisement message by examining the number of 1219 advertised addresses and the IP Total Length field. When the IP 1220 total length indicates that the ICMP message is longer than needed 1221 for the number of advertised addresses, the remaining data is 1222 interpreted as one or more Extensions. The presence of a Mobility 1223 Agent Advertisement Extension identifies the advertisement as an 1224 Agent Advertisement. 1226 If there is more than one advertised address, the mobile node SHOULD 1227 pick the first address for its initial registration attempt. If the 1228 registration attempt fails with a status Code indicating rejection by 1229 the foreign agent, the mobile node MAY retry the attempt with each 1230 subsequent advertised address in turn. 1232 When multiple methods of agent discovery are in use, the mobile node 1233 SHOULD first attempt registration with agents including Mobility 1234 Agent Advertisement Extensions in their advertisements, in preference 1235 to those discovered by other means. This preference maximizes the 1236 likelihood that the registration will be recognized, thereby 1237 minimizing the number of registration attempts. 1239 A mobile node MUST ignore reserved bits in Agent Advertisements, as 1240 opposed to discarding such advertisements. In this way, new bits can 1241 be defined later, without affecting the ability for mobile nodes to 1242 use the advertisements even when the newly defined bits are not 1243 understood. 1245 2.4.1. Registration Required 1247 When the mobile node receives an Agent Advertisement with the 'R' bit 1248 set, the mobile node SHOULD register through the foreign agent, even 1249 when the mobile node might be able to acquire its own co-located 1250 care-of address. This feature is intended to allow sites to enforce 1251 visiting policies (such as accounting) which require exchanges of 1252 authorization. 1254 If formerly reserved bits require some kind of monitoring/enforcement 1255 at the foreign link, foreign agents implementing the new 1256 specification for the formerly reserved bits can set the 'R' bit. 1257 This has the effect of forcing the mobile node to register through 1258 the foreign agent, so the foreign agent could then monitor/enforce 1259 the policy. 1261 2.4.2. Move Detection 1263 Two primary mechanisms are provided for mobile nodes to detect when 1264 they have moved from one subnet to another. Other mechanisms MAY 1265 also be used. When the mobile node detects that it has moved, it 1266 SHOULD register (Section 3) with a suitable care-of address on the 1267 new foreign network. However, the mobile node MUST NOT register more 1268 frequently than once per second on average, as specified in 1269 Section 3.6.3. 1271 2.4.2.1. Algorithm 1 1273 The first method of move detection is based upon the Lifetime field 1274 within the main body of the ICMP Router Advertisement portion of the 1275 Agent Advertisement. A mobile node SHOULD record the Lifetime 1276 received in any Agent Advertisements, until that Lifetime expires. 1277 If the mobile node fails to receive another advertisement from the 1278 same agent within the specified Lifetime, it SHOULD assume that it 1279 has lost contact with that agent. If the mobile node has previously 1280 received an Agent Advertisement from another agent for which the 1281 Lifetime field has not yet expired, the mobile node MAY immediately 1282 attempt registration with that other agent. Otherwise, the mobile 1283 node SHOULD attempt to discover a new agent with which to register. 1285 2.4.2.2. Algorithm 2 1287 The second method uses network prefixes. The Prefix-Lengths 1288 Extension MAY be used in some cases by a mobile node to determine 1289 whether or not a newly received Agent Advertisement was received on 1290 the same subnet as the mobile node's current care-of address. If the 1291 prefixes differ, the mobile node MAY assume that it has moved. If a 1292 mobile node is currently using a foreign agent care-of address, the 1293 mobile node SHOULD NOT use this method of move detection unless both 1294 the current agent and the new agent include the Prefix-Lengths 1295 Extension in their respective Agent Advertisements; if this Extension 1296 is missing from one or both of the advertisements, this method of 1297 move detection SHOULD NOT be used. Similarly, if a mobile node is 1298 using a co-located care-of address, it SHOULD not use this method of 1299 move detection unless the new agent includes the Prefix-Lengths 1300 Extension in its Advertisement and the mobile node knows the network 1301 prefix of its current co-located care-of address. On the expiration 1302 of its current registration, if this method indicates that the mobile 1303 node has moved, rather than re-registering with its current care-of 1304 address, a mobile node MAY choose instead to register with a the 1305 foreign agent sending the new Advertisement with the different 1306 network prefix. The Agent Advertisement on which the new 1307 registration is based MUST NOT have expired according to its Lifetime 1308 field. 1310 2.4.3. Returning Home 1312 A mobile node can detect that it has returned to its home network 1313 when it receives an Agent Advertisement from its own home agent. If 1314 so, it SHOULD deregister with its home agent (Section 3). Before 1315 attempting to deregister, the mobile node SHOULD configure its 1316 routing table appropriately for its home network (Section 4.2.1). In 1317 addition, if the home network is using ARP [17], the mobile node MUST 1318 follow the procedures described in Section 4.6 with regard to ARP, 1319 proxy ARP, and gratuitous ARP. 1321 2.4.4. Sequence Numbers and Rollover Handling 1323 If a mobile node detects two successive values of the sequence number 1324 in the Agent Advertisements from the foreign agent with which it is 1325 registered, the second of which is less than the first and inside the 1326 range 0 to 255, the mobile node SHOULD register again. If the second 1327 value is less than the first but is greater than or equal to 256, the 1328 mobile node SHOULD assume that the sequence number has rolled over 1329 past its maximum value (0xffff), and that reregistration is not 1330 necessary (Section 2.3). 1332 3. Registration 1334 Mobile IP registration provides a flexible mechanism for mobile nodes 1335 to communicate their current reachability information to their home 1336 agent. It is the method by which mobile nodes: 1338 o request forwarding services when visiting a foreign network, 1340 o inform their home agent of their current care-of address, 1342 o renew a registration which is due to expire, and/or 1344 o deregister when they return home. 1346 Registration messages exchange information between a mobile node, 1347 (optionally) a foreign agent, and the home agent. Registration 1348 creates or modifies a mobility binding at the home agent, associating 1349 the mobile node's home address with its care-of address for the 1350 specified Lifetime. 1352 Several other (optional) capabilities are available through the 1353 registration procedure, which enable a mobile node to: 1355 o discover its home address, if the mobile node is not configured 1356 with this information. 1358 o maintain multiple simultaneous registrations, so that a copy of 1359 each datagram will be tunneled to each active care-of address 1361 o deregister specific care-of addresses while retaining other 1362 mobility bindings, and 1364 o discover the address of a home agent if the mobile node is not 1365 configured with this information. 1367 3.1. Registration Overview 1369 Mobile IP defines two different registration procedures, one via a 1370 foreign agent that relays the registration to the mobile node's home 1371 agent, and one directly with the mobile node's home agent. The 1372 following rules determine which of these two registration procedures 1373 to use in any particular circumstance: 1375 o If a mobile node is registering a foreign agent care-of address, 1376 the mobile node MUST register via that foreign agent. 1378 o If a mobile node is using a co-located care-of address, and 1379 receives an Agent Advertisement from a foreign agent on the link 1380 on which it is using this care-of address, the mobile node SHOULD 1381 register via that foreign agent (or via another foreign agent on 1382 this link) if the 'R' bit is set in the received Agent 1383 Advertisement message. 1385 o If a mobile node is otherwise using a co-located care-of address, 1386 the mobile node MUST register directly with its home agent. 1388 o If a mobile node has returned to its home network and is 1389 (de)registering with its home agent, the mobile node MUST register 1390 directly with its home agent. 1392 Both registration procedures involve the exchange of Registration 1393 Request and Registration Reply messages (Section 3.3 and 1394 Section 3.4). When registering via a foreign agent, the registration 1395 procedure requires the following four messages: 1397 a. The mobile node sends a Registration Request to the prospective 1398 foreign agent to begin the registration process. 1400 b. The foreign agent processes the Registration Request and then 1401 relays it to the home agent. 1403 c. The home agent sends a Registration Reply to the foreign agent to 1404 grant or deny the Request. 1406 d. The foreign agent processes the Registration Reply and then 1407 relays it to the mobile node to inform it of the disposition of 1408 its Request. 1410 When the mobile node instead registers directly with its home agent, 1411 the registration procedure requires only the following two messages: 1413 a. The mobile node sends a Registration Request to the home agent. 1415 b. The home agent sends a Registration Reply to the mobile node, 1416 granting or denying the Request. 1418 The registration messages defined in Section 3.3 and Section 3.4 use 1419 the User Datagram Protocol (UDP) [18]. A nonzero UDP checksum SHOULD 1420 be included in the header, and MUST be checked by the recipient. A 1421 zero UDP checksum SHOULD be accepted by the recipient. The behavior 1422 of the mobile node and the home agent with respect to their mutual 1423 acceptance of packets with zero UDP checksums SHOULD be defined as 1424 part of the mobility security association which exists between them. 1426 3.2. Authentication 1428 Each mobile node, foreign agent, and home agent MUST be able to 1429 support a mobility security association for mobile entities, indexed 1430 by their SPI and IP address. In the case of the mobile node, this 1431 must be its Home Address. See Section 5.1 for requirements for 1432 support of authentication algorithms. Registration messages between 1433 a mobile node and its home agent MUST be authenticated with an 1434 authorization-enabling extension, e.g. the Mobile-Home Authentication 1435 Extension (Section 3.5.2). This extension MUST be the first 1436 authentication extension; other foreign agent-specific extensions MAY 1437 be added to the message after the mobile node computes the 1438 authentication. 1440 3.3. Registration Request 1442 A mobile node registers with its home agent using a Registration 1443 Request message so that its home agent can create or modify a 1444 mobility binding for that mobile node (e.g., with a new lifetime). 1445 The Request may be relayed to the home agent by the foreign agent 1446 through which the mobile node is registering, or it may be sent 1447 directly to the home agent in the case in which the mobile node is 1448 registering a co-located care-of address. 1450 IP fields: 1452 Source Address 1454 Typically the interface address from which the message is sent. 1456 Destination Address 1458 Typically that of the foreign agent or the home agent. 1460 See Section 3.6.1.1 and Section 3.7.2.2 for details. 1462 UDP fields: 1464 Source Port 1466 variable 1468 Destination Port 1470 434 1472 The UDP header is followed by the Mobile IP fields shown below: 1474 0 1 2 3 1475 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 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Type |S|B|D|M|G|r|T|x| Lifetime | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Home Address | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Home Agent | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Care-of Address | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | | 1486 + Identification + 1487 | | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Extensions ... 1490 +-+-+-+-+-+-+-+- 1492 Type 1494 1 (Registration Request) 1496 S 1498 Simultaneous bindings. If the 'S' bit is set, the mobile node is 1499 requesting that the home agent retain its prior mobility bindings, 1500 as described in Section 3.6.1.2. 1502 B 1504 Broadcast datagrams. If the 'B' bit is set, the mobile node 1505 requests that the home agent tunnel to it any broadcast datagrams 1506 that it receives on the home network, as described in Section 4.3. 1508 D 1510 Decapsulation by mobile node. If the 'D' bit is set, the mobile 1511 node will itself decapsulate datagrams which are sent to the 1512 care-of address. That is, the mobile node is using a co-located 1513 care-of address. 1515 M 1517 Minimal encapsulation. If the 'M' bit is set, the mobile node 1518 requests that its home agent use minimal encapsulation [16] for 1519 datagrams tunneled to the mobile node. 1521 G 1523 GRE encapsulation. If the 'G' bit is set, the mobile node 1524 requests that its home agent use GRE encapsulation [13] for 1525 datagrams tunneled to the mobile node. 1527 r 1529 Sent as zero; ignored on reception. SHOULD NOT be allocated for 1530 any other uses. 1532 T 1534 Reverse Tunneling requested; see [12]. 1536 x 1538 Sent as zero; ignored on reception. 1540 Lifetime 1542 The number of seconds remaining before the registration is 1543 considered expired. A value of zero indicates a request for 1544 deregistration. A value of 0xffff indicates infinity. 1546 Home Address 1548 The IP address of the mobile node. 1550 Home Agent 1552 The IP address of the mobile node's home agent. 1554 Care-of Address 1556 The IP address for the end of the tunnel. 1558 Identification 1560 A 64-bit number, constructed by the mobile node, used for matching 1561 Registration Requests with Registration Replies, and for 1562 protecting against replay attacks of registration messages. See 1563 Section 5.4 and Section 5.7. 1565 Extensions 1567 The fixed portion of the Registration Request is followed by one 1568 or more of the Extensions listed in Section 3.5. An 1569 authorization-enabling extension MUST be included in all 1570 Registration Requests. See Section 3.6.1.3 and Section 3.7.2.2 1571 for information on the relative order in which different 1572 extensions, when present, MUST be placed in a Registration Request 1573 message. 1575 3.4. Registration Reply 1577 A mobility agent typically returns a Registration Reply message to a 1578 mobile node which has sent a Registration Request message. If the 1579 mobile node is requesting service from a foreign agent, that foreign 1580 agent will typically receive the Reply from the home agent and 1581 subsequently relay it to the mobile node. Reply messages contain the 1582 necessary codes to inform the mobile node about the status of its 1583 Request, along with the lifetime granted by the home agent, which MAY 1584 be smaller than the original Request. 1586 The foreign agent MUST NOT increase the Lifetime selected by the 1587 mobile node in the Registration Request, since the Lifetime is 1588 covered by an authentication extension which enables authorization by 1589 the home agent. Such an extension contains authentication data which 1590 cannot be correctly (re)computed by the foreign agent. The home 1591 agent MUST NOT increase the Lifetime selected by the mobile node in 1592 the Registration Request, since doing so could increase it beyond the 1593 maximum Registration Lifetime allowed by the foreign agent. If the 1594 Lifetime received in the Registration Reply is greater than that in 1595 the Registration Request, the Lifetime in the Request MUST be used. 1596 When the Lifetime received in the Registration Reply is less than 1597 that in the Registration Request, the Lifetime in the Reply MUST be 1598 used. 1600 IP fields: 1602 Source Address 1604 Typically copied from the destination address of the 1605 Registration Request to which the agent is replying. See 1606 Section 3.7.2.3 and Section 3.8.3.2 for complete details. 1608 Destination Address 1610 Copied from the source address of the Registration Request to 1611 which the agent is replying 1613 UDP fields: 1615 Source Port 1617 Copied from the UDP destination port of the corresponding 1618 Registration Request. 1620 Destination Port 1622 Copied from the source port of the corresponding Registration 1623 Request (Section 3.7.1). 1625 The UDP header is followed by the Mobile IP fields shown below: 1627 0 1 2 3 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Type | Code | Lifetime | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Home Address | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | Home Agent | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | | 1637 + Identification + 1638 | | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Extensions ... 1641 +-+-+-+-+-+-+-+- 1643 Type 1645 3 (Registration Reply) 1647 Code 1649 A value indicating the result of the Registration Request. See 1650 below for a list of currently defined Code values. 1652 Lifetime 1654 If the Code field indicates that the registration was accepted, 1655 the Lifetime field is set to the number of seconds remaining 1656 before the registration is considered expired. A value of zero 1657 indicates that the mobile node has been deregistered. A value of 1658 0xffff indicates infinity. If the Code field indicates that the 1659 registration was denied, the contents of the Lifetime field are 1660 unspecified and MUST be ignored on reception. 1662 Home Address 1664 The IP address of the mobile node. 1666 Home Agent 1668 The IP address of the mobile node's home agent. 1670 Identification 1672 A 64-bit number used for matching Registration Requests with 1673 Registration Replies, and for protecting against replay attacks of 1674 registration messages. The value is based on the Identification 1675 field from the Registration Request message from the mobile node, 1676 and on the style of replay protection used in the security context 1677 between the mobile node and its home agent (defined by the 1678 mobility security association between them, and SPI value in the 1679 authorization-enabling extension). See Section 5.4 and 1680 Section 5.7. 1682 Extensions 1684 The fixed portion of the Registration Reply is followed by one or 1685 more of the Extensions listed in Section 3.5. An authorization- 1686 enabling extension MUST be included in all Registration Replies 1687 returned by the home agent. See Section 3.7.2.2 and 1688 Section 3.8.3.3 for rules on placement of extensions to Reply 1689 messages. 1691 The following values are defined for use within the Code field. 1692 Registration successful: 1694 0 registration accepted 1695 1 registration accepted, but simultaneous mobility bindings 1696 unsupported 1698 Registration denied by the foreign agent: 1700 64 reason unspecified 1701 65 administratively prohibited 1702 66 insufficient resources 1703 67 mobile node failed authentication 1704 68 home agent failed authentication 1705 69 requested Lifetime too long 1706 70 poorly formed Request 1707 71 poorly formed Reply 1708 72 requested encapsulation unavailable 1709 73 reserved and unavailable 1710 TBD-IANA Invalid Home Agent address 1711 77 invalid care-of address 1712 78 registration timeout 1713 80 home network unreachable (ICMP error received) 1714 81 home agent host unreachable (ICMP error received) 1715 82 home agent port unreachable (ICMP error received) 1716 88 home agent unreachable (other ICMP error received) 1718 Registration denied by the home agent: 1720 128 reason unspecified 1721 129 administratively prohibited 1722 130 insufficient resources 1723 131 mobile node failed authentication 1724 132 foreign agent failed authentication 1725 133 registration Identification mismatch 1726 134 poorly formed Request 1727 135 too many simultaneous mobility bindings 1728 136 unknown home agent address 1730 Up-to-date values of the Code field are specified in the IANA online 1731 database [21]. 1733 3.5. Registration Extensions 1735 3.5.1. Computing Authentication Extension Values 1737 The Authenticator value computed for each authentication Extension 1738 MUST protect the following fields from the registration message: 1740 o the UDP payload (that is, the Registration Request or Registration 1741 Reply data), 1743 o all prior Extensions in their entirety, and 1745 o the Type, Length, and SPI of this Extension. 1747 The default authentication algorithm uses HMAC-MD5 [10] to compute a 1748 128-bit "message digest" of the registration message. The data over 1749 which the HMAC is computed is defined as: 1751 o the UDP payload (that is, the Registration Request or Registration 1752 Reply data), 1754 o all prior Extensions in their entirety, and 1755 o the Type, Length, and SPI of this Extension. 1757 Note that the Authenticator field itself and the UDP header are NOT 1758 included in the computation of the default Authenticator value. See 1759 Section 5.1 for information about support requirements for message 1760 authentication codes, which are to be used with the various 1761 authentication Extensions. 1763 The Security Parameter Index (SPI) within any of the authentication 1764 Extensions defines the security context which is used to compute the 1765 Authenticator value and which MUST be used by the receiver to check 1766 that value. In particular, the SPI selects the authentication 1767 algorithm and mode (Section 5.1) and secret (a shared key, or 1768 appropriate public/private key pair) used in computing the 1769 Authenticator. In order to ensure interoperability between different 1770 implementations of the Mobile IP protocol, an implementation MUST be 1771 able to associate any SPI value with any authentication algorithm and 1772 mode which it implements. In addition, all implementations of Mobile 1773 IP MUST implement the default authentication algorithm (HMAC-MD5) 1774 specified above. 1776 3.5.2. Mobile-Home Authentication Extension 1778 At least one authorization-enabling extension MUST be present in all 1779 Registration Requests, and also in all Registration Replies generated 1780 by the Home Agent. The Mobile-Home Authentication Extension is 1781 always an authorization-enabling for registration messages specified 1782 in this document. This requirement is intended to eliminate problems 1783 [28] which result from the uncontrolled propagation of remote 1784 redirects in the Internet. The location of the authorization- 1785 enabling extension marks the end of the data to be authenticated by 1786 the authorizatizing agent interpreting that authorization-enabling 1787 extension. 1789 0 1 2 3 1790 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 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Type | Length | SPI .... 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 ... SPI (cont.) | Authenticator ... 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 Type 1799 32 1801 Length 1803 4 plus the number of bytes in the Authenticator. 1805 SPI 1807 Security Parameter Index (4 bytes). An opaque identifier (see 1808 Section 1.6). 1810 Authenticator 1812 (variable length) (See Section 3.5.1) 1814 3.5.3. Mobile-Foreign Authentication Extension 1816 This Extension MAY be included in Registration Requests and Replies 1817 in cases in which a mobility security association exists between the 1818 mobile node and the foreign agent. See Section 5.1 for information 1819 about support requirements for message authentication codes. 1821 0 1 2 3 1822 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 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | Type | Length | SPI .... 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 ... SPI (cont.) | Authenticator ... 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 Type 1831 33 1833 Length 1835 4 plus the number of bytes in the Authenticator. 1837 SPI 1839 Security Parameter Index (4 bytes). An opaque identifier (see 1840 Section 1.6). 1842 Authenticator 1844 (variable length) (See Section 3.5.1) 1846 3.5.4. Foreign-Home Authentication Extension 1848 This Extension MAY be included in Registration Requests and Replies 1849 in cases in which a mobility security association exists between the 1850 foreign agent and the home agent, as long as the Registration Request 1851 is not a deregistration (i.e., the mobile node requested a nonzero 1852 lifetime and the home address is different than the care-of address). 1853 The Foreign-Home Authentication extension MUST NOT be applied to 1854 deregistration messages. See Section 5.1 for information about 1855 support requirements for message authentication codes. 1857 0 1 2 3 1858 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 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Type | Length | SPI .... 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 ... SPI (cont.) | Authenticator ... 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 Type 1867 34 1869 Length 1871 4 plus the number of bytes in the Authenticator. 1873 SPI 1875 Security Parameter Index (4 bytes). An opaque identifier (see 1876 Section 1.6). 1878 Authenticator 1880 (variable length) (See Section 3.5.1) 1882 In order to perform the authentication, the Home Agent and the 1883 Foreign Agent are configured with a mobility security association 1884 that is indexed by the SPI (in the appended Foreign-Home 1885 Authentication Extension) and the IP Source Address of the 1886 Registration Request. When the extension is used with a Registration 1887 Reply message, the foreign agent address MUST be used as the 1888 Destination IP address in the IP header. 1890 When this extension is applied to a Registration Request message, the 1891 mobility security association for verifying the correctness of the 1892 authentication data is selected by the Home Agent based on the value 1893 of the Source IP Address field of the Registration Request and the 1894 SPI of the Authentication extension. The Source IP Address will be 1895 the same as the Care-of Address field of the Registration Request 1896 (see Section 3.7.2.2) 1898 When this extension is applied to a Registration Reply message, the 1899 mobility security association for verifying the correctness of the 1900 authentication data is selected by the foreign agent based on the 1901 value of the Home Agent Address field of the Registration Reply. 1903 If the Care-of Address in the Registration Request is not in the 1904 Agent Advertisement, then the foreign agent MUST NOT append the 1905 Foreign-Home Authentication Extension when relaying the message to 1906 the home agent. Moreover, for a deregistration message (i.e., 1907 lifetime = 0), the foreign agent MUST NOT append the Foreign-Home 1908 Authentication Extension when relaying the message to the home agent. 1909 Consequently, when the HA receives a deregistration request that does 1910 not contain a Foreign-Home Authentication Extension it MUST NOT for 1911 this reason discard the request as part of security association 1912 processing. 1914 3.6. Mobile Node Considerations 1916 A mobile node MUST be configured (statically or dynamically) with a 1917 netmask and a mobility security association for each of its home 1918 agents. In addition, a mobile node MAY be configured with its home 1919 address, and the IP address of one or more of its home agents; 1920 otherwise, the mobile node MAY discover a home agent using the 1921 procedures described in Section 3.6.1.2. 1923 If the mobile node is not configured with a home address, it MAY use 1924 the Mobile Node NAI extension [2] to identify itself, and set the 1925 Home Address field of the Registration Request to 0.0.0.0. In this 1926 case, the mobile node MUST be able to assign its home address after 1927 extracting this information from the Registration Reply from the home 1928 agent. 1930 For each pending registration, the mobile node maintains the 1931 following information: 1933 o the link-layer address of the foreign agent to which the 1934 Registration Request was sent, if applicable, 1935 o the IP destination address of the Registration Request, 1936 o the care-of address used in the registration, 1937 o the Identification value sent in the registration, 1938 o the originally requested Lifetime, and 1939 o the remaining Lifetime of the pending registration. 1941 A mobile node SHOULD initiate a registration whenever it detects a 1942 change in its network connectivity. See Section 2.4.2 for methods by 1943 which mobile nodes MAY make such a determination. When it is away 1944 from home, the mobile node's Registration Request allows its home 1945 agent to create or modify a mobility binding for it. When it is at 1946 home, the mobile node's (de)Registration Request allows its home 1947 agent to delete any previous mobility binding(s) for it. A mobile 1948 node operates without the support of mobility functions when it is at 1949 home. 1951 There are other conditions under which the mobile node SHOULD 1952 (re)register with its foreign agent, such as when the mobile node 1953 detects that the foreign agent has rebooted (as specified in 1954 Section 2.4.4) and when the current registration's Lifetime is near 1955 expiration. 1957 In the absence of link-layer indications of changes in point of 1958 attachment, Agent Advertisements from new agents SHOULD NOT cause a 1959 mobile node to attempt a new registration, if its current 1960 registration has not expired and it is still also receiving Agent 1961 Advertisements from the foreign agent with which it is currently 1962 registered. In the absence of link-layer indications, a mobile node 1963 MUST NOT attempt to register more often than once per second. 1965 A mobile node MAY register with a different agent when transport- 1966 layer protocols indicate excessive retransmissions. A mobile node 1967 MUST NOT consider reception of an ICMP Redirect from a foreign agent 1968 that is currently providing service to it as reason to register with 1969 a new foreign agent. Within these constraints, the mobile node MAY 1970 register again at any time. 1972 Appendix D shows some examples of how the fields in registration 1973 messages would be set up in some typical registration scenarios. 1975 3.6.1. Sending Registration Requests 1977 The following sections specify details for the values the mobile node 1978 MUST supply in the fields of Registration Request messages. 1980 3.6.1.1. IP Fields 1982 This section provides the specific rules by which mobile nodes pick 1983 values for the IP header fields of a Registration Request. 1985 IP Source Address: 1987 o When registering on a foreign network with a co-located care-of 1988 address, the IP source address MUST be the care-of address. 1990 o Otherwise, if the mobile node does not have a home address, the IP 1991 source address MUST be 0.0.0.0. 1993 o In all other circumstances, the IP source address MUST be the 1994 mobile node's home address. 1996 IP Destination Address: 1998 o When the mobile node has discovered the agent with which it is 1999 registering, through some means (e.g., link-layer) that does not 2000 provide the IP address of the agent (the IP address of the agent 2001 is unknown to the mobile node), then the "All Mobility Agents" 2002 multicast address (224.0.0.11) MUST be used. In this case, the 2003 mobile node MUST use the agent's link-layer unicast address in 2004 order to deliver the datagram to the correct agent. 2006 o When registering with a foreign agent, the address of the agent as 2007 learned from the IP source address of the corresponding Agent 2008 Advertisement MUST be used. This MAY be an address which does not 2009 appear as an advertised care-of address in the Agent 2010 Advertisement. In addition, when transmitting this Registration 2011 Request message, the mobile node MUST use a link-layer destination 2012 address copied from the link-layer source address of the Agent 2013 Advertisement message in which it learned this foreign agent's IP 2014 address. 2016 o When the mobile node is registering directly with its home agent 2017 and knows the (unicast) IP address of its home agent, the 2018 destination address MUST be set to this address. 2020 o If the mobile node is registering directly with its home agent, 2021 but does not know the IP address of its home agent, the mobile 2022 node may use dynamic home agent address resolution to 2023 automatically determine the IP address of its home agent 2024 (Section 3.6.1.2). In this case, the IP destination address is 2025 set to the subnet-directed broadcast address of the mobile node's 2026 home network. This address MUST NOT be used as the destination IP 2027 address if the mobile node is registering via a foreign agent, 2028 although it MAY be used as the Home Agent address in the body of 2029 the Registration Request when registering via a foreign agent. 2031 IP Time to Live: 2033 o The IP TTL field MUST be set to 1 if the IP destination address is 2034 set to the "All Mobility Agents" multicast address as described 2035 above. Otherwise a suitable value should be chosen in accordance 2036 with standard IP practice [19]. 2038 3.6.1.2. Registration Request Fields 2040 This section provides specific rules by which mobile nodes pick 2041 values for the fields within the fixed portion of a Registration 2042 Request. 2044 A mobile node MAY set the 'S' bit in order to request that the home 2045 agent maintain prior mobility binding(s). Otherwise, the home agent 2046 deletes any previous binding(s) and replaces them with the new 2047 binding specified in the Registration Request. Multiple simultaneous 2048 mobility bindings are likely to be useful when a mobile node using at 2049 least one wireless network interface moves within wireless 2050 transmission range of more than one foreign agent. IP explicitly 2051 allows duplication of datagrams. When the home agent allows 2052 simultaneous bindings, it will tunnel a separate copy of each 2053 arriving datagram to each care-of address, and the mobile node will 2054 receive multiple copies of datagrams destined to it. 2056 The mobile node SHOULD set the 'D' bit if it is registering with a 2057 co-located care-of address. Otherwise, the 'D' bit MUST NOT be set. 2059 A mobile node MAY set the 'B' bit to request its home agent to 2060 forward to it, a copy of broadcast datagrams received by its home 2061 agent from the home network. The method used by the home agent to 2062 forward broadcast datagrams depends on the type of care-of address 2063 registered by the mobile node, as determined by the 'D' bit in the 2064 mobile node's Registration Request: 2066 o If the 'D' bit is set, then the mobile node has indicated that it 2067 will decapsulate any datagrams tunneled to this care-of address 2068 itself (the mobile node is using a co-located care-of address). 2069 In this case, to forward such a received broadcast datagram to the 2070 mobile node, the home agent MUST tunnel it to this care-of 2071 address. The mobile node de-tunnels the received datagram in the 2072 same way as any other datagram tunneled directly to it. 2074 o If the 'D' bit is NOT set, then the mobile node has indicated that 2075 it is using a foreign agent care-of address, and that the foreign 2076 agent will thus decapsulate arriving datagrams before forwarding 2077 them to the mobile node. In this case, to forward such a received 2078 broadcast datagram to the mobile node, the home agent MUST first 2079 encapsulate the broadcast datagram in a unicast datagram addressed 2080 to the mobile node's home address, and then MUST tunnel this 2081 resulting datagram to the mobile node's care-of address. 2083 When decapsulated by the foreign agent, the inner datagram will 2084 thus be a unicast IP datagram addressed to the mobile node, 2085 identifying to the foreign agent the intended destination of the 2086 encapsulated broadcast datagram, and will be delivered to the 2087 mobile node in the same way as any tunneled datagram arriving for 2088 the mobile node. The foreign agent MUST NOT decapsulate the 2089 encapsulated broadcast datagram and MUST NOT use a local network 2090 broadcast to transmit it to the mobile node. The mobile node thus 2091 MUST decapsulate the encapsulated broadcast datagram itself, and 2092 thus MUST NOT set the 'B' bit in its Registration Request in this 2093 case unless it is capable of decapsulating datagrams. 2095 The mobile node MAY request alternative forms of encapsulation by 2096 setting the 'M' bit and/or the 'G' bit, but only if the mobile node 2097 is decapsulating its own datagrams (the mobile node is using a co- 2098 located care-of address) or if its foreign agent has indicated 2099 support for these forms of encapsulation by setting the corresponding 2100 bits in the Mobility Agent Advertisement Extension of an Agent 2101 Advertisement received by the mobile node. Otherwise, the mobile 2102 node MUST NOT set these bits. 2104 The Lifetime field is chosen as follows: 2106 o If the mobile node is registering with a foreign agent, the 2107 Lifetime SHOULD NOT exceed the value in the Registration Lifetime 2108 field of the Agent Advertisement message received from the foreign 2109 agent. When the method by which the care-of address is learned 2110 does not include a Lifetime, the default ICMP Router Advertisement 2111 Lifetime (1800 seconds) MAY be used. 2113 o The mobile node MAY ask a home agent to delete a particular 2114 mobility binding, by sending a Registration Request with the 2115 care-of address for this binding, with the Lifetime field set to 2116 zero (Section 3.8.2). 2118 o Similarly, a Lifetime of zero is used when the mobile node 2119 deregisters all care-of addresses, such as upon returning home. 2121 The Home Address field MUST be set to the mobile node's home address, 2122 if this information is known. Otherwise, the Home Address MUST be 2123 set to zeroes. 2125 The Home Agent field MUST be set to the address of the mobile node's 2126 home agent, if the mobile node knows this address. Otherwise, the 2127 mobile node MAY use dynamic home agent address resolution to learn 2128 the address of its home agent. In this case, the mobile node MUST 2129 set the Home Agent field to the subnet-directed broadcast address of 2130 the mobile node's home network. Each home agent receiving such a 2131 Registration Request with a broadcast destination address MUST reject 2132 the mobile node's registration and SHOULD return a rejection 2133 Registration Reply indicating its unicast IP address for use by the 2134 mobile node in a future registration attempt. 2136 The Care-of Address field MUST be set to the value of the particular 2137 care-of address that the mobile node wishes to (de)register. In the 2138 special case in which a mobile node wishes to deregister all care-of 2139 addresses, it MUST set this field to its home address. 2141 The mobile node chooses the Identification field in accordance with 2142 the style of replay protection it uses with its home agent. This is 2143 part of the mobility security association the mobile node shares with 2144 its home agent. See Section 5.7 for the method by which the mobile 2145 node computes the Identification field. 2147 3.6.1.3. Extensions 2149 This section describes the ordering of any mandatory and any optional 2150 Extensions that a mobile node appends to a Registration Request. 2151 This ordering is REQUIRED: 2153 a. The IP header, followed by the UDP header, followed by the fixed- 2154 length portion of the Registration Request, followed by 2156 b. If present, any non-authentication Extensions expected to be used 2157 by the home agent or other authorizing agent (which may or may 2158 not also be useful to the foreign agent), followed by 2160 c. All authorization-enabling extensions (see Section 1.6), followed 2161 by 2163 d. If present, any non-authentication Extensions used only by the 2164 foreign agent, followed by 2166 e. The Mobile-Foreign Authentication Extension, if present. 2168 Note that items (a) and (c) MUST appear in every Registration Request 2169 sent by the mobile node. Items (b), (d), and (e) are optional. 2170 However, item (e) MUST be included when the mobile node and the 2171 foreign agent share a mobility security association. 2173 3.6.2. Receiving Registration Replies 2175 Registration Replies will be received by the mobile node in response 2176 to its Registration Requests. Registration Replies generally fall 2177 into three categories: 2179 o the registration was accepted, 2180 o the registration was denied by the foreign agent, or 2181 o the registration was denied by the home agent. 2183 The remainder of this section describes the Registration Reply 2184 handling by a mobile node in each of these three categories. 2186 3.6.2.1. Validity Checks 2188 Registration Replies with an invalid, non-zero UDP checksum MUST be 2189 silently discarded. 2191 In addition, the low-order 32 bits of the Identification field in the 2192 Registration Reply MUST be compared to the low-order 32 bits of the 2193 Identification field in the most recent Registration Request sent to 2194 the replying agent. If they do not match, the Reply MUST be silently 2195 discarded. 2197 Also, the Registration Reply MUST be checked for presence of an 2198 authorization-enabling extension. For all Registration Reply 2199 messages containing a Status Code indicating status from the Home 2200 Agent, the mobile node MUST check for the presence of an 2201 authorization-enabling extension, acting in accordance with the Code 2202 field in the Reply. The rules are as follows: 2204 a. If the mobile node and the foreign agent share a mobility 2205 security association, exactly one Mobile-Foreign Authentication 2206 Extension MUST be present in the Registration Reply, and the 2207 mobile node MUST check the Authenticator value in the Extension. 2208 If no Mobile-Foreign Authentication Extension is found, or if 2209 more than one Mobile-Foreign Authentication Extension is found, 2210 or if the Authenticator is invalid, the mobile node MUST silently 2211 discard the Reply and SHOULD log the event as a security 2212 exception. 2214 b. If the Code field indicates that service is denied by the home 2215 agent, or if the Code field indicates that the registration was 2216 accepted by the home agent, exactly one Mobile-Home 2217 Authentication Extension MUST be present in the Registration 2218 Reply, and the mobile node MUST check the Authenticator value in 2219 the Extension. If the Registration Reply was generated by the 2220 home agent but no Mobile-Home Authentication Extension is found, 2221 or if more than one Mobile-Home Authentication Extension is 2222 found, or if the Authenticator is invalid, the mobile node MUST 2223 silently discard the Reply and SHOULD log the event as a security 2224 exception. 2226 If the Code field indicates an authentication failure, either at the 2227 foreign agent or the home agent, then it is quite possible that any 2228 authenticators in the Registration Reply will also be in error. This 2229 could happen, for example, if the shared secret between the mobile 2230 node and home agent was erroneously configured. The mobile node 2231 SHOULD log such errors as security exceptions. 2233 3.6.2.2. Registration Request Accepted 2235 If the Code field indicates that the request has been accepted, the 2236 mobile node SHOULD configure its routing table appropriately for its 2237 current point of attachment (Section 4.2.1). 2239 If the mobile node is returning to its home network and that network 2240 is one which implements ARP, the mobile node MUST follow the 2241 procedures described in Section 4.6 with regard to ARP, proxy ARP, 2242 and gratuitous ARP. 2244 If the mobile node has registered on a foreign network, it SHOULD re- 2245 register before the expiration of the Lifetime of its registration. 2246 As described in Section 3.6, for each pending Registration Request, 2247 the mobile node MUST maintain the remaining lifetime of this pending 2248 registration, as well as the original Lifetime from the Registration 2249 Request. When the mobile node receives a valid Registration Reply, 2250 the mobile node MUST decrease its view of the remaining lifetime of 2251 the registration by the amount by which the home agent decreased the 2252 originally requested Lifetime. This procedure is equivalent to the 2253 mobile node starting a timer for the granted Lifetime at the time it 2254 sent the Registration Request, even though the granted Lifetime is 2255 not known to the mobile node until the Registration Reply is 2256 received. Since the Registration Request is certainly sent before 2257 the home agent begins timing the registration Lifetime (also based on 2258 the granted Lifetime), this procedure ensures that the mobile node 2259 will re-register before the home agent expires and deletes the 2260 registration, in spite of possibly non-negligible transmission delays 2261 for the original Registration Request and Reply that started the 2262 timing of the Lifetime at the mobile node and its home agent. 2264 3.6.2.3. Registration Request Denied 2266 If the Code field indicates that service is being denied, the mobile 2267 node SHOULD log the error. In certain cases the mobile node may be 2268 able to "repair" the error. These include: 2270 Code 69: (Denied by foreign agent, Lifetime too long) 2272 In this case, the Lifetime field in the Registration Reply will 2273 contain the maximum Lifetime value which that foreign agent is 2274 willing to accept in any Registration Request. The mobile node 2275 MAY attempt to register with this same agent, using a Lifetime in 2276 the Registration Request that MUST be less than or equal to the 2277 value specified in the Reply. 2279 Code 133: (Denied by home agent, Identification mismatch) 2281 In this case, the Identification field in the Registration Reply 2282 will contain a value that allows the mobile node to synchronize 2283 with the home agent, based upon the style of replay protection in 2284 effect (Section 5.7). The mobile node MUST adjust the parameters 2285 it uses to compute the Identification field based upon the 2286 information in the Registration Reply, before issuing any future 2287 Registration Requests. 2289 Code 136: (Denied by home agent, Unknown home agent address) 2291 This code is returned by a home agent when the mobile node is 2292 performing dynamic home agent address resolution as described in 2293 Section 3.6.1.1 and Section 3.6.1.2. In this case, the Home Agent 2294 field within the Reply will contain the unicast IP address of the 2295 home agent returning the Reply. The mobile node MAY then attempt 2296 to register with this home agent in future Registration Requests. 2297 In addition, the mobile node SHOULD adjust the parameters it uses 2298 to compute the Identification field based upon the corresponding 2299 field in the Registration Reply, before issuing any future 2300 Registration Requests. 2302 3.6.3. Registration Retransmission 2304 When no Registration Reply has been received within a reasonable 2305 time, another Registration Request MAY be transmitted. When 2306 timestamps are used, a new registration Identification is chosen for 2307 each retransmission; thus it counts as a new registration. When 2308 nonces are used, the unanswered Request is retransmitted unchanged; 2309 thus the retransmission does not count as a new registration 2310 (Section 5.7). In this way a retransmission will not require the 2311 home agent to resynchronize with the mobile node by issuing another 2312 nonce in the case in which the original Registration Request (rather 2313 than its Registration Reply) was lost by the network. 2315 The maximum time until a new Registration Request is sent SHOULD be 2316 no greater than the requested Lifetime of the Registration Request. 2317 The minimum value SHOULD be large enough to account for the size of 2318 the messages, twice the round trip time for transmission to the home 2319 agent, and at least an additional 100 milliseconds to allow for 2320 processing the messages before responding. The round trip time for 2321 transmission to the home agent will be at least as large as the time 2322 required to transmit the messages at the link speed of the mobile 2323 node's current point of attachment. Some circuits add another 200 2324 milliseconds of satellite delay in the total round trip time to the 2325 home agent. The minimum time between Registration Requests MUST NOT 2326 be less than 1 second. Each successive retransmission timeout period 2327 SHOULD be at least twice the previous period, as long as that is less 2328 than the maximum as specified above. 2330 3.7. Foreign Agent Considerations 2332 The foreign agent plays a mostly passive role in Mobile IP 2333 registration. It relays Registration Requests between mobile nodes 2334 and home agents, and, when it provides the care-of address, 2335 decapsulates datagrams for delivery to the mobile node. It SHOULD 2336 also send periodic Agent Advertisement messages to advertise its 2337 presence as described in Section 2.3, if not detectable by link-layer 2338 means. 2340 A foreign agent MUST NOT transmit a Registration Request except when 2341 relaying a Registration Request received from a mobile node, to the 2342 mobile node's home agent. A foreign agent MUST NOT transmit a 2343 Registration Reply except when relaying a Registration Reply received 2344 from a mobile node's home agent, or when replying to a Registration 2345 Request received from a mobile node in the case in which the foreign 2346 agent is denying service to the mobile node. In particular, a 2347 foreign agent MUST NOT generate a Registration Request or Reply 2348 because a mobile node's registration Lifetime has expired. A foreign 2349 agent also MUST NOT originate a Registration Request message that 2350 asks for deregistration of a mobile node; however, it MUST relay 2351 well-formed (de)Registration Requests originated by a mobile node. 2353 3.7.1. Configuration and Registration Tables 2355 Each foreign agent MUST be configured with a care-of address. In 2356 addition, for each pending or current registration the foreign agent 2357 MUST maintain a visitor list entry containing the following 2358 information obtained from the mobile node's Registration Request: 2360 o the link-layer source address of the mobile node 2361 o the IP Source Address (the mobile node's Home Address) or its co- 2362 located care-of address (see description of the 'R' bit in 2363 Section 2.1.1) 2364 o the IP Destination Address (as specified in Section 3.6.1.1 2365 o the UDP Source Port 2366 o the Home Agent address 2367 o the Identification field 2368 o the requested registration Lifetime, and 2369 o the remaining Lifetime of the pending or current registration. 2371 If there is an NAI extension in the Registration Request message 2372 (often, for example, when the mobile node's Home Address is zero), 2373 then the foreign agent MUST follow the procedures specified in RFC 2374 2794 [2]. In particular, if the foreign agent cannot manage pending 2375 registration request records with such a zero Home Address for the 2376 mobile node, the foreign agent MUST return a Registration Reply with 2377 Code indicating NONZERO_HOMEADDR_REQD (see [2]). 2379 The foreign agent MAY configure a maximum number of pending 2380 registrations that it is willing to maintain (typically 5). 2381 Additional registrations SHOULD then be rejected by the foreign agent 2382 with code 66. The foreign agent MAY delete any pending Registration 2383 Request after the request has been pending for more than 7 seconds; 2384 in this case, the foreign agent SHOULD reject the Request with code 2385 78 (registration timeout). 2387 As with any node on the Internet, a foreign agent MAY also share 2388 mobility security associations with any other nodes. When relaying a 2389 Registration Request from a mobile node to its home agent, if the 2390 foreign agent shares a mobility security association with the home 2391 agent, it MUST add a Foreign-Home Authentication Extension to the 2392 Request. In this case, when the Registration Reply has nonzero 2393 lifetime, the foreign agent MUST check the required Foreign-Home 2394 Authentication Extension in the Registration Reply from the home 2395 agent (Section 3.3 and Section 3.4). Similarly, when receiving a 2396 Registration Request from a mobile node, if the foreign agent shares 2397 a mobility security association with the mobile node, it MUST check 2398 the required Mobile-Foreign Authentication Extension in the Request 2399 and MUST add a Mobile-Foreign Authentication Extension to the 2400 Registration Reply to the mobile node. 2402 3.7.2. Receiving Registration Requests 2404 If the foreign agent accepts a Registration Request from a mobile 2405 node, it checks to make sure that the indicated home agent address 2406 does not belong to any network interface of the foreign agent. If 2407 not, the foreign agent then MUST relay the Request to the indicated 2408 home agent. Otherwise, if the foreign agent denies the Request, it 2409 MUST send a Registration Reply to the mobile node with an appropriate 2410 denial Code, except in cases where the foreign agent would be 2411 required to send out more than one such denial per second to the same 2412 mobile node. The following sections describe this behavior in more 2413 detail. 2415 If the foreign agent has configured one of its network interfaces 2416 with the IP address specified by the mobile node as its home agent 2417 address, the foreign agent MUST NOT forward the request again. If 2418 the foreign agent serves the mobile node as a home agent, the foreign 2419 agent follows the procedures specified in Section 3.8.2. Otherwise, 2420 if the foreign agent does not serve the mobile node as a home agent, 2421 the foreign agent rejects the Registration Request with code TBD-IANA 2422 (Invalid Home Agent Address). 2424 If a foreign agent receives a Registration Request from a mobile node 2425 in its visitor list, the existing visitor list entry for the mobile 2426 node SHOULD NOT be deleted or modified until the foreign agent 2427 receives a valid Registration Reply from the home agent with a Code 2428 indicating success. The foreign agent MUST record the new pending 2429 Request as a separate part of the existing visitor list entry for the 2430 mobile node. If the Registration Request requests deregistration, 2431 the existing visitor list entry for the mobile node SHOULD NOT be 2432 deleted until the foreign agent has received a successful 2433 Registration Reply. If the Registration Reply indicates that the 2434 Request (for registration or deregistration) was denied by the home 2435 agent, the existing visitor list entry for the mobile node MUST NOT 2436 be modified as a result of receiving the Registration Reply. 2438 3.7.2.1. Validity Checks 2440 Registration Requests with an invalid, non-zero UDP checksum MUST be 2441 silently discarded. Requests with non-zero bits in reserved fields 2442 MUST be rejected with code 70 (poorly formed request). Requests with 2443 the 'D' bit set to 0, nonzero lifetime, and specifying a care-of 2444 address not offered by the foreign agent, MUST be rejected with code 2445 77 (invalid care-of address). 2447 Also, the authentication in the Registration Request MUST be checked. 2448 If the foreign agent and the mobile node share a mobility security 2449 association, exactly one Mobile-Foreign Authentication Extension MUST 2450 be present in the Registration Request, and the foreign agent MUST 2451 check the Authenticator value in the Extension. If no Mobile-Foreign 2452 Authentication Extension is found, or if more than one Mobile-Foreign 2453 Authentication Extension is found, or if the Authenticator is 2454 invalid, the foreign agent MUST silently discard the Request and 2455 SHOULD log the event as a security exception. The foreign agent also 2456 SHOULD send a Registration Reply to the mobile node with Code 67. 2458 3.7.2.2. Forwarding a Valid Request to the Home Agent 2460 If the foreign agent accepts the mobile node's Registration Request, 2461 it MUST relay the Request to the mobile node's home agent as 2462 specified in the Home Agent field of the Registration Request. The 2463 foreign agent MUST NOT modify any of the fields beginning with the 2464 fixed portion of the Registration Request up through and including 2465 the Mobile-Home Authentication Extension or other authentication 2466 extension supplied by the mobile node as an authorization-enabling 2467 extension for the home agent. Otherwise, an authentication failure 2468 is very likely to occur at the home agent. In addition, the foreign 2469 agent proceeds as follows: 2471 o It MUST process and remove any extensions which do not precede any 2472 authorization-enabling extension. 2473 o It MAY append any of its own non-authentication Extensions of 2474 relevance to the home agent, if applicable, and 2475 o It MUST append the Foreign-Home Authentication Extension, if the 2476 foreign agent shares a mobility security association with the home 2477 agent. 2479 Specific fields within the IP header and the UDP header of the 2480 relayed Registration Request MUST be set as follows: 2482 IP Source Address 2484 The care-of address offered by the foreign agent for the mobile 2485 node sending the Registration Request. 2487 IP Destination Address 2489 Copied from the Home Agent field within the Registration Request. 2491 UDP Source Port 2493 variable 2495 UDP Destination Port 2497 434 2499 After forwarding a valid Registration Request to the home agent, the 2500 foreign agent MUST begin timing the remaining lifetime of the pending 2501 registration based on the Lifetime in the Registration Request. If 2502 this lifetime expires before receiving a valid Registration Reply, 2503 the foreign agent MUST delete its visitor list entry for this pending 2504 registration. 2506 3.7.2.3. Denying Invalid Requests 2508 If the foreign agent denies the mobile node's Registration Request 2509 for any reason, it SHOULD send the mobile node a Registration Reply 2510 with a suitable denial Code. In such a case, the Home Address, Home 2511 Agent, and Identification fields within the Registration Reply are 2512 copied from the corresponding fields of the Registration Request. 2514 If the Reserved field is nonzero, the foreign agent MUST deny the 2515 Request and SHOULD return a Registration Reply with status code 70 to 2516 the mobile node. If the Request is being denied because the 2517 requested Lifetime is too long, the foreign agent sets the Lifetime 2518 in the Reply to the maximum Lifetime value it is willing to accept in 2519 any Registration Request, and sets the Code field to 69. Otherwise, 2520 the Lifetime SHOULD be copied from the Lifetime field in the Request. 2522 Specific fields within the IP header and the UDP header of the 2523 Registration Reply MUST be set as follows: 2525 IP Source Address 2527 Copied from the IP Destination Address of Registration Request, 2528 unless the "All Agents Multicast" address was used. In this case, 2529 the foreign agent's address (on the interface from which the 2530 message will be sent) MUST be used. 2532 IP Destination Address 2534 If the Registration Reply is generated by the Foreign Agent in 2535 order to reject a mobile node's Registration Request, and the 2536 Registration Request contains a Home Address which is not 0.0.0.0, 2537 then the IP Destination Address is copied from the Home Address 2538 field of the Registration Request. Otherwise, if the Registration 2539 Reply is received from the Home Agent, and contains a Home Address 2540 which is not 0.0.0.0, then the IP Destination Address is copied 2541 from the Home Address field of the Registration Reply. Otherwise, 2542 the IP Destination Address of the Registration Reply is set to be 2543 255.255.255.255. 2545 UDP Source Port 2547 434 2549 UDP Destination Port 2551 Copied from the UDP Source Port of the Registration Request. 2553 3.7.3. Receiving Registration Replies 2555 The foreign agent updates its visitor list when it receives a valid 2556 Registration Reply from a home agent. It then relays the 2557 Registration Reply to the mobile node. The following sections 2558 describe this behavior in more detail. 2560 If upon relaying a Registration Request to a home agent, the foreign 2561 agent receives an ICMP error message instead of a Registration Reply, 2562 then the foreign agent SHOULD send to the mobile node a Registration 2563 Reply with an appropriate "Home Agent Unreachable" failure Code 2564 (within the range 80-95, inclusive). See Section 3.7.2.3 for details 2565 on building the Registration Reply. 2567 3.7.3.1. Validity Checks 2569 Registration Replies with an invalid, non-zero UDP checksum MUST be 2570 silently discarded. 2572 When a foreign agent receives a Registration Reply message, it MUST 2573 search its visitor list for a pending Registration Request with the 2574 same mobile node home address as indicated in the Reply. If there 2575 are multiple entries with the same home address, and if the 2576 Registration Reply has the Mobile Node NAI extension [2], the foreign 2577 agent MUST use the NAI to disambiguate the pending Registration 2578 Requests with the same home address. If no matching pending Request 2579 is found, and if the Registration Reply does not correspond with any 2580 pending Registration Request with a zero mobile node home address 2581 (see Section 3.7.1), the foreign agent MUST silently discard the 2582 Reply. The foreign agent MUST also silently discard the Reply if the 2583 low-order 32 bits of the Identification field in the Reply do not 2584 match those in the Request. 2586 Also, the authentication in the Registration Reply MUST be checked. 2587 If the foreign agent and the home agent share a mobility security 2588 association, exactly one Foreign-Home Authentication Extension MUST 2589 be present in the Registration Reply, and the foreign agent MUST 2590 check the Authenticator value in the Extension. If no Foreign-Home 2591 Authentication Extension is found, or if more than one Foreign-Home 2592 Authentication Extension is found, or if the Authenticator is 2593 invalid, the foreign agent MUST silently discard the Reply and SHOULD 2594 log the event as a security exception. The foreign agent also MUST 2595 reject the mobile node's registration and SHOULD send a Registration 2596 Reply to the mobile node with Code 68. 2598 3.7.3.2. Forwarding Replies to the Mobile Node 2600 A Registration Reply which satisfies the validity checks of 2601 Section 3.8.2.1 is relayed to the mobile node. The foreign agent 2602 MUST also update its visitor list entry for the mobile node to 2603 reflect the results of the Registration Request, as indicated by the 2604 Code field in the Reply. If the Code indicates that the home agent 2605 has accepted the registration and the Lifetime field is nonzero, the 2606 foreign agent SHOULD set the Lifetime in the visitor list entry to 2607 the minimum of the following two values: 2609 o the value specified in the Lifetime field of the Registration 2610 Reply, and 2612 o the foreign agent's own maximum value for allowable registration 2613 lifetime. 2615 If, instead, the Code indicates that the Lifetime field is zero, the 2616 foreign agent MUST delete its visitor list entry for the mobile node. 2617 Finally, if the Code indicates that the registration was denied by 2618 the home agent, the foreign agent MUST delete its pending 2619 registration list entry, but not its visitor list entry, for the 2620 mobile node. 2622 The foreign agent MUST NOT modify any of the fields beginning with 2623 the fixed portion of the Registration Reply up through and including 2624 the Mobile-Home Authentication Extension. Otherwise, an 2625 authentication failure is very likely to occur at the mobile node. 2626 In addition, the foreign agent SHOULD perform the following 2627 additional procedures: 2629 o It MUST process and remove any Extensions which are not covered by 2630 any authorization-enabling extension. 2631 o It MAY append its own non-authentication Extensions that supply 2632 information to the mobile node, if applicable, and 2633 o It MUST append the Mobile-Foreign Authentication Extension, if the 2634 foreign agent shares a mobility security association with the 2635 mobile node. 2637 Specific fields within the IP header and the UDP header of the 2638 relayed Registration Reply are set according to the same rules 2639 specified in Section 3.7.2.3. 2641 After forwarding a valid Registration Reply to the mobile node, the 2642 foreign agent MUST update its visitor list entry for this 2643 registration as follows. If the Registration Reply indicates that 2644 the registration was accepted by the home agent, the foreign agent 2645 resets its timer of the lifetime of the registration to the Lifetime 2646 granted in the Registration Reply; unlike the mobile node's timing of 2647 the registration lifetime as described in Section 3.6.2.2, the 2648 foreign agent considers this lifetime to begin when it forwards the 2649 Registration Reply message, ensuring that the foreign agent will not 2650 expire the registration before the mobile node does. On the other 2651 hand, if the Registration Reply indicates that the registration was 2652 rejected by the home agent, the foreign agent deletes its visitor 2653 list entry for this attempted registration. 2655 3.8. Home Agent Considerations 2657 Home agents play a reactive role in the registration process. The 2658 home agent receives Registration Requests from the mobile node 2659 (perhaps relayed by a foreign agent), updates its record of the 2660 mobility bindings for this mobile node, and issues a suitable 2661 Registration Reply in response to each. 2663 A home agent MUST NOT transmit a Registration Reply except when 2664 replying to a Registration Request received from a mobile node. In 2665 particular, the home agent MUST NOT generate a Registration Reply to 2666 indicate that the Lifetime has expired. 2668 3.8.1. Configuration and Registration Tables 2670 Each home agent MUST be configured with an IP address and with the 2671 prefix size for the home network. The home agent MUST be configured 2672 with the mobility security association of each authorized mobile node 2673 that it is serving as a home agent. 2675 When the home agent accepts a valid Registration Request from a 2676 mobile node that it serves as a home agent, the home agent MUST 2677 create or modify the entry for this mobile node in its mobility 2678 binding list containing: 2680 o the mobile node's home address 2681 o the mobile node's care-of address 2682 o the Identification field from the Registration Reply 2683 o the remaining Lifetime of the registration 2685 The home agent MAY optionally offer the capability to dynamically 2686 associate a home address to a mobile node upon receiving a 2687 Registration Request from that mobile node. The method by which a 2688 home address is allocated to the mobile node is beyond the scope of 2689 this document, but see [2]. After the home agent makes the 2690 association of the home address to the mobile node, the home agent 2691 MUST put that home address into the Home Address field of the 2692 Registration Reply. 2694 The home agent MAY also maintain mobility security associations with 2695 various foreign agents. When receiving a Registration Request from a 2696 foreign agent, if the home agent shares a mobility security 2697 association with the foreign agent, the home agent MUST check the 2698 Authenticator in the required Foreign-Home Authentication Extension 2699 in the message, based on this mobility security association, unless 2700 the Lifetime field equals 0. When processing a Registration Request 2701 with Lifetime=0, the HA MAY skip checking for the presence and 2702 validity of a Foreign-Home Authentication Extension. Similarly, when 2703 sending a Registration Reply to a foreign agent, if the home agent 2704 shares a mobility security association with the foreign agent, the 2705 home agent MUST include a Foreign-Home Authentication Extension in 2706 the message, based on this mobility security association. 2708 3.8.2. Receiving Registration Requests 2710 If the home agent accepts an incoming Registration Request, it MUST 2711 update its record of the the mobile node's mobility binding(s) and 2712 SHOULD send a Registration Reply with a suitable Code. Otherwise 2713 (the home agent denies the Request), it SHOULD send a Registration 2714 Reply with an appropriate Code specifying the reason the Request was 2715 denied. The following sections describe this behavior in more 2716 detail. If the home agent does not support broadcasts (see 2717 Section 4.3), it MUST ignore the 'B' bit (as opposed to rejecting the 2718 Registration Request). 2720 3.8.2.1. Validity Checks 2722 Registration Requests with an invalid, non-zero UDP checksum MUST be 2723 silently discarded by the home agent. 2725 The authentication in the Registration Request MUST be checked. This 2726 involves the following operations: 2728 a. The home agent MUST check for the presence of at least one 2729 authorization-enabling extension, and ensure that all indicated 2730 authentications are carried out. At least one authorization- 2731 enabling extension MUST be present in the Registration Request; 2732 and the home agent MUST either check the Authenticator value in 2733 the extension or verify that the authenticator value has been 2734 checked by another agent with which it has a security 2735 association. If no authorization-enabling extension is found, or 2736 if the Authenticator is invalid, the home agent MUST reject the 2737 mobile node's registration and SHOULD send a Registration Reply 2738 to the mobile node with Code 131. The home agent MUST then 2739 discard the Request and SHOULD log the error as a security 2740 exception. If the home agent receives a Registration Request 2741 without a Mobile-Home Authentication extension from a Mobile Node 2742 that has a security association with this home agent, the home 2743 agent MUST discard the Mobile Node's Registration Request. 2745 b. The home agent MUST check that the registration Identification 2746 field is correct using the context selected by the SPI within the 2747 authorization-enabling extension that the home agent used to 2748 authenticate the Mobile Node's Registration Request. See 2749 Section 5.7 for a description of how this is performed. If 2750 incorrect, the home agent MUST reject the Request and SHOULD send 2751 a Registration Reply to the mobile node with Code 133, including 2752 an Identification field computed in accordance with the rules 2753 specified in Section 5.7. The home agent MUST do no further 2754 processing with such a Request, though it SHOULD log the error as 2755 a security exception. 2757 c. If the home agent shares a mobility security association with the 2758 foreign agent, and this is a registration request (has non-zero 2759 lifetime), the home agent MUST check for the presence of a valid 2760 Foreign-Home Authentication Extension. Exactly one Foreign-Home 2761 Authentication Extension MUST be present in the Registration 2762 Request in this case, and the home agent MUST check the 2763 Authenticator value in the Extension. If no Foreign-Home 2764 Authentication Extension is found, or if more than one Foreign- 2765 Home Authentication Extension is found, or if the Authenticator 2766 is invalid, the home agent MUST reject the mobile node's 2767 registration and SHOULD send a Registration Reply to the mobile 2768 node with Code 132. The home agent MUST then discard the Request 2769 and SHOULD log the error as a security exception. 2771 In addition to checking the authentication in the Registration 2772 Request, home agents MUST deny Registration Requests that are sent to 2773 the subnet-directed broadcast address of the home network (as opposed 2774 to being unicast to the home agent). The home agent MUST discard the 2775 Request and SHOULD returning a Registration Reply with a Code of 136. 2776 In this case, the Registration Reply will contain the home agent's 2777 unicast address, so that the mobile node can re-issue the 2778 Registration Request with the correct home agent address. 2780 Note that some routers change the IP destination address of a 2781 datagram from a subnet-directed broadcast address to 255.255.255.255 2782 before injecting it into the destination subnet. In this case, home 2783 agents that attempt to pick up dynamic home agent discovery requests 2784 by binding a socket explicitly to the subnet-directed broadcast 2785 address will not see such packets. Home agent implementors should be 2786 prepared for both the subnet-directed broadcast address and 2787 255.255.255.255 if they wish to support dynamic home agent discovery. 2789 3.8.2.2. Accepting a Valid Request 2791 If the Registration Request satisfies the validity checks in 2792 Section 3.8.2.1, and the home agent is able to accommodate the 2793 Request, the home agent MUST update its mobility binding list for the 2794 requesting mobile node and MUST return a Registration Reply to the 2795 mobile node. In this case, the Reply Code will be either 0 if the 2796 home agent supports simultaneous mobility bindings, or 1 if it does 2797 not. See Section 3.8.3 for details on building the Registration 2798 Reply message. 2800 The home agent updates its record of the mobile node's mobility 2801 bindings as follows, based on the fields in the Registration Request: 2803 o If the Lifetime is zero and the Care-of Address equals the mobile 2804 node's home address, the home agent deletes all of the entries in 2805 the mobility binding list for the requesting mobile node. This is 2806 how a mobile node requests that its home agent cease providing 2807 mobility services. 2809 o If the Lifetime is zero and the Care-of Address does not equal the 2810 mobile node's home address, the home agent deletes only the entry 2811 containing the specified Care-of Address from the mobility binding 2812 list for the requesting mobile node. Any other active entries 2813 containing other care-of addresses will remain active. 2815 o If the Lifetime is nonzero, the home agent adds an entry 2816 containing the requested Care-of Address to the mobility binding 2817 list for the mobile node. If the 'S' bit is set and the home 2818 agent supports simultaneous mobility bindings, the previous 2819 mobility binding entries are retained. Otherwise, the home agent 2820 removes all previous entries in the mobility binding list for the 2821 mobile node. 2823 In all cases, the home agent MUST send a Registration Reply to the 2824 source of the Registration Request, which might indeed be a different 2825 foreign agent than that whose care-of address is being 2826 (de)registered. If the home agent shares a mobility security 2827 association with the foreign agent whose care-of address is being 2828 deregistered, and that foreign agent is different from the one which 2829 relayed the Registration Request, the home agent MAY additionally 2830 send a Registration Reply to the foreign agent whose care-of address 2831 is being deregistered. The home agent MUST NOT send such a Reply if 2832 it does not share a mobility security association with the foreign 2833 agent. If no Reply is sent, the foreign agent's visitor list will 2834 expire naturally when the original Lifetime expires. 2836 When a foreign agent relays a deregistration message containing a 2837 care-of address that it does not own, it MUST NOT add a Foreign-Home 2838 Authentication Extension to that deregistration. See Section 3.5.4 2839 for more details. 2841 The home agent MUST NOT increase the Lifetime above that specified by 2842 the mobile node in the Registration Request. However, it is not an 2843 error for the mobile node to request a Lifetime longer than the home 2844 agent is willing to accept. In this case, the home agent simply 2845 reduces the Lifetime to a permissible value and returns this value in 2846 the Registration Reply. The Lifetime value in the Registration Reply 2847 informs the mobile node of the granted lifetime of the registration, 2848 indicating when it SHOULD re-register in order to maintain continued 2849 service. After the expiration of this registration lifetime, the 2850 home agent MUST delete its entry for this registration in its 2851 mobility binding list. 2853 If the Registration Request duplicates an accepted current 2854 Registration Request, the new Lifetime MUST NOT extend beyond the 2855 Lifetime originally granted. A Registration Request is a duplicate 2856 if the home address, care-of address, and Identification fields all 2857 equal those of an accepted current registration. 2859 In addition, if the home network implements ARP [17], and the 2860 Registration Request asks the home agent to create a mobility binding 2861 for a mobile node which previously had no binding (the mobile node 2862 was previously assumed to be at home), then the home agent MUST 2863 follow the procedures described in Section 4.6 with regard to ARP, 2864 proxy ARP, and gratuitous ARP. If the mobile node already had a 2865 previous mobility binding, the home agent MUST continue to follow the 2866 rules for proxy ARP described in Section 4.6. 2868 3.8.2.3. Denying an Invalid Request 2870 If the Registration Request does not satisfy all of the validity 2871 checks in Section 3.8.2.1, or the home agent is unable to accommodate 2872 the Request, the home agent SHOULD return a Registration Reply to the 2873 mobile node with a Code that indicates the reason for the error. If 2874 a foreign agent was involved in relaying the Request, this allows the 2875 foreign agent to delete its pending visitor list entry. Also, this 2876 informs the mobile node of the reason for the error such that it may 2877 attempt to fix the error and issue another Request. 2879 This section lists a number of reasons the home agent might reject a 2880 Request, and provides the Code value it should use in each instance. 2881 See Section 3.8.3 for additional details on building the Registration 2882 Reply message. 2884 Many reasons for rejecting a registration are administrative in 2885 nature. For example, a home agent can limit the number of 2886 simultaneous registrations for a mobile node, by rejecting any 2887 registrations that would cause its limit to be exceeded, and 2888 returning a Registration Reply with error code 135. Similarly, a 2889 home agent may refuse to grant service to mobile nodes which have 2890 entered unauthorized service areas by returning a Registration Reply 2891 with a Code of 129. 2893 Requests with non-zero bits in reserved fields MUST be rejected with 2894 code 134 (poorly formed request). 2896 3.8.3. Sending Registration Replies 2898 If the home agent accepts a Registration Request, it then MUST update 2899 its record of the mobile node's mobility binding(s) and SHOULD send a 2900 Registration Reply with a suitable Code. Otherwise (the home agent 2901 has denied the Request), it SHOULD send a Registration Reply with an 2902 appropriate Code specifying the reason the Request was denied. The 2903 following sections provide additional detail for the values the home 2904 agent MUST supply in the fields of Registration Reply messages. 2906 3.8.3.1. IP/UDP Fields 2908 This section provides the specific rules by which home agents pick 2909 values for the IP and UDP header fields of a Registration Reply. 2911 IP Source Address 2913 Copied from the IP Destination Address of Registration Request, 2914 unless a multicast or broadcast address was used. If the IP 2915 Destination Address of the Registration Request was a broadcast or 2916 multicast address, the IP Source Address of the Registration Reply 2917 MUST be set to the home agent's (unicast) IP address. 2919 IP Destination Address 2921 Copied from the IP Source Address of the Registration Request. 2923 UDP Source Port 2925 Copied from the UDP Destination Port of the Registration Request. 2927 UDP Destination Port 2929 Copied from the UDP Source Port of the Registration Request. 2931 When sending a Registration Reply in response to a Registration 2932 Request that requested deregistration of the mobile node (the 2933 Lifetime is zero and the Care-of Address equals the mobile node's 2934 home address) and in which the IP Source Address was also set to the 2935 mobile node's home address (this is the normal method used by a 2936 mobile node to deregister when it returns to its home network), the 2937 IP Destination Address in the Registration Reply will be set to the 2938 mobile node's home address, as copied from the IP Source Address of 2939 the Request. 2941 In this case, when transmitting the Registration Reply, the home 2942 agent MUST transmit the Reply directly onto the home network as if 2943 the mobile node were at home, bypassing any mobility binding list 2944 entry that may still exist at the home agent for the destination 2945 mobile node. In particular, for a mobile node returning home after 2946 being registered with a care-of address, if the mobile node's new 2947 Registration Request is not accepted by the home agent, the mobility 2948 binding list entry for the mobile node will still indicate that 2949 datagrams addressed to the mobile node should be tunneled to the 2950 mobile node's registered care-of address; when sending the 2951 Registration Reply indicating the rejection of this Request, this 2952 existing binding list entry MUST be ignored, and the home agent MUST 2953 transmit this Reply as if the mobile node were at home. 2955 3.8.3.2. Registration Reply Fields 2957 This section provides the specific rules by which home agents pick 2958 values for the fields within the fixed portion of a Registration 2959 Reply. 2961 The Code field of the Registration Reply is chosen in accordance with 2962 the rules specified in the previous sections. When replying to an 2963 accepted registration, a home agent SHOULD respond with Code 1 if it 2964 does not support simultaneous registrations. 2966 The Lifetime field MUST be copied from the corresponding field in the 2967 Registration Request, unless the requested value is greater than the 2968 maximum length of time the home agent is willing to provide the 2969 requested service. In such a case, the Lifetime MUST be set to the 2970 length of time that service will actually be provided by the home 2971 agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed 2972 by the home agent (for this mobile node and care-of address). 2974 If the Home Address field of the Registration Request is nonzero, it 2975 MUST be copied into the Home Address field of the Registration Reply 2976 message. If the Home Agent cannot support the specified nonzero 2977 unicast address in the Home Address field of the Registration 2978 Request, then the Home Agent MUST reject the Registration Request 2979 with an error code of 129. 2981 Otherwise, if the Home Address field of the Registration Request is 2982 zero as specified in Section 3.6, the home agent SHOULD arrange for 2983 the selection of a home address for the mobile node, and insert the 2984 selected address into the Home Address field of the Registration 2985 Reply message. See [2] for further relevant details in the case 2986 where mobile nodes identify themselves using an NAI instead of their 2987 IP home address. 2989 If the Home Agent field in the Registration Request contains a 2990 unicast address of this home agent, then that field MUST be copied 2991 into the Home Agent field of the Registration Reply. Otherwise, the 2992 home agent MUST set the Home Agent field in the Registration Reply to 2993 its unicast address. In this latter case, the home agent MUST reject 2994 the registration with a suitable code (e.g., Code 136) to prevent the 2995 mobile node from possibly being simultaneously registered with two or 2996 more home agents. 2998 3.8.3.3. Extensions 3000 This section describes the ordering of any required and any optional 3001 Mobile IP Extensions that a home agent appends to a Registration 3002 Reply. The following ordering MUST be followed: 3004 a. The IP header, followed by the UDP header, followed by the fixed- 3005 length portion of the Registration Reply, 3007 b. If present, any non-authentication Extensions used by the mobile 3008 node (which may or may not also be used by the foreign agent), 3010 c. The Mobile-Home Authentication Extension, 3012 d. If present, any non-authentication Extensions used only by the 3013 foreign agent, and 3015 e. The Foreign-Home Authentication Extension, if present. 3017 Note that items (a) and (c) MUST appear in every Registration Reply 3018 sent by the home agent. Items (b), (d), and (e) are optional. 3019 However, item (e) MUST be included when the home agent and the 3020 foreign agent share a mobility security association. 3022 4. Routing Considerations 3024 This section describes how mobile nodes, home agents, and (possibly) 3025 foreign agents cooperate to route datagrams to/from mobile nodes that 3026 are connected to a foreign network. The mobile node informs its home 3027 agent of its current location using the registration procedure 3028 described in Section 3. See the protocol overview in Section 1.7 for 3029 the relative locations of the mobile node's home address with respect 3030 to its home agent, and the mobile node itself with respect to any 3031 foreign agent with which it might attempt to register. 3033 4.1. Encapsulation Types 3035 Home agents and foreign agents MUST support tunneling datagrams using 3036 IP in IP encapsulation [15]. Any mobile node that uses a co-located 3037 care-of address MUST support receiving datagrams tunneled using IP in 3038 IP encapsulation. Minimal encapsulation [16] and GRE encapsulation 3039 [13] are alternate encapsulation methods which MAY optionally be 3040 supported by mobility agents and mobile nodes. The use of these 3041 alternative forms of encapsulation, when requested by the mobile 3042 node, is otherwise at the discretion of the home agent. 3044 4.2. Unicast Datagram Routing 3046 4.2.1. Mobile Node Considerations 3048 When connected to its home network, a mobile node operates without 3049 the support of mobility services. That is, it operates in the same 3050 way as any other (fixed) host or router. The method by which a 3051 mobile node selects a default router when connected to its home 3052 network, or when away from home and using a co-located care-of 3053 address, is outside the scope of this document. ICMP Router 3054 Advertisement [5] is one such method. 3056 When registered on a foreign network, the mobile node chooses a 3057 default router by the following rules: 3059 o If the mobile node is registered using a foreign agent care-of 3060 address, it MAY use its foreign agent as a first-hop router. The 3061 foreign agent's MAC address can be learned from Agent 3062 Advertisement. Otherwise, the mobile node MUST choose its default 3063 router from among the Router Addresses advertised in the ICMP 3064 Router Advertisement portion of that Agent Advertisement message. 3066 o If the mobile node is registered directly with its home agent 3067 using a co-located care-of address, then the mobile node SHOULD 3068 choose its default router from among those advertised in any ICMP 3069 Router Advertisement message that it receives for which its 3070 externally obtained care-of address and the Router Address match 3071 under the network prefix. If the mobile node's externally 3072 obtained care-of address matches the IP source address of the 3073 Agent Advertisement under the network prefix, the mobile node MAY 3074 also consider that IP source address as another possible choice 3075 for the IP address of a default router. The network prefix MAY be 3076 obtained from the Prefix-Lengths Extension in the Router 3077 Advertisement, if present. The prefix MAY also be obtained 3078 through other mechanisms beyond the scope of this document. 3080 While they are away from the home network, mobile nodes MUST NOT 3081 broadcast ARP packets to find the MAC address of another Internet 3082 node. Thus, the (possibly empty) list of Router Addresses from the 3083 ICMP Router Advertisement portion of the message is not useful for 3084 selecting a default router, unless the mobile node has some means not 3085 involving broadcast ARP and not specified within this document for 3086 obtaining the MAC address of one of the routers in the list. 3087 Similarly, in the absence of unspecified mechanisms for obtaining MAC 3088 addresses on foreign networks, the mobile node MUST ignore redirects 3089 to other routers on foreign networks. 3091 4.2.2. Foreign Agent Considerations 3093 Upon receipt of an encapsulated datagram sent to its advertised 3094 care-of address, a foreign agent MUST compare the inner destination 3095 address to those entries in its visitor list. When the destination 3096 does not match the address of any mobile node currently in the 3097 visitor list, the foreign agent MUST NOT forward the datagram without 3098 modifications to the original IP header, because otherwise a routing 3099 loop is likely to result. The datagram SHOULD be silently discarded. 3100 ICMP Destination Unreachable MUST NOT be sent when a foreign agent is 3101 unable to forward an incoming tunneled datagram. Otherwise, the 3102 foreign agent forwards the decapsulated datagram to the mobile node. 3104 The foreign agent MUST NOT advertise to other routers in its routing 3105 domain, nor to any other mobile node, the presence of a mobile router 3106 (Section 4.5) or mobile node in its visitor list. 3108 The foreign agent MUST route datagrams it receives from registered 3109 mobile nodes. At a minimum, this means that the foreign agent must 3110 verify the IP Header Checksum, decrement the IP Time To Live, 3111 recompute the IP Header Checksum, and forward such datagrams to a 3112 default router. 3114 A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC 3115 address on a foreign network. It may obtain the MAC address by 3116 copying the information from an Agent Solicitation or a Registration 3117 Request transmitted from a mobile node. A foreign agent's ARP cache 3118 for the mobile node's IP address MUST NOT be allowed to expire before 3119 the mobile node's visitor list entry expires, unless the foreign 3120 agent has some way other than broadcast ARP to refresh its MAC 3121 address associated with the mobile node's IP address. 3123 Each foreign agent SHOULD support the mandatory features for reverse 3124 tunneling [12]. 3126 4.2.3. Home Agent Considerations 3128 The home agent MUST be able to intercept any datagrams on the home 3129 network addressed to the mobile node while the mobile node is 3130 registered away from home. Proxy and gratuitous ARP MAY be used in 3131 enabling this interception, as specified in Section 4.6. 3133 The home agent must examine the IP Destination Address of all 3134 arriving datagrams to see if it is equal to the home address of any 3135 of its mobile nodes registered away from home. If so, the home agent 3136 tunnels the datagram to the mobile node's currently registered 3137 care-of address or addresses. If the home agent supports the 3138 optional capability of multiple simultaneous mobility bindings, it 3139 tunnels a copy to each care-of address in the mobile node's mobility 3140 binding list. If the mobile node has no current mobility bindings, 3141 the home agent MUST NOT attempt to intercept datagrams destined for 3142 the mobile node, and thus will not in general receive such datagrams. 3143 However, if the home agent is also a router handling common IP 3144 traffic, it is possible that it will receive such datagrams for 3145 forwarding onto the home network. In this case, the home agent MUST 3146 assume the mobile node is at home and simply forward the datagram 3147 directly onto the home network. 3149 For multihomed home agents, the source address in the outer IP header 3150 of the encapsulated datagram MUST be the address sent to the mobile 3151 node in the home agent field of the registration reply. That is, the 3152 home agent cannot use the the address of some other network interface 3153 as the source address. 3155 See Section 4.1 regarding methods of encapsulation that may be used 3156 for tunneling. Nodes implementing tunneling SHOULD also implement 3157 the "tunnel soft state" mechanism [15], which allows ICMP error 3158 messages returned from the tunnel to correctly be reflected back to 3159 the original senders of the tunneled datagrams. 3161 Home agents MUST decapsulate packets addressed to themselves, sent by 3162 a mobile node for the purpose of maintaining location privacy, as 3163 described in Section 5.5. This feature is also required for support 3164 of reverse tunneling [12]. 3166 If the Lifetime for a given mobility binding expires before the home 3167 agent has received another valid Registration Request for that mobile 3168 node, then that binding is deleted from the mobility binding list. 3169 The home agent MUST NOT send any Registration Reply message simply 3170 because the mobile node's binding has expired. The entry in the 3171 visitor list of the mobile node's current foreign agent will expire 3172 naturally, probably at the same time as the binding expired at the 3173 home agent. When a mobility binding's lifetime expires, the home 3174 agent MUST delete the binding, but it MUST retain any other (non- 3175 expired) simultaneous mobility bindings that it holds for the mobile 3176 node. 3178 When a home agent receives a datagram, intercepted for one of its 3179 mobile nodes registered away from home, the home agent MUST examine 3180 the datagram to check if it is already encapsulated. If so, special 3181 rules apply in the forwarding of that datagram to the mobile node: 3183 o If the inner (encapsulated) Destination Address is the same as the 3184 outer Destination Address (the mobile node), then the home agent 3185 MUST also examine the outer Source Address of the encapsulated 3186 datagram (the source address of the tunnel). If this outer Source 3187 Address is the same as the mobile node's current care-of address, 3188 the home agent MUST silently discard that datagram in order to 3189 prevent a likely routing loop. If, instead, the outer Source 3190 Address is NOT the same as the mobile node's current care-of 3191 address, then the home agent SHOULD forward the datagram to the 3192 mobile node. In order to forward the datagram in this case, the 3193 home agent MAY simply alter the outer Destination Address to the 3194 care-of address, rather than re-encapsulating the datagram. 3196 o Otherwise (the inner Destination Address is NOT the same as the 3197 outer Destination Address), the home agent SHOULD encapsulate the 3198 datagram again (nested encapsulation), with the new outer 3199 Destination Address set equal to the mobile node's care-of 3200 address. That is, the home agent forwards the entire datagram to 3201 the mobile node in the same way as any other datagram 3202 (encapsulated already or not). 3204 4.3. Broadcast Datagrams 3206 When a home agent receives a broadcast datagram, it MUST NOT forward 3207 the datagram to any mobile nodes in its mobility binding list other 3208 than those that have requested forwarding of broadcast datagrams. A 3209 mobile node MAY request forwarding of broadcast datagrams by setting 3210 the 'B' bit in its Registration Request message (Section 3.3). For 3211 each such registered mobile node, the home agent SHOULD forward 3212 received broadcast datagrams to the mobile node, although it is a 3213 matter of configuration at the home agent as to which specific 3214 categories of broadcast datagrams will be forwarded to such mobile 3215 nodes. 3217 If the 'D' bit was set in the mobile node's Registration Request 3218 message, indicating that the mobile node is using a co-located 3219 care-of address, the home agent simply tunnels appropriate broadcast 3220 IP datagrams to the mobile node's care-of address. Otherwise (the 3221 'D' bit was NOT set), the home agent first encapsulates the broadcast 3222 datagram in a unicast datagram addressed to the mobile node's home 3223 address, and then tunnels this encapsulated datagram to the foreign 3224 agent. This extra level of encapsulation is required so that the 3225 foreign agent can determine which mobile node should receive the 3226 datagram after it is decapsulated. When received by the foreign 3227 agent, the unicast encapsulated datagram is detunneled and delivered 3228 to the mobile node in the same way as any other datagram. In either 3229 case, the mobile node must decapsulate the datagram it receives in 3230 order to recover the original broadcast datagram. 3232 4.4. Multicast Datagram Routing 3234 As mentioned previously, a mobile node that is connected to its home 3235 network functions in the same way as any other (fixed) host or 3236 router. Thus, when it is at home, a mobile node functions 3237 identically to other multicast senders and receivers. This section 3238 therefore describes the behavior of a mobile node that is visiting a 3239 foreign network. 3241 In order to receive multicasts, a mobile node MUST join the multicast 3242 group in one of two ways. First, a mobile node MAY join the group 3243 via a (local) multicast router on the visited subnet. This option 3244 assumes that there is a multicast router present on the visited 3245 subnet. If the mobile node is using a co-located care-of address, it 3246 SHOULD use this address as the source IP address of its IGMP [6] 3247 messages. Otherwise, it MAY use its home address. 3249 Alternatively, a mobile node which wishes to receive multicasts MAY 3250 join groups via a bi-directional tunnel to its home agent, assuming 3251 that its home agent is a multicast router. The mobile node tunnels 3252 IGMP messages to its home agent and the home agent forwards multicast 3253 datagrams down the tunnel to the mobile node. For packets tunneled 3254 to the home agent, the source address in the IP header SHOULD be the 3255 mobile node's home address. 3257 The rules for multicast datagram delivery to mobile nodes in this 3258 case are identical to those for broadcast datagrams (Section 4.3). 3259 Namely, if the mobile node is using a co-located care-of address (the 3260 'D' bit was set in the mobile node's Registration Request), then the 3261 home agent SHOULD tunnel the datagram to this care-of address; 3262 otherwise, the home agent MUST first encapsulate the datagram in a 3263 unicast datagram addressed to the mobile node's home address and then 3264 MUST tunnel the resulting datagram (nested tunneling) to the mobile 3265 node's care-of address. For this reason, the mobile node MUST be 3266 capable of decapsulating packets sent to its home address in order to 3267 receive multicast datagrams using this method. 3269 A mobile node that wishes to send datagrams to a multicast group also 3270 has two options: (1) send directly on the visited network; or (2) 3271 send via a tunnel to its home agent. Because multicast routing in 3272 general depends upon the IP source address, a mobile node which sends 3273 multicast datagrams directly on the visited network MUST use a co- 3274 located care-of address as the IP source address. Similarly, a 3275 mobile node which tunnels a multicast datagram to its home agent MUST 3276 use its home address as the IP source address of both the (inner) 3277 multicast datagram and the (outer) encapsulating datagram. This 3278 second option assumes that the home agent is a multicast router. 3280 4.5. Mobile Routers 3282 A mobile node can be a router that is responsible for the mobility of 3283 one or more entire networks moving together, perhaps on an airplane, 3284 a ship, a train, an automobile, a bicycle, or a kayak. The nodes 3285 connected to a network served by the mobile router may themselves be 3286 fixed nodes or mobile nodes or routers. In this document, such 3287 networks are called "mobile networks". 3289 A mobile router MAY act as a foreign agent and provide a foreign 3290 agent care-of address to mobile nodes connected to the mobile 3291 network. Typical routing to a mobile node via a mobile router in 3292 this case is illustrated by the following example: 3294 a. A laptop computer is disconnected from its home network and later 3295 attached to a network port in the seat back of an aircraft. The 3296 laptop computer uses Mobile IP to register on this foreign 3297 network, using a foreign agent care-of address discovered through 3298 an Agent Advertisement from the aircraft's foreign agent. 3300 b. The aircraft network is itself mobile. Suppose the node serving 3301 as the foreign agent on the aircraft also serves as the default 3302 router that connects the aircraft network to the rest of the 3303 Internet. When the aircraft is at home, this router is attached 3304 to some fixed network at the airline's headquarters, which is the 3305 router's home network. While the aircraft is in flight, this 3306 router registers from time to time over its radio link with a 3307 series of foreign agents below it on the ground. This router's 3308 home agent is a node on the fixed network at the airline's 3309 headquarters. 3311 c. Some correspondent node sends a datagram to the laptop computer, 3312 addressing the datagram to the laptop's home address. This 3313 datagram is initially routed to the laptop's home network. 3315 d. The laptop's home agent intercepts the datagram on the home 3316 network and tunnels it to the laptop's care-of address, which in 3317 this example is an address of the node serving as router and 3318 foreign agent on the aircraft. Normal IP routing will route the 3319 datagram to the fixed network at the airline's headquarters. 3321 e. The aircraft router and foreign agent's home agent there 3322 intercepts the datagram and tunnels it to its current care-of 3323 address, which in this example is some foreign agent on the 3324 ground below the aircraft. The original datagram from the 3325 correspondent node has now been encapsulated twice: once by the 3326 laptop's home agent and again by the aircraft's home agent. 3328 f. The foreign agent on the ground decapsulates the datagram, 3329 yielding a datagram still encapsulated by the laptop's home 3330 agent, with a destination address of the laptop's care-of 3331 address. The ground foreign agent sends the resulting datagram 3332 over its radio link to the aircraft. 3334 g. The foreign agent on the aircraft decapsulates the datagram, 3335 yielding the original datagram from the correspondent node, with 3336 a destination address of the laptop's home address. The aircraft 3337 foreign agent delivers the datagram over the aircraft network to 3338 the laptop's link-layer address. 3340 This example illustrated the case in which a mobile node is attached 3341 to a mobile network. That is, the mobile node is mobile with respect 3342 to the network, which itself is also mobile (here with respect to the 3343 ground). If, instead, the node is fixed with respect to the mobile 3344 network (the mobile network is the fixed node's home network), then 3345 either of two methods may be used to cause datagrams from 3346 correspondent nodes to be routed to the fixed node. 3348 A home agent MAY be configured to have a permanent registration for 3349 the fixed node, that indicates the mobile router's address as the 3350 fixed host's care-of address. The mobile router's home agent will 3351 usually be used for this purpose. The home agent is then responsible 3352 for advertising connectivity using normal routing protocols to the 3353 fixed node. Any datagrams sent to the fixed node will thus use 3354 nested tunneling as described above. 3356 Alternatively, the mobile router MAY advertise connectivity to the 3357 entire mobile network using normal IP routing protocols through a bi- 3358 directional tunnel to its own home agent. This method avoids the 3359 need for nested tunneling of datagrams. 3361 4.6. ARP, Proxy ARP, and Gratuitous ARP 3363 The use of ARP [17] requires special rules for correct operation when 3364 wireless or mobile nodes are involved. The requirements specified in 3365 this section apply to all home networks in which ARP is used for 3366 address resolution. 3368 In addition to the normal use of ARP for resolving a target node's 3369 link-layer address from its IP address, this document distinguishes 3370 two special uses of ARP: 3372 o A Proxy ARP [20] is an ARP Reply sent by one node on behalf of 3373 another node which is either unable or unwilling to answer its own 3374 ARP Requests. The sender of a Proxy ARP reverses the Sender and 3375 Target Protocol Address fields as described in [17], but supplies 3376 some configured link-layer address (generally, its own) in the 3377 Sender Hardware Address field. The node receiving the Reply will 3378 then associate this link-layer address with the IP address of the 3379 original target node, causing it to transmit future datagrams for 3380 this target node to the node with that link-layer address. 3382 o A Gratuitous ARP [44] is an ARP packet sent by a node in order to 3383 spontaneously cause other nodes to update an entry in their ARP 3384 cache. A gratuitous ARP MAY use either an ARP Request or an ARP 3385 Reply packet. In either case, the ARP Sender Protocol Address and 3386 ARP Target Protocol Address are both set to the IP address of the 3387 cache entry to be updated, and the ARP Sender Hardware Address is 3388 set to the link-layer address to which this cache entry should be 3389 updated. When using an ARP Reply packet, the Target Hardware 3390 Address is also set to the link-layer address to which this cache 3391 entry should be updated (this field is not used in an ARP Request 3392 packet). 3394 In either case, for a gratuitous ARP, the ARP packet MUST be 3395 transmitted as a local broadcast packet on the local link. As 3396 specified in [17], any node receiving any ARP packet (Request or 3397 Reply) MUST update its local ARP cache with the Sender Protocol 3398 and Hardware Addresses in the ARP packet, if the receiving node 3399 has an entry for that IP address already in its ARP cache. This 3400 requirement in the ARP protocol applies even for ARP Request 3401 packets, and for ARP Reply packets that do not match any ARP 3402 Request transmitted by the receiving node [17]. 3404 While a mobile node is registered on a foreign network, its home 3405 agent uses proxy ARP [20] to reply to ARP Requests it receives that 3406 seek the mobile node's link-layer address. When receiving an ARP 3407 Request, the home agent MUST examine the target IP address of the 3408 Request, and if this IP address matches the home address of any 3409 mobile node for which it has a registered mobility binding, the home 3410 agent MUST transmit an ARP Reply on behalf of the mobile node. After 3411 exchanging the sender and target addresses in the packet [20], the 3412 home agent MUST set the sender link-layer address in the packet to 3413 the link-layer address of its own interface over which the Reply will 3414 be sent. 3416 When a mobile node leaves its home network and registers a binding on 3417 a foreign network, its home agent uses gratuitous ARP to update the 3418 ARP caches of nodes on the home network. This causes such nodes to 3419 associate the link-layer address of the home agent with the mobile 3420 node's home (IP) address. When registering a binding for a mobile 3421 node for which the home agent previously had no binding (the mobile 3422 node was assumed to be at home), the home agent MUST transmit a 3423 gratuitous ARP on behalf of the mobile node. This gratuitous ARP 3424 packet MUST be transmitted as a broadcast packet on the link on which 3425 the mobile node's home address is located. Since broadcasts on the 3426 local link (such as Ethernet) are typically not guaranteed to be 3427 reliable, the gratuitous ARP packet SHOULD be retransmitted a small 3428 number of times to increase its reliability. 3430 When a mobile node returns to its home network, the mobile node and 3431 its home agent use gratuitous ARP to cause all nodes on the mobile 3432 node's home network to update their ARP caches to once again 3433 associate the mobile node's own link-layer address with the mobile 3434 node's home (IP) address. Before transmitting the (de)Registration 3435 Request message to its home agent, the mobile node MUST transmit this 3436 gratuitous ARP on its home network as a local broadcast on this link. 3437 The gratuitous ARP packet SHOULD be retransmitted a small number of 3438 times to increase its reliability, but these retransmissions SHOULD 3439 proceed in parallel with the transmission and processing of its 3440 (de)Registration Request. 3442 When the mobile node's home agent receives and accepts this 3443 (de)Registration Request, the home agent MUST also transmit a 3444 gratuitous ARP on the mobile node's home network. This gratuitous 3445 ARP also is used to associate the mobile node's home address with the 3446 mobile node's own link-layer address. A gratuitous ARP is 3447 transmitted by both the mobile node and its home agent, since in the 3448 case of wireless network interfaces, the area within transmission 3449 range of the mobile node will likely differ from that within range of 3450 its home agent. The ARP packet from the home agent MUST be 3451 transmitted as a local broadcast on the mobile node's home link, and 3452 SHOULD be retransmitted a small number of times to increase its 3453 reliability; these retransmissions, however, SHOULD proceed in 3454 parallel with the transmission and processing of its (de)Registration 3455 Reply. 3457 While the mobile node is away from home, it MUST NOT transmit any 3458 broadcast ARP Request or ARP Reply messages. Finally, while the 3459 mobile node is away from home, it MUST NOT reply to ARP Requests in 3460 which the target IP address is its own home address unless the ARP 3461 Request is unicast by a foreign agent with which the mobile node is 3462 attempting to register or a foreign agent with which the mobile node 3463 has an unexpired registration. In the latter case, the mobile node 3464 MUST use a unicast ARP Reply to respond to the foreign agent. Note 3465 that if the mobile node is using a co-located care-of address and 3466 receives an ARP Request in which the target IP address is this 3467 care-of address, then the mobile node SHOULD reply to this ARP 3468 Request. Note also that, when transmitting a Registration Request on 3469 a foreign network, a mobile node may discover the link-layer address 3470 of a foreign agent by storing the address as it is received from the 3471 Agent Advertisement from that foreign agent, but not by transmitting 3472 a broadcast ARP Request message. 3474 The specific order in which each of the above requirements for the 3475 use of ARP, proxy ARP, and gratuitous ARP are applied, relative to 3476 the transmission and processing of the mobile node's Registration 3477 Request and Registration Reply messages when leaving home or 3478 returning home, are important to the correct operation of the 3479 protocol. 3481 To summarize the above requirements, when a mobile node leaves its 3482 home network, the following steps, in this order, MUST be performed: 3484 o The mobile node decides to register away from home, perhaps 3485 because it has received an Agent Advertisement from a foreign 3486 agent and has not recently received one from its home agent. 3488 o Before transmitting the Registration Request, the mobile node 3489 disables its own future processing of any ARP Requests it may 3490 subsequently receive requesting the link-layer address 3491 corresponding to its home address, except insofar as necessary to 3492 communicate with foreign agents on visited networks. 3494 o The mobile node transmits its Registration Request. 3496 o When the mobile node's home agent receives and accepts the 3497 Registration Request, it performs a gratuitous ARP on behalf of 3498 the mobile node, and begins using proxy ARP to reply to ARP 3499 Requests that it receives requesting the mobile node's link-layer 3500 address. In the gratuitous ARP, the ARP Sender Hardware Address 3501 is set to the link-layer address of the home agent. If, instead, 3502 the home agent rejects the Registration Request, no ARP processing 3503 (gratuitous nor proxy) is performed by the home agent. 3505 When a mobile node later returns to its home network, the following 3506 steps, in this order, MUST be performed: 3508 o The mobile node decides to register at home, perhaps because it 3509 has received an Agent Advertisement from its home agent. 3511 o Before transmitting the Registration Request, the mobile node re- 3512 enables its own future processing of any ARP Requests it may 3513 subsequently receive requesting its link-layer address. 3515 o The mobile node performs a gratuitous ARP for itself. In this 3516 gratuitous ARP, the ARP Sender Hardware Address is set to the 3517 link-layer address of the mobile node. 3519 o The mobile node transmits its Registration Request. 3521 o When the mobile node's home agent receives and accepts the 3522 Registration Request, it stops using proxy ARP to reply to ARP 3523 Requests that it receives requesting the mobile node's link-layer 3524 address, and then performs a gratuitous ARP on behalf of the 3525 mobile node. In this gratuitous ARP, the ARP Sender Hardware 3526 Address is set to the link-layer address of the mobile node. If, 3527 instead, the home agent rejects the Registration Request, the home 3528 agent MUST NOT make any change to the way it performs ARP 3529 processing (gratuitous nor proxy) for the mobile node. In this 3530 latter case, the home agent should operate as if the mobile node 3531 has not returned home, and continue to perform proxy ARP on behalf 3532 of the mobile node. 3534 5. Security Considerations 3536 The mobile computing environment is potentially very different from 3537 the ordinary computing environment. In many cases, mobile computers 3538 will be connected to the network via wireless links. Such links are 3539 particularly vulnerable to passive eavesdropping, active replay 3540 attacks, and other active attacks. 3542 5.1. Message Authentication Codes 3544 Home agents and mobile nodes MUST be able to perform authentication. 3545 The default algorithm is HMAC-MD5 [10], with a key size of 128 bits. 3546 The foreign agent MUST also support authentication using HMAC-MD5 and 3547 key sizes of 128 bits or greater, with manual key distribution. Keys 3548 with arbitrary binary values MUST be supported. 3550 The "prefix+suffix" use of MD5 to protect data and a shared secret is 3551 considered vulnerable to attack by the cryptographic community. 3552 Where backward compatibility with existing Mobile IP implementations 3553 that use this mode is needed, new implementations SHOULD include 3554 keyed MD5 [22] as one of the additional authentication algorithms for 3555 use when producing and verifying the authentication data that is 3556 supplied with Mobile IP registration messages, for instance in the 3557 extensions specified in Section 3.5.2, Section 3.5.3, and 3558 Section 3.5.4. 3560 More authentication algorithms, algorithm modes, key distribution 3561 methods, and key sizes MAY also be supported for all of these 3562 extensions. 3564 5.2. Areas of Security Concern in this Protocol 3566 The registration protocol described in this document will result in a 3567 mobile node's traffic being tunneled to its care-of address. This 3568 tunneling feature could be a significant vulnerability if the 3569 registration were not authenticated. Such remote redirection, for 3570 instance as performed by the mobile registration protocol, is widely 3571 understood to be a security problem in the current Internet if not 3572 authenticated [28]. Moreover, the Address Resolution Protocol (ARP) 3573 is not authenticated, and can potentially be used to steal another 3574 host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings 3575 with it all of the risks associated with the use of ARP. 3577 5.3. Key Management 3579 This specification requires a strong authentication mechanism (keyed 3580 MD5) which precludes many potential attacks based on the Mobile IP 3581 registration protocol. However, because key distribution is 3582 difficult in the absence of a network key management protocol, 3583 messages with the foreign agent are not all required to be 3584 authenticated. In a commercial environment it might be important to 3585 authenticate all messages between the foreign agent and the home 3586 agent, so that billing is possible, and service providers do not 3587 provide service to users that are not legitimate customers of that 3588 service provider. 3590 5.4. Picking Good Random Numbers 3592 The strength of any authentication mechanism depends on several 3593 factors, including the innate strength of the authentication 3594 algorithm, the secrecy of the key used, the strength of the key used, 3595 and the quality of the particular implementation. This specification 3596 requires implementation of keyed MD5 for authentication, but does not 3597 preclude the use of other authentication algorithms and modes. For 3598 keyed MD5 authentication to be useful, the 128-bit key must be both 3599 secret (that is, known only to authorized parties) and pseudo-random. 3600 If nonces are used in connection with replay protection, they must 3601 also be selected carefully. Eastlake, et al. [8] provides more 3602 information on generating pseudo-random numbers. 3604 5.5. Privacy 3606 Users who have sensitive data that they do not wish others to see 3607 should use mechanisms outside the scope of this document (such as 3608 encryption) to provide appropriate protection. Users concerned about 3609 traffic analysis should consider appropriate use of link encryption. 3610 If absolute location privacy is desired, the mobile node can create a 3611 tunnel to its home agent. Then, datagrams destined for correspondent 3612 nodes will appear to emanate from the home network, and it may be 3613 more difficult to pinpoint the location of the mobile node. Such 3614 mechanisms are all beyond the scope of this document. 3616 5.6. Ingress Filtering 3618 Many routers implement security policies such as "ingress filtering" 3619 [33] that do not allow forwarding of packets that have a Source 3620 Address which appears topologically incorrect. In environments where 3621 this is a problem, mobile nodes may use reverse tunneling [12] with 3622 the foreign agent supplied care-of address as the Source Address. 3623 Reverse tunneled packets will be able to pass normally through such 3624 routers, while ingress filtering rules will still be able to locate 3625 the true topological source of the packet in the same way as packets 3626 from non-mobile nodes. 3628 5.7. Replay Protection for Registration Requests 3630 The Identification field is used to let the home agent verify that a 3631 registration message has been freshly generated by the mobile node, 3632 not replayed by an attacker from some previous registration. Two 3633 methods are described in this section: timestamps (mandatory) and 3634 "nonces" (optional). All mobile nodes and home agents MUST implement 3635 timestamp-based replay protection. These nodes MAY also implement 3636 nonce-based replay protection (but see Appendix A). 3638 The style of replay protection in effect between a mobile node and 3639 its home agent is part of the mobile security association. A mobile 3640 node and its home agent MUST agree on which method of replay 3641 protection will be used. The interpretation of the Identification 3642 field depends on the method of replay protection as described in the 3643 subsequent subsections. 3645 Whatever method is used, the low-order 32 bits of the Identification 3646 MUST be copied unchanged from the Registration Request to the Reply. 3647 The foreign agent uses those bits (and the mobile node's home 3648 address) to match Registration Requests with corresponding replies. 3649 The mobile node MUST verify that the low-order 32 bits of any 3650 Registration Reply are identical to the bits it sent in the 3651 Registration Request. 3653 The Identification in a new Registration Request MUST NOT be the same 3654 as in an immediately preceding Request, and SHOULD NOT repeat while 3655 the same security context is being used between the mobile node and 3656 the home agent. Retransmission as in Section 3.6.3 is allowed. 3658 5.7.1. Replay Protection using Timestamps 3660 The basic principle of timestamp replay protection is that the node 3661 generating a message inserts the current time of day, and the node 3662 receiving the message checks that this timestamp is sufficiently 3663 close to its own time of day. Unless specified differently in the 3664 security association between the nodes, a default value of 7 seconds 3665 MAY be used to limit the time difference. This value SHOULD be 3666 greater than 3 seconds. Obviously the two nodes must have adequately 3667 synchronized time-of-day clocks. As with any messages, time 3668 synchronization messages may be protected against tampering by an 3669 authentication mechanism determined by the security context between 3670 the two nodes. 3672 If timestamps are used, the mobile node MUST set the Identification 3673 field to a 64-bit value formatted as specified by the Network Time 3674 Protocol [11]. The low-order 32 bits of the NTP format represent 3675 fractional seconds, and those bits which are not available from a 3676 time source SHOULD be generated from a good source of randomness. 3677 Note, however, that when using timestamps, the 64-bit Identification 3678 used in a Registration Request from the mobile node MUST be greater 3679 than that used in any previous Registration Request, as the home 3680 agent uses this field also as a sequence number. Without such a 3681 sequence number, it would be possible for a delayed duplicate of an 3682 earlier Registration Request to arrive at the home agent (within the 3683 clock synchronization required by the home agent), and thus be 3684 applied out of order, mistakenly altering the mobile node's current 3685 registered care-of address. 3687 Upon receipt of a Registration Request with an authorization-enabling 3688 extension, the home agent MUST check the Identification field for 3689 validity. In order to be valid, the timestamp contained in the 3690 Identification field MUST be close enough to the home agent's time of 3691 day clock and the timestamp MUST be greater than all previously 3692 accepted timestamps for the requesting mobile node. Time tolerances 3693 and resynchronization details are specific to a particular mobility 3694 security association. 3696 If the timestamp is valid, the home agent copies the entire 3697 Identification field into the Registration Reply it returns the Reply 3698 to the mobile node. If the timestamp is not valid, the home agent 3699 copies only the low-order 32 bits into the Registration Reply, and 3700 supplies the high-order 32 bits from its own time of day. In this 3701 latter case, the home agent MUST reject the registration by returning 3702 Code 133 (identification mismatch) in the Registration Reply. 3704 As described in Section 3.6.2.1, the mobile node MUST verify that the 3705 low-order 32 bits of the Identification in the Registration Reply are 3706 identical to those in the rejected registration attempt, before using 3707 the high-order bits for clock resynchronization. 3709 5.7.2. Replay Protection using Nonces 3711 The basic principle of nonce replay protection is that node A 3712 includes a new random number in every message to node B, and checks 3713 that node B returns that same number in its next message to node A. 3714 Both messages use an authentication code to protect against 3715 alteration by an attacker. At the same time node B can send its own 3716 nonces in all messages to node A (to be echoed by node A), so that it 3717 too can verify that it is receiving fresh messages. 3719 The home agent may be expected to have resources for computing 3720 pseudo-random numbers useful as nonces [8]. It inserts a new nonce 3721 as the high-order 32 bits of the identification field of every 3722 Registration Reply. The home agent copies the low-order 32 bits of 3723 the Identification from the Registration Request message into the 3724 low-order 32 bits of the Identification in the Registration Reply. 3725 When the mobile node receives an authenticated Registration Reply 3726 from the home agent, it saves the high-order 32 bits of the 3727 identification for use as the high-order 32 bits of its next 3728 Registration Request. 3730 The mobile node is responsible for generating the low-order 32 bits 3731 of the Identification in each Registration Request. Ideally it 3732 should generate its own random nonces. However it may use any 3733 expedient method, including duplication of the random value sent by 3734 the home agent. The method chosen is of concern only to the mobile 3735 node, because it is the node that checks for valid values in the 3736 Registration Reply. The high-order and low-order 32 bits of the 3737 identification chosen SHOULD both differ from their previous values. 3738 The home agent uses a new high-order value and the mobile node uses a 3739 new low-order value for each registration message. The foreign agent 3740 uses the low-order value (and the mobile host's home address) to 3741 correctly match registration replies with pending Requests 3742 (Section 3.7.1). 3744 If a registration message is rejected because of an invalid nonce, 3745 the Reply always provides the mobile node with a new nonce to be used 3746 in the next registration. Thus the nonce protocol is self- 3747 synchronizing. 3749 6. IANA Considerations 3751 Mobile IP specifies several new number spaces for values to be used 3752 in various message fields. These number spaces include the 3753 following: 3755 o Mobile IP message types sent to UDP port 434, as defined in 3756 Section 1.8. 3758 o types of extensions to Registration Request and Registration Reply 3759 messages (see Section 3.3 and Section 3.4, and also consult 3760 ([12],[41],[2],[3],[7]). 3762 o values for the Code in the Registration Reply message (see 3763 Section 3.4, and also consult ([12],[41],[2],[3],[7]). 3765 o Mobile IP defines so-called Agent Solicitation and Agent 3766 Advertisement messages. These messages are in fact Router 3767 Discovery messages [5] augmented with mobile-IP specific 3768 extensions. Thus, they do not define a new name space, but do 3769 define additional Router Discovery extensions as described below 3770 in Section 6.2. Also see Section 2.1 and consult ([3], [7]). 3772 There are additional Mobile IP numbering spaces specified in [3]. 3774 Information about assignment of mobile-ip numbers derived from 3775 specifications external to this document is given by IANA at 3776 http://www.iana.org/numbers.html. From that URL, follow the 3777 hyperlinks to [M] within the "Directory of General Assigned Numbers", 3778 and subsequently to the specific section for "Mobile IP Numbers". 3780 In this revised specification, a new Code value (for the field in the 3781 Registration Reply message) is needed within the range typically used 3782 for Foreign Agent messages. This error code is needed to indicate 3783 the status "Invalid Home Agent Address". See Section 3.7.2 for 3784 details. 3786 6.1. Mobile IP Message Types 3788 Mobile IP messages are defined to be those that are sent to a message 3789 recipient at port 434 (UDP or TCP). The number space for Mobile IP 3790 messages is specified in Section 1.8. Approval of new extension 3791 numbers is subject to Expert Review, and a specification is required 3792 [14]. The currently standardized message types have the following 3793 numbers, and are specified in the indicated sections. 3795 Type Name Section 3796 ---- -------------------------------------------- --------- 3797 1 Registration Request 3.3 3798 3 Registration Reply 3.4 3800 6.2. Extensions to RFC 1256 Router Advertisement 3802 RFC 1256 defines two ICMP message types, Router Advertisement and 3803 Router Solicitation. Mobile IP defines a number space for extensions 3804 to Router Advertisement, which could be used by protocols other than 3805 Mobile IP. The extension types currently standardized for use with 3806 Mobile IP have the following numbers. 3808 Type Name Reference 3809 ---- -------------------------------------------- --------- 3810 0 One-byte Padding 2.1.3 3811 16 Mobility Agent Advertisement 2.1.1 3812 19 Prefix-Lengths 2.1.2 3814 Approval of new extension numbers for use with Mobile IP is subject 3815 to Expert Review, and a specification is required [14]. 3817 6.3. Extensions to Mobile IP Registration Messages 3819 The Mobile IP messages, specified within this document, and listed in 3820 Section 1.8 and Section 6.1, may have extensions. Mobile IP message 3821 extensions all share the same number space, even if they are to be 3822 applied to different Mobile IP messages. The number space for Mobile 3823 IP message extensions is specified within this document. Approval of 3824 new extension numbers is subject to Expert Review, and a 3825 specification is required [14]. 3827 Type Name Reference 3828 ---- -------------------------------------------- --------- 3829 0 One-byte Padding 3830 32 Mobile-Home Authentication 3.5.2 3831 33 Mobile-Foreign Authentication 3.5.3 3832 34 Foreign-Home Authentication 3.5.4 3834 6.4. Code Values for Mobile IP Registration Reply Messages 3836 The Mobile IP Registration Reply message, specified in Section 3.4, 3837 has a Code field. The number space for the Code field values is also 3838 specified in Section 3.4. The Code number space is structured 3839 according to whether the registration was successful, or whether the 3840 foreign agent denied the registration request, or lastly whether the 3841 home agent denied the registration request, as follows: 3843 0-8 Success Codes 3844 9-63 No allocation guidelines currently exist 3845 64-127 Error Codes from the Foreign Agent 3846 128-192 Error Codes from the Home Agent 3847 193-255 No allocation guidelines currently exist 3849 Approval of new Code values requires Expert Review [14]. 3851 7. Acknowledgments 3853 Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp 3854 and John Ioannidis (JI) (Columbia University), for forming the 3855 working group, chairing it, and putting so much effort into its early 3856 development. Columbia's early Mobile IP work can be found in 3857 [35],[36],[37]. 3859 Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, 3860 Erik Nordmark, Basavaraj Patil, and Phil Roberts for their 3861 contributions to the group while performing the duties of 3862 chairperson, as well as for their many useful comments. 3864 Thanks to the active members of the Mobile IP Working Group, 3865 particularly those who contributed text, including (in alphabetical 3866 order) 3868 Ran Atkinson (Naval Research Lab), 3869 Samita Chakrabarti (Sun Microsystems) 3870 Ken Imboden (Candlestick Networks, Inc.) 3871 Dave Johnson (Carnegie Mellon University), 3872 Frank Kastenholz (FTP Software), 3873 Anders Klemets (KTH), 3874 Chip Maguire (KTH), 3875 Alison Mankin (ISI) 3876 Andrew Myles (Macquarie University), 3877 Thomas Narten (IBM), 3878 Al Quirt (Bell Northern Research), 3879 Yakov Rekhter (IBM), 3880 Fumio Teraoka (Sony), and 3881 Alper Yegin (NTT DoCoMo) 3883 Thanks to Charlie Kunzinger and to Bill Simpson, the editors who 3884 produced the first drafts for of this document, reflecting the 3885 discussions of the Working Group. Much of the new text in the later 3886 revisions preceding RFC 2002 is due to Jim Solomon and Dave Johnson. 3888 Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank 3889 Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for 3890 their generous support in hosting interim Working Group meetings. 3892 Section 1.10 and Section 1.11, which specify new extension formats to 3893 be used with aggregatable extension types, were included from a 3894 specification document (entitled "Mobile IP Extensions 3895 Rationalization (MIER)", which was written by 3896 Mohamed M.Khalil, Nortel Networks 3897 Raja Narayanan, nVisible Networks 3898 Haseeb Akhtar, Nortel Networks 3899 Emad Qaddoura, Nortel Networks 3901 Thanks to these authors, and also for the additional work on MIER, 3902 which was contributed by Basavaraj Patil, Pat Calhoun, Neil 3903 Justusson, N. Asokan, and Jouni Malinen. 3905 Thanks to Vijay Devarapalli, who put in many hours to convert the 3906 source for this text document into XML format. 3908 8. References 3910 8.1. Normative References 3912 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3913 Levels", BCP 14, RFC 2119, March 1997. 3915 [2] Calhoun, P. and C. Perkins, "Mobile IP Network Access 3916 Identifier Extension for IPv4", RFC 2794, March 2000. 3918 [3] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 3919 Challenge/Response Extensions (Revised)", RFC 4721, 3920 January 2007. 3922 [4] Cong, D., Hamlen, M., and C. Perkins, "The Definitions of 3923 Managed Objects for IP Mobility Support using SMIv2", RFC 2006, 3924 October 1996. 3926 [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 3927 September 1991. 3929 [6] Deering, S., "Host extensions for IP multicasting", STD 5, 3930 RFC 1112, August 1989. 3932 [7] Dommety, G. and K. Leung, "Mobile IP Vendor/ 3933 Organization-Specific Extensions", RFC 3115, April 2001. 3935 [8] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3936 Requirements for Security", BCP 106, RFC 4086, June 2005. 3938 [9] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 3940 [10] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 3941 for Message Authentication", RFC 2104, February 1997. 3943 [11] Mills, D., "Network Time Protocol (Version 3) Specification, 3944 Implementation", RFC 1305, March 1992. 3946 [12] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", 3947 RFC 3024, January 2001. 3949 [13] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 3950 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 3952 [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3953 Considerations Section in RFCs", BCP 26, RFC 2434, 3954 October 1998. 3956 [15] Perkins, C., "IP Encapsulation within IP", RFC 2003, 3957 October 1996. 3959 [16] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 3960 October 1996. 3962 [17] Plummer, D., "Ethernet Address Resolution Protocol: Or 3963 converting network protocol addresses to 48.bit Ethernet 3964 address for transmission on Ethernet hardware", STD 37, 3965 RFC 826, November 1982. 3967 [18] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3968 August 1980. 3970 [19] Postel, J., "Internet Protocol", STD 5, RFC 791, 3971 September 1981. 3973 [20] Postel, J., "Multi-LAN address resolution", RFC 925, 3974 October 1984. 3976 [21] IANA Assigned Numbers Online Database, "Mobile IPv4 Numbers", 3977 http://www.iana.org/assignments/mobileip-numbers . 3979 [22] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3980 April 1992. 3982 [23] Solomon, J., "Applicability Statement for IP Mobility Support", 3983 RFC 2005, October 1996. 3985 8.2. Informative References 3987 [24] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for 3988 PPP IPCP", RFC 2290, February 1998. 3990 [25] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. 3991 Vaidya, "Long Thin Networks", RFC 2757, January 2000. 3993 [26] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over 3994 Satellite Channels using Standard Mechanisms", BCP 28, 3995 RFC 2488, January 1999. 3997 [27] Paxson, V. and M. Allman, "Computing TCP's Retransmission 3998 Timer", RFC 2988, November 2000. 4000 [28] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", 4001 ACM Computer Communications Review, 19(2), March 1989. 4003 [29] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 4005 Shelby, "Performance Enhancing Proxies Intended to Mitigate 4006 Link-Related Degradations", RFC 3135, June 2001. 4008 [30] Caceres, R. and L. Iftode, "Improving the Performance of 4009 Reliable Transport Protocols in Mobile Computing Environments", 4010 IEEE Journal on Selected Areas in Communication, 13(5):850-- 4011 857, June 1995. 4013 [31] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. 4014 Vaidya, "End-to-end Performance Implications of Links with 4015 Errors", BCP 50, RFC 3155, August 2001. 4017 [32] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 4018 March 1997. 4020 [33] Ferguson, P. and D. Senie, "Network Ingress Filtering: 4021 Defeating Denial of Service Attacks which employ IP Source 4022 Address Spoofing", BCP 38, RFC 2827, May 2000. 4024 [34] Jacobson, V., "Compressing TCP/IP headers for low-speed serial 4025 links", RFC 1144, February 1990. 4027 [35] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-Based Protocols 4028 for Mobile Interworking", In Proceedings of the SIGCOMM '01 4029 Conference: Communications Architectures and Protocols, Pages 4030 235--245, September 1991. 4032 [36] Ioannidis, J. and G. Maguire, "The Design and Implementation of 4033 a Mobile Internetworking Architecture", In Proceedings of the 4034 Winter USENIX Technical Conference, Pages 489--500, 4035 January 1993. 4037 [37] Ioannidis, J., "Protocols for Mobile Interworking", PhD 4038 Dissertation - Columbia University in the City of New York , 4039 July 1993. 4041 [38] Jacobson, V., "Congestion Avoidance and Control", In 4042 Proceedings of the SIGCOMM '88 Workshop, ACM SIGCOMM, ACM 4043 Press, Pages 314--329, August 1998. 4045 [39] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces 4046 Group of MIB-II", RFC 1573, January 1994. 4048 [40] McGregor, G., "The PPP Internet Protocol Control Protocol 4049 (IPCP)", RFC 1332, May 1992. 4051 [41] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for 4052 Mobile IP", RFC 2356, June 1998. 4054 [42] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 4056 [43] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 4057 August 2002. 4059 [44] Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols", 4060 Addison-Wesley, Reading, Massachussets, 1994. 4062 [45] Perkins, C. and P. Calhoun, "Authentication, Authorization, and 4063 Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, 4064 March 2005. 4066 [46] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 4067 RFC 1661, July 1994. 4069 Appendix A. Patent Issues 4071 The IETF has been notified of intellectual property rights claimed in 4072 regard to some or all of the specification contained in this 4073 document. For more information consult the online list of claimed 4074 rights. 4076 Appendix B. Link-Layer Considerations 4078 The mobile node MAY use link-layer mechanisms to decide that its 4079 point of attachment has changed. Such indications include the Down/ 4080 Testing/Up interface status [39], and changes in cell or 4081 administration. The mechanisms will be specific to the particular 4082 link-layer technology, and are outside the scope of this document. 4084 The Point-to-Point-Protocol (PPP) [46] and its Internet Protocol 4085 Control Protocol (IPCP) [40], negotiates the use of IP addresses. 4087 The mobile node SHOULD first attempt to specify its home address, so 4088 that if the mobile node is attaching to its home network, the 4089 unrouted link will function correctly. When the home address is not 4090 accepted by the peer, but a transient IP address is dynamically 4091 assigned to the mobile node, and the mobile node is capable of 4092 supporting a co-located care-of address, the mobile node MAY register 4093 that address as a co-located care-of address. When the peer 4094 specifies its own IP address, that address MUST NOT be assumed to be 4095 a foreign agent care-of address or the IP address of a home agent. 4096 PPP extensions for Mobile IP have been specified in RFC 2290 [24]. 4097 Please consult that document for additional details for how to handle 4098 care-of address assignment from PPP in a more efficient manner. 4100 Appendix C. TCP Considerations 4102 C.1. TCP Timers 4104 When high-delay (e.g. SATCOM) or low-bandwidth (e.g. High-Frequency 4105 Radio) links are in use, some TCP stacks may have insufficiently 4106 adaptive (non-standard) retransmission timeouts. There may be 4107 spurious retransmission timeouts, even when the link and network are 4108 actually operating properly, but just with a high delay because of 4109 the medium in use. This can cause an inability to create or maintain 4110 TCP connections over such links, and can also cause unneeded 4111 retransmissions which consume already scarce bandwidth. Vendors are 4112 encouraged to follow the algorithms in RFC 2988 [27] when 4113 implementing TCP retransmission timers. Vendors of systems designed 4114 for low-bandwidth, high-delay links should consult RFCs 2757 and 2488 4115 [25], [26]. Designers of applications targeted to operate on mobile 4116 nodes should be sensitive to the possibility of timer-related 4117 difficulties. 4119 C.2. TCP Congestion Management 4121 Mobile nodes often use media which are more likely to introduce 4122 errors, effectively causing more packets to be dropped. This 4123 introduces a conflict with the mechanisms for congestion management 4124 found in modern versions of TCP [38]. Now, when a packet is dropped, 4125 the correspondent node's TCP implementation is likely to react as if 4126 there were a source of network congestion, and initiate the slow- 4127 start mechanisms [38] designed for controlling that problem. 4128 However, those mechanisms are inappropriate for overcoming errors 4129 introduced by the links themselves, and have the effect of magnifying 4130 the discontinuity introduced by the dropped packet. This problem has 4131 been analyzed by Caceres, et al. [30]. TCP approaches to the problem 4132 of handling errors that might interfere with congestion management 4133 are discussed in documents from the [pilc] working group [29] [31]. 4134 While such approaches are beyond the scope of this document, they 4135 illustrate that providing performance transparency to mobile nodes 4136 involves understanding mechanisms outside the network layer. 4137 Problems introduced by higher media error rates also indicate the 4138 need to avoid designs which systematically drop packets; such designs 4139 might otherwise be considered favorably when making engineering 4140 tradeoffs. 4142 Appendix D. Example Scenarios 4144 This section shows example Registration Requests for several common 4145 scenarios. 4147 D.1. Registering with a Foreign Agent Care-of Address 4149 The mobile node receives an Agent Advertisement from a foreign agent 4150 and wishes to register with that agent using the advertised foreign 4151 agent care-of address. The mobile node wishes only IP-in-IP 4152 encapsulation, does not want broadcasts, and does not want 4153 simultaneous mobility bindings: 4155 IP fields: 4156 Source Address = mobile node's home address 4157 Destination Address = copied from the IP source address of the 4158 Agent Advertisement 4159 Time to Live = 1 4160 UDP fields: 4161 Source Port = 4162 Destination Port = 434 4163 Registration Request fields: 4164 Type = 1 4165 S=0,B=0,D=0,M=0,G=0 4166 Lifetime = the Registration Lifetime copied from the 4167 Mobility Agent Advertisement Extension of the 4168 Router Advertisement message 4169 Home Address = the mobile node's home address 4170 Home Agent = IP address of mobile node's home agent 4171 Care-of Address = the Care-of Address copied from the 4172 Mobility Agent Advertisement Extension of the 4173 Router Advertisement message 4174 Identification = Network Time Protocol timestamp or Nonce 4175 Extensions: 4176 An authorization-enabling extension (e.g., the Mobile-Home 4177 Authentication Extension) 4179 D.2. Registering with a Co-Located Care-of Address 4181 The mobile node enters a foreign network that contains no foreign 4182 agents. The mobile node obtains an address from a DHCP server [32] 4183 for use as a co-located care-of address. The mobile node supports 4184 all forms of encapsulation (IP-in-IP, minimal encapsulation, and 4185 GRE), desires a copy of broadcast datagrams on the home network, and 4186 does not want simultaneous mobility bindings: 4188 IP fields: 4189 Source Address = care-of address obtained from DHCP server 4190 Destination Address = IP address of home agent 4191 Time to Live = 64 4192 UDP fields: 4193 Source Port = 4194 Destination Port = 434 4195 Registration Request fields: 4196 Type = 1 4197 S=0,B=1,D=1,M=1,G=1 4198 Lifetime = 1800 (seconds) 4199 Home Address = the mobile node's home address 4200 Home Agent = IP address of mobile node's home agent 4201 Care-of Address = care-of address obtained from DHCP server 4202 Identification = Network Time Protocol timestamp or Nonce 4203 Extensions: 4204 The Mobile-Home Authentication Extension 4206 D.3. Deregistration 4208 The mobile node returns home and wishes to deregister all care-of 4209 addresses with its home agent. 4211 IP fields: 4212 Source Address = mobile node's home address 4213 Destination Address = IP address of home agent 4214 Time to Live = 1 4215 UDP fields: 4216 Source Port = 4217 Destination Port = 434 4218 Registration Request fields: 4219 Type = 1 4220 S=0,B=0,D=0,M=0,G=0 4221 Lifetime = 0 4222 Home Address = the mobile node's home address 4223 Home Agent = IP address of mobile node's home agent 4224 Care-of Address = the mobile node's home address 4225 Identification = Network Time Protocol timestamp or Nonce 4226 Extensions: 4227 An authorization-enabling extension (e.g., the Mobile-Home 4228 Authentication Extension) 4230 Appendix E. Applicability of Prefix-Lengths Extension 4232 Caution is indicated with the use of the Prefix-Lengths Extension 4233 over wireless links, due to the irregular coverage areas provided by 4234 wireless transmitters. As a result, it is possible that two foreign 4235 agents advertising the same prefix might indeed provide different 4236 connectivity to prospective mobile nodes. The Prefix-Lengths 4237 Extension SHOULD NOT be included in the advertisements sent by agents 4238 in such a configuration. 4240 Foreign agents using different wireless interfaces would have to 4241 cooperate using special protocols to provide identical coverage in 4242 space, and thus be able to claim to have wireless interfaces situated 4243 on the same subnetwork. In the case of wired interfaces, a mobile 4244 node disconnecting and subsequently connecting to a new point of 4245 attachment, may well send in a new Registration Request no matter 4246 whether the new advertisement is on the same medium as the last 4247 recorded advertisement. And, finally, in areas with dense 4248 populations of foreign agents it would seem unwise to require the 4249 propagation via routing protocols of the subnet prefixes associated 4250 with each individual wireless foreign agent; such a strategy could 4251 lead to quick depletion of available space for routing tables, 4252 unwarranted increases in the time required for processing routing 4253 updates, and longer decision times for route selection if routes 4254 (which are almost always unnecessary) are stored for wireless 4255 "subnets". 4257 Appendix F. Interoperability Considerations 4259 This document specifies revisions to RFC 2002 that are intended to 4260 improve interoperability by resolving ambiguities contained in the 4261 earlier text. Implementations that perform authentication according 4262 to the new more precisely specified algorithm would be interoperable 4263 with earlier implementations that did what was originally expected 4264 for producing authentication data. That was a major source of non- 4265 interoperability before. 4267 However, this specification does have new features that, if used, 4268 would cause interoperability problems with older implementations. 4269 All features specified in RFC 2002 will work with the new 4270 implementations, except for V-J compression [34]. The following list 4271 details some of the possible areas of compatibility problems that may 4272 be experienced by nodes conforming to this revised specification, 4273 when attempting to interoperate with nodes obeying RFC 2002. 4275 o A client that expects some of the newly mandatory features (like 4276 reverse tunneling) from a foreign agent would still be 4277 interoperable as long as it pays attention to the `T' bit. 4279 o Mobile nodes that use the NAI extension to identify themselves 4280 would not work with old mobility agents. 4282 o Mobile nodes that use a zero home address and expect to receive 4283 their home address in the Registration Reply would not work with 4284 old mobility agents. 4286 o Mobile nodes that attempt to authenticate themselves without using 4287 the Mobile-Home authentication extension will be unable to 4288 successful register with their home agent. 4290 In all of these cases, a robust and well-configured mobile node is 4291 very likely to be able to recover if it takes reasonable actions upon 4292 receipt of a Registration Reply with an error code indicating the 4293 cause for rejection. For instance, if a mobile node sends a 4294 registration request that is rejected because it contains the wrong 4295 kind of authentication extension, then the mobile node could retry 4296 the registration with a mobile-home authentication extension, since 4297 the foreign agent and/or home agent in this case will not be 4298 configured to demand the alternative authentication data. 4300 Appendix G. Changes since RFC 2002 4302 G.1. Recent Changes 4304 The following changes have been made since RFC 3344 was published. 4305 For items marked with issue numbers, more information is available by 4306 consulting the MIP4 issues web page, 4307 http://www.mip4.org/issues/tracker/mip4/ 4309 Due to non-unique assignment of IPv4 addresses in many domains, it is 4310 possible for different mobile nodes to have the same home address. 4311 If they use the NAI, the foreign agent can still distinguish them. 4312 Language was added to ?REFERENCE? and ?REFERENCE? to specify that the 4313 foreign agent must use the NAI to distinguish mobile nodes with the 4314 same home address. 4316 o (Issue 45) Specified that a foreign agent MUST NOT apply a 4317 Foreign-Home Authentication extension to a mobile node's 4318 deregistration request. Also, the foreign agent MUST NOT apply a 4319 Foreign-Home Authentication extension unless Care-of Address in 4320 the Registration Request matches an address advertised by the 4321 foreign agent. 4323 o Specified that the mobility security association to be used by the 4324 Foreign Agent and Home Agent depends upon values contained in the 4325 message data, not the IP headers. 4327 o (Issues 9, 18) Created a new error code for use by the foreign 4328 agent, for the case when the foreign agent does not serve the 4329 mobile node as a home agent. Formerly, the foreign agent could 4330 use error code 136 for this case. 4332 o (Issue 17) Specified that, if the Home Agent cannot support the 4333 requested nonzero unicast address in the Home Address field of the 4334 Registration Request, then the it MUST reject the registration 4335 with an error code of 129. See section Section 3.8.3.2. 4337 o (Issue 19) Specified that multiple authorization-enabling 4338 extensions may be present in the Registration Request message, but 4339 that the home agent has to (somehow) ensure that all have been 4340 checked (see section Section 3.8.3.1). 4342 o (Issue 20) Specified that the foreign agent SHOULD NOT modify any 4343 of the fields of the Registration Reply message that are covered 4344 by the Mobile-Home Authentication Extension, when it relays the 4345 packet to the mobile node. 4347 o (Issue 21) Clarified that the foreign agent removes extensions 4348 that do not precede any authorization-enabling extension, not just 4349 the Mobile-Home Authentication extension (section 3.7.3.2). 4351 o (Issue 44) Specified that the address advertised by the foreign 4352 agent in Agent Advertisements is the care-of address offered on 4353 that network interface, not necessarily the address of the network 4354 interface (section 3.7.2.2). 4356 o (Issue 45) Clarification in section 3.7.2.1 that code 77 can only 4357 apply to a Registration Request with nonzero lifetime. 4359 G.2. Major Changes 4361 o Specification for Destination IP address of Registration Reply 4362 transmitted from Foreign Agent, to avoid any possible transmission 4363 to IP address 0.0.0.0. 4365 o Specification of two new formats for Mobile IP extensions, 4366 according to the ideas contained in MIER. 4368 o Specification that the SPI of the MN-HA authentication extension 4369 is to be used as part of the data over which the authentication 4370 algorithm must be computed. 4372 o Eliminated Van-Jacobson Compression feature 4374 o Specification that foreign agents MAY send advertisements at a 4375 rate faster than once per second, but chosen so that the 4376 advertisements do not burden the capacity of the local link. For 4377 simplicity, the foreign agent now MAY send advertisements at an 4378 interval less than 1/3 the advertised ICMP Lifetime. 4380 o Specification that foreign agents SHOULD support reverse 4381 tunneling, and home agents MUST support decapsulation of reverse 4382 tunnels. 4384 o Changed the preconfiguration requirements in section 3.6 for the 4385 mobile node to reflect the capability, specified in RFC 2794 [2], 4386 for the mobile node to identify itself by using its NAI, and then 4387 getting a home address from the Registration Reply. 4389 o Changed section 3.7.3.1 so that a foreign agent is not required to 4390 discard Registration Replies that have a Home Address field that 4391 does not match any pending Registration Request. 4393 o Allowed registrations to be authenticated by use of a security 4394 association between the mobile node and a suitable authentication 4395 entity acceptable to the home agent. Defined "Authorization- 4396 enabling Extension" to be an authentication extension that makes a 4397 registration message acceptable to the recipient. This is needed 4398 according to specification in [2]. 4400 o Mandated that HMAC-MD5 be used instead of the "prefix+suffix" mode 4401 of MD5 as originally mandated in RFC 2002. 4403 o Specified that the mobile node SHOULD take the first care-of 4404 address in a list offered by a foreign agent, and MAY try each 4405 subsequent advertised address in turn if the attempted 4406 registrations are rejected by the foreign agent 4408 o Clarification that a mobility agent SHOULD only put its own 4409 addresses into the initial (i.e., not mobility-related) list of 4410 routers in the mobility advertisement. RFC 2002 suggests that a 4411 mobility agent might advertise other default routers. 4413 o Specification that a mobile node MUST ignore reserved bits in 4414 Agent Advertisements, as opposed to discarding such 4415 advertisements. In this way, new bits can be defined later, 4416 without affecting the ability for mobile nodes to use the 4417 advertisements even when the newly defined bits are not 4418 understood. Furthermore, foreign agents can set the `R' bit to 4419 make sure that new bits are handled by themselves instead of some 4420 legacy mobility agent. 4422 o Specification that the foreign agent checks to make sure that the 4423 indicated home agent address does not belong to any of its network 4424 interfaces before relaying a Registration Request. If the check 4425 fails, and the foreign agent is not the mobile node's home agent, 4426 then the foreign agent rejects the request with code 136 (unknown 4427 home agent address). 4429 o Specification that, while they are away from the home network, 4430 mobile nodes MUST NOT broadcast ARP packets to find the MAC 4431 address of another Internet node. Thus, the (possibly empty) list 4432 of Router Addresses from the ICMP Router Advertisement portion of 4433 the message is not useful for selecting a default router, unless 4434 the mobile node has some means not involving broadcast ARP and not 4435 specified within this document for obtaining the MAC address of 4436 one of the routers in the list. Similarly, in the absence of 4437 unspecified mechanisms for obtaining MAC addresses on foreign 4438 networks, the mobile node MUST ignore redirects to other routers 4439 on foreign networks. 4441 o Specification that a foreign agent MUST NOT use broadcast ARP for 4442 a mobile node's MAC address on a foreign network. It may obtain 4443 the MAC address by copying the information from an Agent 4444 Solicitation or a Registration Request transmitted from a mobile 4445 node. 4447 o Specification that a foreign agent's ARP cache for the mobile 4448 node's IP address MUST NOT be allowed to expire before the mobile 4449 node's visitor list entry expires, unless the foreign agent has 4450 some way other than broadcast ARP to refresh its MAC address 4451 associated to the mobile node's IP address. 4453 o At the end of section 4.6, clarified that a home agent MUST NOT 4454 make any changes to the way it performs proxy ARP after it rejects 4455 an invalid deregistration request. 4457 o In section 4.2.3, specification that multihomed home agents MUST 4458 use the the address sent to the mobile node in the home agent 4459 field of the registration reply as the source address in the outer 4460 IP header of the encapsulated datagram. 4462 o Inserted 'T' bit into its proper place in the Registration Request 4463 message format (section 3.3). 4465 G.3. Minor Changes 4467 o Allowed registration replies to be processed by the mobile node, 4468 even in the absence of any Mobile-Home Authentication extension, 4469 when containing rejection code by the foreign agent. 4470 o Specification that the foreign agent MAY configure a maximum 4471 number of pending registrations that it is willing to maintain 4472 (typically 5). Additional registrations SHOULD then be rejected 4473 by the foreign agent with code 66. The foreign agent MAY delete 4474 any pending Registration Request after the request has been 4475 pending for more than 7 seconds; in this case, the foreign agent 4476 SHOULD reject the Request with code 78 (registration timeout). 4477 o Relaxation of the requirement that, when a mobile node has joined 4478 a multicast group at the router on the foreign network, the mobile 4479 node MUST use its home address as the source IP address for 4480 multicast packets. 4481 o Clarification that a mobility agent MAY use different settings for 4482 each of the 'R', 'H', and 'F' bits on different network 4483 interfaces. 4484 o Replacement of the terminology "recursive tunneling" by the 4485 terminology "nested tunneling". 4486 o Specification that the mobile node MAY use the IP source address 4487 of an agent advertisement as its default router address. 4488 o Clarification that keys with arbitrary binary values MUST be 4489 supported as part of mobility security associations. 4491 o Specification that the default value may be chosen as 7 seconds, 4492 for allowable time skews between a home agent and mobile node 4493 using timestamps for replay protection. Further specification 4494 that this value SHOULD be greater than 3 seconds. 4495 o Specification that Registration Requests with the 'D' bit set to 4496 0, and specifying a care-of address not offered by the foreign 4497 agent, MUST be rejected with code 77 (invalid care-of address). 4498 o Clarification that the foreign agent SHOULD consider its own 4499 maximum value when handling the Lifetime field of the Registration 4500 Reply. 4501 o Clarification that the home agent MUST ignore the 'B' bit (as 4502 opposed to rejecting the Registration Request) if it does not 4503 support broadcasts. 4504 o Advice about the impossibility of using dynamic home agent 4505 discovery in the case when routers change the IP destination 4506 address of a datagram from a subnet-directed broadcast address to 4507 255.255.255.255 before injecting it into the destination subnet. 4508 o Clarified that when an Agent Advertisement is unicast to a mobile 4509 node, the specific IP home address of a mobile node MAY be used as 4510 the destination IP address. 4511 o Included a reference to RFC 2290 within appendix B, which deals 4512 with PPP operation. 4513 o Created IANA Considerations section 4514 o In section 3.8.3, clarified that a home agent SHOULD arrange the 4515 selection of a home address for a mobile node when the 4516 Registration Reply contains a zero Home Address. 4518 G.4. Changes since RFC3344 4520 This section lists the changes between this document and the previous 4521 version of the Mobile IPv4 Proposed Standard, RFC 3344 [43]. 4523 o Created a new error code for use when a Foreign Agent can detect 4524 that the Home Agent address field is incorrect. 4525 o Prohibited the use of the Foreign-Home Authorization Extension on 4526 deregistration messages. 4527 o Cleaned up some more wording having to do with authorization- 4528 enabling extensions. 4529 o For consistency, changed some wording about copying UDP ports. 4530 o Added wording to clearly not disallow dynamically configuring 4531 netmask and security information at the mobile node. 4532 o Revamped Changes section 4533 o Updated citations. 4535 Appendix H. Example Messages 4537 H.1. Example ICMP Agent Advertisement Message Format 4539 0 1 2 3 4540 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 4541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4542 | Type | Code | Checksum | 4543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4544 | Num Addrs |Addr Entry Size| Lifetime | 4545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4546 | Router Address[1] | 4547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4548 | Preference Level[1] | 4549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4550 | Router Address[2] | 4551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4552 | Preference Level[2] | 4553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4554 | .... | 4555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4556 | Type = 16 | Length | Sequence Number | 4557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4558 | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | 4559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4560 | Care-of Address[1] | 4561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4562 | Care-of Address[2] | 4563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4564 | .... | 4565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4566 : Optional Extensions : 4567 : .... ...... ...... : 4568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4570 H.2. Example Registration Request Message Format 4572 The UDP header is followed by the Mobile IP fields shown below: 4574 0 1 2 3 4575 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 4576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4577 | Type = 1 |S|B|D|M|G|r|T|x| Lifetime | 4578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4579 | Home Address | 4580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4581 | Home Agent | 4582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4583 | Care-of Address | 4584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4585 | | 4586 + Identification + 4587 | | 4588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4589 | Optional Non-Auth Extensions for HA ... | 4590 | ( variable length ) | 4591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4592 | Type =32 | Length | SPI | 4593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4594 | SPI (cont..) | | 4595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4596 : MN-HA Authenticator ( variable length ) : 4597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4598 : Optional Non-Auth Extensions for FA ......... 4599 : Optional MN-FA Authentication Extension... 4600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4602 H.3. Example Registration Reply Message Format 4604 The UDP header is followed by the Mobile IP fields shown below: 4606 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 4607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4608 | Type = 3 | Code | Lifetime | 4609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4610 | Home Address | 4611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4612 | Home Agent | 4613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4614 | | 4615 + Identification + 4616 | | 4617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4618 | Optional HA Non-Auth Extensions ... | 4619 | ( variable length ) | 4620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4621 | Type =32 | Length | SPI | 4622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4623 | SPI (cont...) | | 4624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4625 : MN-HA Authenticator ( variable length ) : 4626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4627 : Optional Extensions used by FA......... 4628 : Optional MN-FA Authentication Extension... 4629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4631 Author's Address 4633 Charles E. Perkins 4634 Nokia Siemens Networks 4635 323 Fairchild Dr. 4636 Mountain View, CA 94043 4637 USA 4639 Email: charles.perkins@nsn.com 4641 Full Copyright Statement 4643 Copyright (C) The IETF Trust (2007). 4645 This document is subject to the rights, licenses and restrictions 4646 contained in BCP 78, and except as set forth therein, the authors 4647 retain all their rights. 4649 This document and the information contained herein are provided on an 4650 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4651 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4652 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4653 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4654 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4655 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4657 Intellectual Property 4659 The IETF takes no position regarding the validity or scope of any 4660 Intellectual Property Rights or other rights that might be claimed to 4661 pertain to the implementation or use of the technology described in 4662 this document or the extent to which any license under such rights 4663 might or might not be available; nor does it represent that it has 4664 made any independent effort to identify any such rights. Information 4665 on the procedures with respect to rights in RFC documents can be 4666 found in BCP 78 and BCP 79. 4668 Copies of IPR disclosures made to the IETF Secretariat and any 4669 assurances of licenses to be made available, or the result of an 4670 attempt made to obtain a general license or permission for the use of 4671 such proprietary rights by implementers or users of this 4672 specification can be obtained from the IETF on-line IPR repository at 4673 http://www.ietf.org/ipr. 4675 The IETF invites any interested party to bring to its attention any 4676 copyrights, patents or patent applications, or other proprietary 4677 rights that may cover technology that may be required to implement 4678 this standard. Please address the information to the IETF at 4679 ietf-ipr@ietf.org. 4681 Acknowledgment 4683 Funding for the RFC Editor function is provided by the IETF 4684 Administrative Support Activity (IASA).