idnits 2.17.1 draft-ietf-mip4-rfc3344bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 -- The draft header indicates that this document obsoletes RFC3344, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 8, 2010) is 5129 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '10') ** Obsolete normative reference: RFC 1305 (ref. '11') (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '19') ** Obsolete normative reference: RFC 3344 (ref. '21') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 5226 (ref. '22') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2988 (ref. '26') (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 2002 (ref. '44') (Obsoleted by RFC 3220) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 5 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 WiChorus Inc. 4 Obsoletes: 3344 (if approved) April 8, 2010 5 Intended status: Standards Track 6 Expires: October 10, 2010 8 IP Mobility Support for IPv4, revised 9 draft-ietf-mip4-rfc3344bis-10 11 Abstract 13 This document specifies protocol enhancements that allow transparent 14 routing of IP datagrams to mobile nodes in the Internet. Each mobile 15 node is always identified by its home address, regardless of its 16 current point of attachment to the Internet. While situated away 17 from its home, a mobile node is also associated with a care-of 18 address, which provides information about its current point of 19 attachment to the Internet. The protocol provides for registering 20 the care-of address with a home agent. The home agent sends 21 datagrams destined for the mobile node through a tunnel to the 22 care-of address. After arriving at the end of the tunnel, each 23 datagram is then delivered to the mobile node. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 10, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 5 61 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 63 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 64 1.5. New Architectural Entities . . . . . . . . . . . . . . . 7 65 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 66 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10 67 1.8. Message Format and Protocol Extensibility . . . . . . . . 14 68 1.9. Type-Length-Value Extension Format for Mobile IP 69 Extensions . . . . . . . . . . . . . . . . . . . . . . . 16 70 1.10. Long Extension Format . . . . . . . . . . . . . . . . . . 17 71 1.11. Short Extension Format . . . . . . . . . . . . . . . . . 18 72 2. Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . 19 73 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 19 74 2.1.1. Mobility Agent Advertisement Extension . . . . . . . 21 75 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . . . 24 76 2.1.3. One-byte Padding Extension . . . . . . . . . . . . . 25 77 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 25 78 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 25 79 2.3.1. Advertised Router Addresses . . . . . . . . . . . . . 26 80 2.3.2. Sequence Numbers and Rollover Handling . . . . . . . 27 81 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 27 82 2.4.1. Registration Required . . . . . . . . . . . . . . . . 28 83 2.4.2. Move Detection . . . . . . . . . . . . . . . . . . . 28 84 2.4.3. Returning Home . . . . . . . . . . . . . . . . . . . 30 85 2.4.4. Sequence Numbers and Rollover Handling . . . . . . . 30 86 3. Registration . . . . . . . . . . . . . . . . . . . . . . . . 31 87 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 31 88 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 33 89 3.3. Registration Request . . . . . . . . . . . . . . . . . . 33 90 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 36 91 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 39 92 3.5.1. Computing Authentication Extension Values . . . . . . 39 93 3.5.2. Mobile-Home Authentication Extension . . . . . . . . 40 94 3.5.3. Mobile-Foreign Authentication Extension . . . . . . . 41 95 3.5.4. Foreign-Home Authentication Extension . . . . . . . . 42 97 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 43 98 3.6.1. Sending Registration Requests . . . . . . . . . . . . 44 99 3.6.2. Receiving Registration Replies . . . . . . . . . . . 48 100 3.6.3. Registration Retransmission . . . . . . . . . . . . . 51 101 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 52 102 3.7.1. Configuration and Registration Tables . . . . . . . . 52 103 3.7.2. Receiving Registration Requests . . . . . . . . . . . 53 104 3.7.3. Receiving Registration Replies . . . . . . . . . . . 56 105 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 58 106 3.8.1. Configuration and Registration Tables . . . . . . . . 59 107 3.8.2. Receiving Registration Requests . . . . . . . . . . . 60 108 3.8.3. Sending Registration Replies . . . . . . . . . . . . 64 109 4. Routing Considerations . . . . . . . . . . . . . . . . . . . 68 110 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 68 111 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 68 112 4.2.1. Mobile Node Considerations . . . . . . . . . . . . . 68 113 4.2.2. Foreign Agent Considerations . . . . . . . . . . . . 69 114 4.2.3. Home Agent Considerations . . . . . . . . . . . . . . 70 115 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 71 116 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 72 117 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 73 118 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 75 119 5. Security Considerations . . . . . . . . . . . . . . . . . . . 79 120 5.1. Message Authentication Codes . . . . . . . . . . . . . . 79 121 5.2. Areas of Security Concern in this Protocol . . . . . . . 79 122 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 79 123 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 80 124 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 80 125 5.6. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 80 126 5.7. Replay Protection for Registration Requests . . . . . . . 81 127 5.7.1. Replay Protection using Timestamps . . . . . . . . . 81 128 5.7.2. Replay Protection using Nonces . . . . . . . . . . . 82 129 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 130 6.1. Mobile IP Message Types . . . . . . . . . . . . . . . . . 84 131 6.2. Extensions to RFC 1256 Router Advertisement . . . . . . . 85 132 6.3. Extensions to Mobile IP Registration Messages . . . . . . 85 133 6.4. Code Values for Mobile IP Registration Reply Messages . . 85 134 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87 135 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 89 136 8.1. Normative References . . . . . . . . . . . . . . . . . . 89 137 8.2. Informative References . . . . . . . . . . . . . . . . . 90 138 Appendix A. Pre-RFC5378 Disclaimer . . . . . . . . . . . . . . . 93 139 Appendix B. Link-Layer Considerations . . . . . . . . . . . . . 94 140 Appendix C. TCP Considerations . . . . . . . . . . . . . . . . . 95 141 C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 95 142 C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 95 143 Appendix D. Example Scenarios . . . . . . . . . . . . . . . . . 96 144 D.1. Registering with a Foreign Agent Care-of Address . . . . 96 145 D.2. Registering with a Co-Located Care-of Address . . . . . . 96 146 D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 97 147 Appendix E. Applicability of Prefix-Lengths Extension . . . . . 98 148 Appendix F. Interoperability Considerations . . . . . . . . . . 99 149 Appendix G. Changes since RFC 3344 . . . . . . . . . . . . . . . 100 150 Appendix H. Example Messages . . . . . . . . . . . . . . . . . . 102 151 H.1. Example ICMP Agent Advertisement Message Format . . . . . 102 152 H.2. Example Registration Request Message Format . . . . . . . 102 153 H.3. Example Registration Reply Message Format . . . . . . . . 103 154 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 105 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 [44],[14],[15],[20],[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 [45]. 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 [34] (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 [34], 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 [17] 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 [48]. 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 in 631 Mobile IP control messages (those sent to and from UDP port number 632 434). In this document, the following Types are defined for 633 Extensions appearing in Mobile IP control messages: 635 0 One-byte Padding (encoded with no Length nor Data field) 636 32 Mobile-Home Authentication 637 33 Mobile-Foreign Authentication 638 34 Foreign-Home Authentication 640 o The second set consists of those extensions which may appear in 641 ICMP Router Discovery messages [5]. In this document, the 642 following Types are defined for Extensions appearing in ICMP 643 Router Discovery messages: 645 0 One-byte Padding (encoded with no Length nor Data field) 646 16 Mobility Agent Advertisement 647 19 Prefix-Lengths 649 Each individual Extension is described in detail in a separate 650 section later in this document. Up-to-date values for these 651 Extension Type numbers are specified in the IANA online database 652 [48]. 654 Due to the separation (orthogonality) of these sets, it is 655 conceivable that two Extensions that are defined at a later date 656 could have identical Type values, so long as one of the Extensions 657 may be used only in Mobile IP control messages and the other may be 658 used only in ICMP Router Discovery messages. 660 The type field in the Mobile IP extension structure can support up to 661 255 (skippable and not skippable) uniquely identifiable extensions. 662 When an Extension numbered in either of these sets within the range 0 663 through 127 is encountered but not recognized, the message containing 664 that Extension MUST be silently discarded. When an Extension 665 numbered in the range 128 through 255 is encountered which is not 666 recognized, that particular Extension is ignored, but the rest of the 667 Extensions and message data MUST still be processed. The Length 668 field of the Extension is used to skip the Data field in searching 669 for the next Extension. 671 Unless additional structure is utilized for the extension types, new 672 developments or additions to Mobile IP might require so many new 673 extensions that the available space for extension types might run 674 out. Two new extension structures are proposed to solve this 675 problem. Certain types of extensions can be aggregated, using 676 subtypes to identify the precise extension, for example as has been 677 done with the Generic Authentication Keys extensions [46]. In many 678 cases, this may reduce the rate of allocation for new values of the 679 type field. 681 Since the new extension structures will cause an efficient usage of 682 the extension type space, it is recommended that new Mobile IP 683 extensions follow one of the two new extension formats whenever there 684 may be the possibility to group related extensions together. 686 The following subsections provide details about three distinct 687 structures for Mobile IP extensions: 689 o The simple extension format 690 o The long extension format 691 o The short extension format 693 1.9. Type-Length-Value Extension Format for Mobile IP Extensions 695 The Type-Length-Value format illustrated in Figure 2 is used for 696 extensions which are specified in this document. Since this simple 697 extension structure does not encourage the most efficient usage of 698 the extension type space, it is recommended that new Mobile IP 699 extensions follow one of the two new extension formats specified in 700 Section 1.10 or Section 1.11 whenever there may be the possibility to 701 group related extensions together. 703 0 1 2 704 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 706 | Type | Length | Data ... 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 709 Figure 2: Type-Length-Value extension format for Mobile IPv4 711 Type 713 Indicates the particular type of Extension. 715 Length 717 Indicates the length (in bytes) of the data field within this 718 Extension. The length does NOT include the Type and Length bytes. 720 Data 722 The particular data associated with this Extension. This field 723 may be zero or more bytes in length. The format and length of the 724 data field is determined by the type and length fields. 726 1.10. Long Extension Format 728 This format is applicable for non-skippable extensions which carry 729 information more than 256 bytes. Skippable extensions can never use 730 the long format, because the receiver is not required to include 731 parsing code and is likely to treat the 8 bits immediately following 732 the Type as the Length field. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type | Sub-Type | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Data ..... 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 The Long Extension format requires that the following fields be 743 specified as the first fields of the extension. 745 Type 747 is the type, which describes a collection of extensions having a 748 common data type. 750 Sub-Type 752 is a unique number given to each member in the aggregated type. 754 Length 756 indicates the length (in bytes) of the data field within this 757 Extension. It does NOT include the Type, Length and Sub-Type 758 bytes. 760 Data 762 is the data associated with the subtype of this extension. This 763 specification does not place any additional structure on the 764 subtype data. 766 Since the length field is 16 bits wide, the extension data can exceed 767 256 bytes in length. 769 1.11. Short Extension Format 771 This format is compatible with the skippable extensions defined in 772 Section 1.9. It is not applicable for extensions which require more 773 than 256 bytes of data; for such extensions, use the format described 774 in Section 1.10. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type | Length | Sub-Type | Data .... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 The Short Extension format requires that the following fields be 783 specified as the first fields of the extension: 785 Type 787 is the type, which describes a collection of extensions having a 788 common data type. 790 Sub-Type 792 is a unique number given to each member in the aggregated type. 794 Length 796 8-bit unsigned integer. Length of the extension, in bytes, 797 excluding the extension Type and the extension Length fields. 798 This field MUST be set to 1 plus the total length of the data 799 field. 801 Data 803 is the data associated with this extension. This specification 804 does not place any additional structure on the subtype data. 806 2. Agent Discovery 808 Agent Discovery is the method by which a mobile node determines 809 whether it is currently connected to its home network or to a foreign 810 network, and by which a mobile node can detect when it has moved from 811 one network to another. When connected to a foreign network, the 812 methods specified in this section also allow the mobile node to 813 determine the foreign agent care-of address being offered by each 814 foreign agent on that network. 816 Mobile IP extends ICMP Router Discovery [5] as its primary mechanism 817 for Agent Discovery. An Agent Advertisement is formed by including a 818 Mobility Agent Advertisement Extension in an ICMP Router 819 Advertisement message (Section 2.1). An Agent Solicitation message 820 is identical to an ICMP Router Solicitation, except that its IP TTL 821 MUST be set to 1 (Section 2.2). This section describes the message 822 formats and procedures by which mobile nodes, foreign agents, and 823 home agents cooperate to realize Agent Discovery. 825 Agent Advertisement and Agent Solicitation may not be necessary for 826 link layers that already provide this functionality. The method by 827 which mobile nodes establish link-layer connections with prospective 828 agents is outside the scope of this document (but see Appendix B). 829 The procedures described below assume that such link-layer 830 connectivity has already been established. 832 No authentication is required for Agent Advertisement and Agent 833 Solicitation messages. They MAY be authenticated using the IP 834 Authentication Header [9], which is unrelated to the messages 835 described in this document. Further specification of the way in 836 which Advertisement and Solicitation messages may be authenticated is 837 outside of the scope of this document. 839 2.1. Agent Advertisement 841 Agent Advertisements are transmitted by a mobility agent to advertise 842 its services on a link. Mobile nodes use these advertisements to 843 determine their current point of attachment to the Internet. An 844 Agent Advertisement is an ICMP Router Advertisement that has been 845 extended to also carry an Mobility Agent Advertisement Extension 846 (Section 2.1.1) and, optionally, a Prefix-Lengths Extension 847 (Section 2.1.2), One-byte Padding Extension (Section 2.1.3, or other 848 Extensions that might be defined in the future. 850 Within an Agent Advertisement message, ICMP Router Advertisement 851 fields of the message are required to conform to the following 852 additional specifications: 854 Link-Layer Fields 856 Destination Address 858 The link-layer destination address of a unicast Agent 859 Advertisement MUST be the same as the source link-layer address 860 of the Agent Solicitation which prompted the Advertisement. 862 IP Fields 864 TTL 866 The TTL for all Agent Advertisements MUST be set to 1. 868 Destination Address 870 As specified for ICMP Router Discovery [5], the IP destination 871 address of an multicast Agent Advertisement MUST be either the 872 "all systems on this link" multicast address (224.0.0.1) [6] or 873 the "limited broadcast" address (255.255.255.255). The subnet- 874 directed broadcast address of the form .<-1> cannot be 875 used since mobile nodes will not generally know the prefix of 876 the foreign network. When the Agent Advertisement is unicast 877 to a mobile node, the IP home address of the mobile node SHOULD 878 be used as the Destination Address. 880 ICMP Fields 882 Code 884 The Code field of the agent advertisement is interpreted as 885 follows: 887 0 The mobility agent handles common traffic -- that is, it 888 acts as a router for IP datagrams not necessarily related to 889 mobile nodes. 891 16 The mobility agent does not route common traffic. 892 However, all foreign agents MUST (minimally) forward to a 893 default router any datagrams received from a registered 894 mobile node (Section 4.2.2). 896 Lifetime 898 The maximum length of time that the Advertisement is considered 899 valid in the absence of further Advertisements. 901 Router Address(es) 903 See Section 2.3.1 for a discussion of the addresses that may 904 appear in this portion of the Agent Advertisement. 906 Num Addrs 908 The number of Router Addresses advertised in this message. 909 Note that in an Agent Advertisement message, the number of 910 router addresses specified in the ICMP Router Advertisement 911 portion of the message MAY be set to 0. See Section 2.3.1 for 912 details. 914 If sent periodically, the nominal interval at which Agent 915 Advertisements are sent SHOULD be no longer than 1/3 of the 916 advertisement Lifetime given in the ICMP header. This interval MAY 917 be shorter than 1/3 the advertised Lifetime. This allows a mobile 918 node to miss three successive advertisements before deleting the 919 agent from its list of valid agents. The actual transmission time 920 for each advertisement SHOULD be slightly randomized [5] in order to 921 avoid synchronization and subsequent collisions with other Agent 922 Advertisements that may be sent by other agents (or with other Router 923 Advertisements sent by other routers). Note that this field has no 924 relation to the "Registration Lifetime" field within the Mobility 925 Agent Advertisement Extension defined below. 927 2.1.1. Mobility Agent Advertisement Extension 929 The Mobility Agent Advertisement Extension follows the ICMP Router 930 Advertisement fields. It is used to indicate that an ICMP Router 931 Advertisement message is also an Agent Advertisement being sent by a 932 mobility agent. The Mobility Agent Advertisement Extension is 933 defined as follows: 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Length | Sequence Number | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Registration Lifetime |R|B|H|F|M|G|r|T|U|X|I|reserved | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | zero or more Care-of Addresses | 943 | ... | 945 Type 947 16 949 Length 951 (6 + 4*N), where 6 accounts for the number of bytes in the 952 Sequence Number, Registration Lifetime, flags, and reserved 953 fields, and N is the number of care-of addresses advertised. 955 Sequence Number 957 The count of Agent Advertisement messages sent since the agent was 958 initialized (Section 2.3.2). 960 Registration Lifetime 962 The longest lifetime (measured in seconds) that this agent is 963 willing to accept in any Registration Request. A value of 0xffff 964 indicates infinity. This field has no relation to the "Lifetime" 965 field within the ICMP Router Advertisement portion of the Agent 966 Advertisement. 968 R 970 Registration required. Registration with this foreign agent (or 971 another foreign agent on this link) is required even when using a 972 co-located care-of address. 974 B 976 Busy. The foreign agent will not accept registrations from 977 additional mobile nodes. 979 H 981 Home agent. This agent offers service as a home agent on the link 982 on which this Agent Advertisement message is sent. 984 F 986 Foreign agent. This agent offers service as a foreign agent on 987 the link on which this Agent Advertisement message is sent. 989 M 991 Minimal encapsulation. This agent implements receiving tunneled 992 datagrams that use minimal encapsulation [15]. 994 G 996 GRE encapsulation. This agent implements receiving tunneled 997 datagrams that use GRE encapsulation [13]. 999 r 1001 Sent as zero; ignored on reception. SHOULD NOT be allocated for 1002 any other uses. 1004 T 1006 Foreign agent supports reverse tunneling as specified in [12]. 1008 U 1010 Mobility agent supports UDP Tunnelling as specified in [27]. 1012 X 1014 Mobility agent supports Registration Revocation as specified in 1015 [28]. 1017 I 1019 Foreign agent supports Regional Registration as specified in [29]. 1021 reserved 1023 Sent as zero; ignored on reception. 1025 Care-of Address(es) 1027 The advertised foreign agent care-of address(es) provided by this 1028 foreign agent. An Agent Advertisement MUST include at least one 1029 care-of address if the 'F' bit is set. The number of care-of 1030 addresses present is determined by the Length field in the 1031 Extension. 1033 A home agent MUST always be prepared to serve the mobile nodes for 1034 which it is the home agent. A foreign agent may at times be too busy 1035 to serve additional mobile nodes; even so, it must continue to send 1036 Agent Advertisements, so that any mobile nodes already registered 1037 with it will know that they have not moved out of range of the 1038 foreign agent and that the foreign agent has not failed. A foreign 1039 agent may indicate that it is "too busy" to allow new mobile nodes to 1040 register with it, by setting the 'B' bit in its Agent Advertisements. 1041 An Agent Advertisement message MUST NOT have the 'B' bit set if the 1042 'F' bit is not also set. Furthermore, at least one of the 'F' bit 1043 and the 'H' bit MUST be set in any Agent Advertisement message sent. 1045 When a foreign agent wishes to require registration even from those 1046 mobile nodes which have acquired a co-located care-of address, it 1047 sets the 'R' bit to one. Because this bit applies only to foreign 1048 agents, an agent MUST NOT set the 'R' bit to one unless the 'F' bit 1049 is also set to one. 1051 2.1.2. Prefix-Lengths Extension 1053 The Prefix-Lengths Extension MAY follow the Mobility Agent 1054 Advertisement Extension. It is used to indicate the number of bits 1055 of network prefix that applies to each Router Address listed in the 1056 ICMP Router Advertisement portion of the Agent Advertisement. Note 1057 that the prefix lengths given DO NOT apply to care-of address(es) 1058 listed in the Mobility Agent Advertisement Extension. The Prefix- 1059 Lengths Extension is defined as follows: 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Type | Length | Prefix Length | .... 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 Type 1069 19 (Prefix-Lengths Extension) 1071 Length 1073 N, where N is the value (possibly zero) of the Num Addrs field in 1074 the ICMP Router Advertisement portion of the Agent Advertisement. 1076 Prefix Length(s) 1078 The number of leading bits that define the network number of the 1079 corresponding Router Address listed in the ICMP Router 1080 Advertisement portion of the message. The prefix length for each 1081 Router Address is encoded as a separate byte, in the order that 1082 the Router Addresses are listed in the ICMP Router Advertisement 1083 portion of the message. 1085 See Section 2.4.2 for information about how the Prefix-Lengths 1086 Extension MAY be used by a mobile node when determining whether it 1087 has moved. See Appendix E for implementation details about the use 1088 of this Extension. 1090 2.1.3. One-byte Padding Extension 1092 Some IP protocol implementations insist upon padding ICMP messages to 1093 an even number of bytes. If the ICMP length of an Agent 1094 Advertisement is odd, this Extension MAY be included in order to make 1095 the ICMP length even. Note that this Extension is NOT intended to be 1096 a general-purpose Extension to be included in order to word- or long- 1097 align the various fields of the Agent Advertisement. An Agent 1098 Advertisement SHOULD NOT include more than one One-byte Padding 1099 Extension and if present, this Extension SHOULD be the last Extension 1100 in the Agent Advertisement. 1102 Note that unlike other Extensions used in Mobile IP, the One-byte 1103 Padding Extension is encoded as a single byte, with no "Length" nor 1104 "Data" field present. The One-byte Padding Extension is defined as 1105 follows: 1107 0 1 2 3 4 5 6 7 1108 +-+-+-+-+-+-+-+-+ 1109 | Type | 1110 +-+-+-+-+-+-+-+-+ 1112 Type 0 (One-byte Padding Extension) 1114 2.2. Agent Solicitation 1116 An Agent Solicitation is identical to an ICMP Router Solicitation 1117 with the further restriction that the IP TTL Field MUST be set to 1. 1119 2.3. Foreign Agent and Home Agent Considerations 1121 Any mobility agent which cannot be discovered by a link-layer 1122 protocol MUST send Agent Advertisements. An agent which can be 1123 discovered by a link-layer protocol SHOULD also implement Agent 1124 Advertisements. However, the Advertisements need not be sent, except 1125 when the site policy requires registration with the agent (i.e., when 1126 the 'R' bit is set), or as a response to a specific Agent 1127 Solicitation. All mobility agents MUST process packets that they 1128 receive addressed to the Mobile-Agents multicast group, at address 1129 224.0.0.11. A mobile node MAY send an Agent Solicitation to 1130 224.0.0.11. All mobility agents SHOULD respond to Agent 1131 Solicitations. 1133 The same procedures, defaults, and constants are used in Agent 1134 Advertisement messages and Agent Solicitation messages as specified 1135 for ICMP Router Discovery [5], except that: 1137 o a mobility agent MUST limit the rate at which it sends broadcast 1138 or multicast Agent Advertisements; the maximum rate SHOULD be 1139 chosen so that the Advertisements do not consume a significant 1140 amount of network bandwidth, AND 1142 o a mobility agent that receives a Router Solicitation MUST NOT 1143 require that the IP Source Address is the address of a neighbor 1144 (i.e., an address that matches one of the router's own addresses 1145 on the arrival interface, under the subnet mask associated with 1146 that address of the router). 1148 o a mobility agent MAY be configured to send Agent Advertisements 1149 only in response to an Agent Solicitation message. 1151 If the home network is not a virtual network, then the home agent for 1152 any mobile node SHOULD be located on the link identified by the 1153 mobile node's home address, and Agent Advertisement messages sent by 1154 the home agent on this link MUST have the 'H' bit set. In this way, 1155 mobile nodes on their own home network will be able to determine that 1156 they are indeed at home. Any Agent Advertisement messages sent by 1157 the home agent on another link to which it may be attached (if it is 1158 a mobility agent serving more than one link), MUST NOT have the 'H' 1159 bit set unless the home agent also serves as a home agent (to other 1160 mobile nodes) on that other link. A mobility agent MAY use different 1161 settings for each of the 'R', 'H', and 'F' bits on different network 1162 interfaces. 1164 If the home network is a virtual network, the home network has no 1165 physical realization external to the home agent itself. In this 1166 case, there is no physical network link on which to send Agent 1167 Advertisement messages advertising the home agent. Mobile nodes for 1168 which this is the home network are always treated as being away from 1169 home. 1171 On a particular subnet, either all mobility agents MUST include the 1172 Prefix-Lengths Extension or all of them MUST NOT include this 1173 Extension. Equivalently, it is prohibited for some agents on a given 1174 subnet to include the Extension but for others not to include it. 1175 Otherwise, one of the move detection algorithms designed for mobile 1176 nodes will not function properly (Section 2.4.2). 1178 2.3.1. Advertised Router Addresses 1180 The ICMP Router Advertisement portion of the Agent Advertisement MAY 1181 contain one or more router addresses. An agent SHOULD only put its 1182 own addresses, if any, in the advertisement. Whether or not its own 1183 address appears in the Router Addresses, a foreign agent MUST route 1184 datagrams it receives from registered mobile nodes (Section 3.7). 1186 2.3.2. Sequence Numbers and Rollover Handling 1188 The sequence number in Agent Advertisements ranges from 0 to 0xffff. 1189 After booting, an agent MUST use the number 0 for its first 1190 advertisement. Each subsequent advertisement MUST use the sequence 1191 number one greater, with the exception that the sequence number 1192 0xffff MUST be followed by sequence number 256. In this way, mobile 1193 nodes can distinguish a reduction in the sequence number that occurs 1194 after a reboot from a reduction that results in rollover of the 1195 sequence number after it attains the value 0xffff. 1197 2.4. Mobile Node Considerations 1199 Every mobile node MUST implement Agent Solicitation. Solicitations 1200 SHOULD only be sent in the absence of Agent Advertisements and when a 1201 care-of address has not been determined through a link-layer protocol 1202 or other means. The mobile node uses the same procedures, defaults, 1203 and constants for Agent Solicitation as specified for ICMP Router 1204 Solicitation messages [5], except that the mobile node MAY solicit 1205 more often than once every three seconds, and that a mobile node that 1206 is currently not connected to any foreign agent MAY solicit more 1207 times than MAX_SOLICITATIONS. 1209 The rate at which a mobile node sends Solicitations MUST be limited 1210 by the mobile node. The mobile node MAY send three initial 1211 Solicitations at a maximum rate of one per second while searching for 1212 an agent. After this, the rate at which Solicitations are sent MUST 1213 be reduced so as to limit the overhead on the local link. Subsequent 1214 Solicitations MUST be sent using a binary exponential backoff 1215 mechanism, doubling the interval between consecutive Solicitations, 1216 up to a maximum interval. The maximum interval SHOULD be chosen 1217 appropriately based upon the characteristics of the media over which 1218 the mobile node is soliciting. This maximum interval SHOULD be at 1219 least one minute between Solicitations. 1221 While still searching for an agent, the mobile node MUST NOT increase 1222 the rate at which it sends Solicitations unless it has received a 1223 positive indication that it has moved to a new link. After 1224 successfully registering with an agent, the mobile node SHOULD also 1225 increase the rate at which it will send Solicitations when it next 1226 begins searching for a new agent with which to register. The 1227 increased solicitation rate MAY revert to the maximum rate, but then 1228 MUST be limited in the manner described above. In all cases, the 1229 recommended solicitation intervals are nominal values. Mobile nodes 1230 MUST randomize their solicitation times around these nominal values 1231 as specified for ICMP Router Discovery [5]. 1233 Mobile nodes MUST process received Agent Advertisements. A mobile 1234 node can distinguish an Agent Advertisement message from other uses 1235 of the ICMP Router Advertisement message by examining the number of 1236 advertised addresses and the IP Total Length field. When the IP 1237 total length indicates that the ICMP message is longer than needed 1238 for the number of advertised addresses, the remaining data is 1239 interpreted as one or more Extensions. The presence of a Mobility 1240 Agent Advertisement Extension identifies the advertisement as an 1241 Agent Advertisement. 1243 If there is more than one advertised address, the mobile node SHOULD 1244 pick the first address for its initial registration attempt. If the 1245 registration attempt fails with a status Code indicating rejection by 1246 the foreign agent, the mobile node MAY retry the attempt with each 1247 subsequent advertised address in turn. 1249 When multiple methods of agent discovery are in use, the mobile node 1250 SHOULD first attempt registration with agents including Mobility 1251 Agent Advertisement Extensions in their advertisements, in preference 1252 to those discovered by other means. This preference maximizes the 1253 likelihood that the registration will be recognized, thereby 1254 minimizing the number of registration attempts. 1256 A mobile node MUST ignore reserved bits in Agent Advertisements, as 1257 opposed to discarding such advertisements. In this way, new bits can 1258 be defined later, without affecting the ability for mobile nodes to 1259 use the advertisements even when the newly defined bits are not 1260 understood. 1262 2.4.1. Registration Required 1264 When the mobile node receives an Agent Advertisement with the 'R' bit 1265 set, the mobile node SHOULD register through the foreign agent, even 1266 when the mobile node might be able to acquire its own co-located 1267 care-of address. This feature is intended to allow sites to enforce 1268 visiting policies (such as accounting) which require exchanges of 1269 authorization. 1271 If formerly reserved bits require some kind of monitoring/enforcement 1272 at the foreign link, foreign agents implementing the new 1273 specification for the formerly reserved bits can set the 'R' bit. 1274 This has the effect of forcing the mobile node to register through 1275 the foreign agent, so the foreign agent could then monitor/enforce 1276 the policy. 1278 2.4.2. Move Detection 1280 Two primary mechanisms are provided for mobile nodes to detect when 1281 they have moved from one subnet to another. Other mechanisms MAY 1282 also be used. When the mobile node detects that it has moved, it 1283 SHOULD register (Section 3) with a suitable care-of address on the 1284 new foreign network. However, the mobile node MUST NOT register more 1285 frequently than once per second on average, as specified in 1286 Section 3.6.3. 1288 2.4.2.1. Algorithm 1 1290 The first method of move detection is based upon the Lifetime field 1291 within the main body of the ICMP Router Advertisement portion of the 1292 Agent Advertisement. A mobile node SHOULD record the Lifetime 1293 received in any Agent Advertisements, until that Lifetime expires. 1294 If the mobile node fails to receive another advertisement from the 1295 same agent within the specified Lifetime, it SHOULD assume that it 1296 has lost contact with that agent. If the mobile node has previously 1297 received an Agent Advertisement from another agent for which the 1298 Lifetime field has not yet expired, the mobile node MAY immediately 1299 attempt registration with that other agent. Otherwise, the mobile 1300 node SHOULD attempt to discover a new agent with which to register. 1302 2.4.2.2. Algorithm 2 1304 The second method uses network prefixes. The Prefix-Lengths 1305 Extension MAY be used in some cases by a mobile node to determine 1306 whether or not a newly received Agent Advertisement was received on 1307 the same subnet as the mobile node's current care-of address. If the 1308 prefixes differ, the mobile node MAY assume that it has moved. If a 1309 mobile node is currently using a foreign agent care-of address, the 1310 mobile node SHOULD NOT use this method of move detection unless both 1311 the current agent and the new agent include the Prefix-Lengths 1312 Extension in their respective Agent Advertisements; if this Extension 1313 is missing from one or both of the advertisements, this method of 1314 move detection SHOULD NOT be used. Similarly, if a mobile node is 1315 using a co-located care-of address, it SHOULD NOT use this method of 1316 move detection unless the new agent includes the Prefix-Lengths 1317 Extension in its Advertisement and the mobile node knows the network 1318 prefix of its current co-located care-of address. On the expiration 1319 of its current registration, if this method indicates that the mobile 1320 node has moved, rather than re-registering with its current care-of 1321 address, a mobile node MAY choose instead to register with a the 1322 foreign agent sending the new Advertisement with the different 1323 network prefix. The Agent Advertisement on which the new 1324 registration is based MUST NOT have expired according to its Lifetime 1325 field. 1327 2.4.3. Returning Home 1329 A mobile node can detect that it has returned to its home network 1330 when it receives an Agent Advertisement from its own home agent. If 1331 so, it SHOULD deregister with its home agent (Section 3). Before 1332 attempting to deregister, the mobile node SHOULD configure its 1333 routing table appropriately for its home network (Section 4.2.1). In 1334 addition, if the home network is using ARP [16], the mobile node MUST 1335 follow the procedures described in Section 4.6 with regard to ARP, 1336 proxy ARP, and gratuitous ARP. 1338 2.4.4. Sequence Numbers and Rollover Handling 1340 If a mobile node detects two successive values of the sequence number 1341 in the Agent Advertisements from the foreign agent with which it is 1342 registered, the second of which is less than the first and inside the 1343 range 0 to 255, the mobile node SHOULD register again. If the second 1344 value is less than the first but is greater than or equal to 256, the 1345 mobile node SHOULD assume that the sequence number has rolled over 1346 past its maximum value (0xffff), and that reregistration is not 1347 necessary (Section 2.3). 1349 3. Registration 1351 Mobile IP registration provides a flexible mechanism for mobile nodes 1352 to communicate their current reachability information to their home 1353 agent. It is the method by which mobile nodes: 1355 o request forwarding services when visiting a foreign network, 1357 o inform their home agent of their current care-of address, 1359 o renew a registration which is due to expire, and/or 1361 o deregister when they return home. 1363 Registration messages exchange information between a mobile node, 1364 (optionally) a foreign agent, and the home agent. Registration 1365 creates or modifies a mobility binding at the home agent, associating 1366 the mobile node's home address with its care-of address for the 1367 specified Lifetime. 1369 Several other (optional) capabilities are available through the 1370 registration procedure, which enable a mobile node to: 1372 o discover its home address, if the mobile node is not configured 1373 with this information. 1375 o maintain multiple simultaneous registrations, so that a copy of 1376 each datagram will be tunneled to each active care-of address 1378 o deregister specific care-of addresses while retaining other 1379 mobility bindings, and 1381 o discover the address of a home agent if the mobile node is not 1382 configured with this information. 1384 3.1. Registration Overview 1386 Mobile IP defines two different registration procedures, one via a 1387 foreign agent that relays the registration to the mobile node's home 1388 agent, and one directly with the mobile node's home agent. The 1389 following rules determine which of these two registration procedures 1390 to use in any particular circumstance: 1392 o If a mobile node is registering a foreign agent care-of address, 1393 the mobile node MUST register via that foreign agent. 1395 o If a mobile node is using a co-located care-of address, and 1396 receives an Agent Advertisement from a foreign agent on the link 1397 on which it is using this care-of address, the mobile node SHOULD 1398 register via that foreign agent (or via another foreign agent on 1399 this link) if the 'R' bit is set in the received Agent 1400 Advertisement message. 1402 o If a mobile node is otherwise using a co-located care-of address, 1403 the mobile node MUST register directly with its home agent. 1405 o If a mobile node has returned to its home network and is 1406 (de)registering with its home agent, the mobile node MUST register 1407 directly with its home agent. 1409 Both registration procedures involve the exchange of Registration 1410 Request and Registration Reply messages (Section 3.3 and 1411 Section 3.4). When registering via a foreign agent, the registration 1412 procedure requires the following four messages: 1414 a. The mobile node sends a Registration Request to the prospective 1415 foreign agent to begin the registration process. 1417 b. The foreign agent processes the Registration Request and then 1418 relays it to the home agent. 1420 c. The home agent sends a Registration Reply to the foreign agent to 1421 grant or deny the Request. 1423 d. The foreign agent processes the Registration Reply and then 1424 relays it to the mobile node to inform it of the disposition of 1425 its Request. 1427 When the mobile node instead registers directly with its home agent, 1428 the registration procedure requires only the following two messages: 1430 a. The mobile node sends a Registration Request to the home agent. 1432 b. The home agent sends a Registration Reply to the mobile node, 1433 granting or denying the Request. 1435 The registration messages defined in Section 3.3 and Section 3.4 use 1436 the User Datagram Protocol (UDP) [17]. A nonzero UDP checksum SHOULD 1437 be included in the header, and MUST be checked by the recipient. A 1438 zero UDP checksum SHOULD be accepted by the recipient. The behavior 1439 of the mobile node and the home agent with respect to their mutual 1440 acceptance of packets with zero UDP checksums SHOULD be defined as 1441 part of the mobility security association which exists between them. 1443 3.2. Authentication 1445 Each mobile node, foreign agent, and home agent MUST be able to 1446 support a mobility security association for mobile entities, indexed 1447 by their SPI and IP address. In the case of the mobile node, this 1448 must be its Home Address. See Section 5.1 for requirements for 1449 support of authentication algorithms. Registration messages between 1450 a mobile node and its home agent MUST be authenticated with an 1451 authorization-enabling extension, e.g. the Mobile-Home Authentication 1452 Extension (Section 3.5.2). This extension MUST be the first 1453 authentication extension; other foreign agent-specific extensions MAY 1454 be added to the message after the mobile node computes the 1455 authentication. 1457 3.3. Registration Request 1459 A mobile node registers with its home agent using a Registration 1460 Request message so that its home agent can create or modify a 1461 mobility binding for that mobile node (e.g., with a new lifetime). 1462 The Request may be relayed to the home agent by the foreign agent 1463 through which the mobile node is registering, or it may be sent 1464 directly to the home agent in the case in which the mobile node is 1465 registering a co-located care-of address. 1467 IP fields: 1469 Source Address 1471 Typically the interface address from which the message is sent. 1473 Destination Address 1475 Typically that of the foreign agent or the home agent. 1477 See Section 3.6.1.1 and Section 3.7.2.2 for details. 1479 UDP fields: 1481 Source Port 1483 variable 1485 Destination Port 1487 434 1489 The UDP header is followed by the Mobile IP fields shown below: 1491 0 1 2 3 1492 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 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Type |S|B|D|M|G|r|T|x| Lifetime | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Home Address | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Home Agent | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Care-of Address | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | | 1503 + Identification + 1504 | | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Extensions ... 1507 +-+-+-+-+-+-+-+- 1509 Type 1511 1 (Registration Request) 1513 S 1515 Simultaneous bindings. If the 'S' bit is set, the mobile node is 1516 requesting that the home agent retain its prior mobility bindings, 1517 as described in Section 3.6.1.2. 1519 B 1521 Broadcast datagrams. If the 'B' bit is set, the mobile node 1522 requests that the home agent tunnel to it any broadcast datagrams 1523 that it receives on the home network, as described in Section 4.3. 1525 D 1527 Decapsulation by mobile node. If the 'D' bit is set, the mobile 1528 node will itself decapsulate datagrams which are sent to the 1529 care-of address. That is, the mobile node is using a co-located 1530 care-of address. 1532 M 1534 Minimal encapsulation. If the 'M' bit is set, the mobile node 1535 requests that its home agent use minimal encapsulation [16] for 1536 datagrams tunneled to the mobile node. 1538 G 1540 GRE encapsulation. If the 'G' bit is set, the mobile node 1541 requests that its home agent use GRE encapsulation [13] for 1542 datagrams tunneled to the mobile node. 1544 r 1546 Sent as zero; ignored on reception. SHOULD NOT be allocated for 1547 any other uses. 1549 T 1551 Reverse Tunneling requested; see [12]. 1553 x 1555 Sent as zero; ignored on reception. 1557 Lifetime 1559 The number of seconds remaining before the registration is 1560 considered expired. A value of zero indicates a request for 1561 deregistration. A value of 0xffff indicates infinity. 1563 Home Address 1565 The IP address of the mobile node. 1567 Home Agent 1569 The IP address of the mobile node's home agent. 1571 Care-of Address 1573 The IP address for the end of the tunnel. 1575 Identification 1577 A 64-bit number, constructed by the mobile node, used for matching 1578 Registration Requests with Registration Replies, and for 1579 protecting against replay attacks of registration messages. See 1580 Section 5.4 and Section 5.7. 1582 Extensions 1584 The fixed portion of the Registration Request is followed by one 1585 or more of the Extensions listed in Section 3.5. An 1586 authorization-enabling extension MUST be included in all 1587 Registration Requests. See Section 3.6.1.3 and Section 3.7.2.2 1588 for information on the relative order in which different 1589 extensions, when present, MUST be placed in a Registration Request 1590 message. 1592 3.4. Registration Reply 1594 A mobility agent typically returns a Registration Reply message to a 1595 mobile node which has sent a Registration Request message. If the 1596 mobile node is requesting service from a foreign agent, that foreign 1597 agent will typically receive the Reply from the home agent and 1598 subsequently relay it to the mobile node. Reply messages contain the 1599 necessary codes to inform the mobile node about the status of its 1600 Request, along with the lifetime granted by the home agent, which MAY 1601 be smaller than the original Request. 1603 The foreign agent MUST NOT increase the Lifetime selected by the 1604 mobile node in the Registration Request, since the Lifetime is 1605 covered by an authentication extension which enables authorization by 1606 the home agent. Such an extension contains authentication data which 1607 cannot be correctly (re)computed by the foreign agent. The home 1608 agent MUST NOT increase the Lifetime selected by the mobile node in 1609 the Registration Request, since doing so could increase it beyond the 1610 maximum Registration Lifetime allowed by the foreign agent. If the 1611 Lifetime received in the Registration Reply is greater than that in 1612 the Registration Request, the Lifetime in the Request MUST be used. 1613 When the Lifetime received in the Registration Reply is less than 1614 that in the Registration Request, the Lifetime in the Reply MUST be 1615 used. 1617 IP fields: 1619 Source Address 1621 Typically copied from the destination address of the 1622 Registration Request to which the agent is replying. See 1623 Section 3.7.2.3 and Section 3.8.3.2 for complete details. 1625 Destination Address 1627 Copied from the source address of the Registration Request to 1628 which the agent is replying 1630 UDP fields: 1632 Source Port 1634 Copied from the UDP destination port of the corresponding 1635 Registration Request. 1637 Destination Port 1639 Copied from the source port of the corresponding Registration 1640 Request (Section 3.7.1). 1642 The UDP header is followed by the Mobile IP fields shown below: 1644 0 1 2 3 1645 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 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Type | Code | Lifetime | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Home Address | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Home Agent | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | | 1654 + Identification + 1655 | | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Extensions ... 1658 +-+-+-+-+-+-+-+- 1660 Type 1662 3 (Registration Reply) 1664 Code 1666 A value indicating the result of the Registration Request. See 1667 below for a list of currently defined Code values. 1669 Lifetime 1671 If the Code field indicates that the registration was accepted, 1672 the Lifetime field is set to the number of seconds remaining 1673 before the registration is considered expired. A value of zero 1674 indicates that the mobile node has been deregistered. A value of 1675 0xffff indicates infinity. If the Code field indicates that the 1676 registration was denied, the contents of the Lifetime field are 1677 unspecified and MUST be ignored on reception. 1679 Home Address 1681 The IP address of the mobile node. 1683 Home Agent 1685 The IP address of the mobile node's home agent. 1687 Identification 1689 A 64-bit number used for matching Registration Requests with 1690 Registration Replies, and for protecting against replay attacks of 1691 registration messages. The value is based on the Identification 1692 field from the Registration Request message from the mobile node, 1693 and on the style of replay protection used in the security context 1694 between the mobile node and its home agent (defined by the 1695 mobility security association between them, and SPI value in the 1696 authorization-enabling extension). See Section 5.4 and 1697 Section 5.7. 1699 Extensions 1701 The fixed portion of the Registration Reply is followed by one or 1702 more of the Extensions listed in Section 3.5. An authorization- 1703 enabling extension MUST be included in all Registration Replies 1704 returned by the home agent. See Section 3.7.2.2 and 1705 Section 3.8.3.3 for rules on placement of extensions to Reply 1706 messages. 1708 The following values are defined for use within the Code field. 1709 Registration successful: 1711 0 registration accepted 1712 1 registration accepted, but simultaneous mobility bindings 1713 unsupported 1715 Registration denied by the foreign agent: 1717 64 reason unspecified 1718 65 administratively prohibited 1719 66 insufficient resources 1720 67 mobile node failed authentication 1721 68 home agent failed authentication 1722 69 requested Lifetime too long 1723 70 poorly formed Request 1724 71 poorly formed Reply 1725 72 requested encapsulation unavailable 1726 73 reserved and unavailable 1727 TBD-IANA Invalid Home Agent address 1728 77 invalid care-of address 1729 78 registration timeout 1730 80 home network unreachable (ICMP error received) 1731 81 home agent host unreachable (ICMP error received) 1732 82 home agent port unreachable (ICMP error received) 1733 88 home agent unreachable (other ICMP error received) 1735 Registration denied by the home agent: 1737 128 reason unspecified 1738 129 administratively prohibited 1739 130 insufficient resources 1740 131 mobile node failed authentication 1741 132 foreign agent failed authentication 1742 133 registration Identification mismatch 1743 134 poorly formed Request 1744 135 too many simultaneous mobility bindings 1745 136 unknown home agent address 1747 Up-to-date values of the Code field are specified in the IANA online 1748 database [48]. 1750 3.5. Registration Extensions 1752 3.5.1. Computing Authentication Extension Values 1754 The Authenticator value computed for each authentication Extension 1755 MUST protect the following fields from the registration message: 1757 o the UDP payload (that is, the Registration Request or Registration 1758 Reply data), 1760 o all prior Extensions in their entirety, and 1762 o the Type, Length, and SPI of this Extension. 1764 The default authentication algorithm uses HMAC-MD5 [10] to compute a 1765 128-bit "message digest" of the registration message. The data over 1766 which the HMAC is computed is defined as: 1768 o the UDP payload (that is, the Registration Request or Registration 1769 Reply data), 1771 o all prior Extensions in their entirety, and 1772 o the Type, Length, and SPI of this Extension. 1774 Note that the Authenticator field itself and the UDP header are NOT 1775 included in the computation of the default Authenticator value. See 1776 Section 5.1 for information about support requirements for message 1777 authentication codes, which are to be used with the various 1778 authentication Extensions. 1780 The Security Parameter Index (SPI) within any of the authentication 1781 Extensions defines the security context which is used to compute the 1782 Authenticator value and which MUST be used by the receiver to check 1783 that value. In particular, the SPI selects the authentication 1784 algorithm and mode (Section 5.1) and secret (a shared key, or 1785 appropriate public/private key pair) used in computing the 1786 Authenticator. In order to ensure interoperability between different 1787 implementations of the Mobile IP protocol, an implementation MUST be 1788 able to associate any SPI value with any authentication algorithm and 1789 mode which it implements. In addition, all implementations of Mobile 1790 IP MUST implement the default authentication algorithm (HMAC-MD5) 1791 specified above. 1793 3.5.2. Mobile-Home Authentication Extension 1795 At least one authorization-enabling extension MUST be present in all 1796 Registration Requests, and also in all Registration Replies generated 1797 by the Home Agent. The Mobile-Home Authentication Extension is 1798 always an authorization-enabling for registration messages specified 1799 in this document. This requirement is intended to eliminate problems 1800 [30] which result from the uncontrolled propagation of remote 1801 redirects in the Internet. The location of the authorization- 1802 enabling extension marks the end of the data to be authenticated by 1803 the authorizing agent interpreting that authorization-enabling 1804 extension. 1806 0 1 2 3 1807 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 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Type | Length | SPI .... 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 ... SPI (cont.) | Authenticator ... 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 Type 1816 32 1818 Length 1820 4 plus the number of bytes in the Authenticator. 1822 SPI 1824 Security Parameter Index (4 bytes). An opaque identifier (see 1825 Section 1.6). 1827 Authenticator 1829 (variable length) (See Section 3.5.1) 1831 3.5.3. Mobile-Foreign Authentication Extension 1833 This Extension MAY be included in Registration Requests and Replies 1834 in cases in which a mobility security association exists between the 1835 mobile node and the foreign agent. See Section 5.1 for information 1836 about support requirements for message authentication codes. 1838 0 1 2 3 1839 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 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | Type | Length | SPI .... 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 ... SPI (cont.) | Authenticator ... 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 Type 1848 33 1850 Length 1852 4 plus the number of bytes in the Authenticator. 1854 SPI 1856 Security Parameter Index (4 bytes). An opaque identifier (see 1857 Section 1.6). 1859 Authenticator 1861 (variable length) (See Section 3.5.1) 1863 3.5.4. Foreign-Home Authentication Extension 1865 This Extension MAY be included in Registration Requests and Replies 1866 in cases in which a mobility security association exists between the 1867 foreign agent and the home agent, as long as the Registration Request 1868 is not a deregistration (i.e., the mobile node requested a nonzero 1869 lifetime and the home address is different than the care-of address). 1870 The Foreign-Home Authentication extension MUST NOT be applied to 1871 deregistration messages. See Section 5.1 for information about 1872 support requirements for message authentication codes. 1874 0 1 2 3 1875 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 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | Type | Length | SPI .... 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 ... SPI (cont.) | Authenticator ... 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 Type 1884 34 1886 Length 1888 4 plus the number of bytes in the Authenticator. 1890 SPI 1892 Security Parameter Index (4 bytes). An opaque identifier (see 1893 Section 1.6). 1895 Authenticator 1897 (variable length) (See Section 3.5.1) 1899 In order to perform the authentication, the Home Agent and the 1900 Foreign Agent are configured with a mobility security association 1901 that is indexed by the SPI (in the appended Foreign-Home 1902 Authentication Extension) and the IP Source Address of the 1903 Registration Request. When the extension is used with a Registration 1904 Reply message, the foreign agent address MUST be used as the 1905 Destination IP address in the IP header. 1907 When this extension is applied to a Registration Request message, the 1908 mobility security association for verifying the correctness of the 1909 authentication data is selected by the Home Agent based on the value 1910 of the Source IP Address field of the Registration Request and the 1911 SPI of the Authentication extension. The Source IP Address will be 1912 the same as the Care-of Address field of the Registration Request 1913 (see Section 3.7.2.2) 1915 When this extension is applied to a Registration Reply message, the 1916 mobility security association for verifying the correctness of the 1917 authentication data is selected by the foreign agent based on the 1918 value of the Home Agent Address field of the Registration Reply. 1920 If the Care-of Address in the Registration Request is not in the 1921 Agent Advertisement, then the foreign agent MUST NOT append the 1922 Foreign-Home Authentication Extension when relaying the message to 1923 the home agent. Moreover, for a deregistration message (i.e., 1924 lifetime = 0), the foreign agent MUST NOT append the Foreign-Home 1925 Authentication Extension when relaying the message to the home agent. 1926 Consequently, when the HA receives a deregistration request that does 1927 not contain a Foreign-Home Authentication Extension it MUST NOT for 1928 this reason discard the request as part of security association 1929 processing. 1931 3.6. Mobile Node Considerations 1933 A mobile node MUST be configured (statically or dynamically) with a 1934 netmask and a mobility security association for each of its home 1935 agents. In addition, a mobile node MAY be configured with its home 1936 address, and the IP address of one or more of its home agents; 1937 otherwise, the mobile node MAY discover a home agent using the 1938 procedures described in Section 3.6.1.2. 1940 If the mobile node is not configured with a home address, it MAY use 1941 the Mobile Node NAI extension [2] to identify itself, and set the 1942 Home Address field of the Registration Request to 0.0.0.0. In this 1943 case, the mobile node MUST be able to assign its home address after 1944 extracting this information from the Registration Reply from the home 1945 agent. 1947 For each pending registration, the mobile node maintains the 1948 following information: 1950 o the link-layer address of the foreign agent to which the 1951 Registration Request was sent, if applicable, 1952 o the IP destination address of the Registration Request, 1953 o the care-of address used in the registration, 1954 o the Identification value sent in the registration, 1955 o the originally requested Lifetime, and 1956 o the remaining Lifetime of the pending registration. 1958 A mobile node SHOULD initiate a registration whenever it detects a 1959 change in its network connectivity. See Section 2.4.2 for methods by 1960 which mobile nodes MAY make such a determination. When it is away 1961 from home, the mobile node's Registration Request allows its home 1962 agent to create or modify a mobility binding for it. When it is at 1963 home, the mobile node's (de)Registration Request allows its home 1964 agent to delete any previous mobility binding(s) for it. A mobile 1965 node operates without the support of mobility functions when it is at 1966 home. 1968 There are other conditions under which the mobile node SHOULD 1969 (re)register with its foreign agent, such as when the mobile node 1970 detects that the foreign agent has rebooted (as specified in 1971 Section 2.4.4) and when the current registration's Lifetime is near 1972 expiration. 1974 In the absence of link-layer indications of changes in point of 1975 attachment, Agent Advertisements from new agents SHOULD NOT cause a 1976 mobile node to attempt a new registration, if its current 1977 registration has not expired and it is still also receiving Agent 1978 Advertisements from the foreign agent with which it is currently 1979 registered. In the absence of link-layer indications, a mobile node 1980 MUST NOT attempt to register more often than once per second. 1982 A mobile node MAY register with a different agent when transport- 1983 layer protocols indicate excessive retransmissions. A mobile node 1984 MUST NOT consider reception of an ICMP Redirect from a foreign agent 1985 that is currently providing service to it as reason to register with 1986 a new foreign agent. Within these constraints, the mobile node MAY 1987 register again at any time. 1989 Appendix D shows some examples of how the fields in registration 1990 messages would be set up in some typical registration scenarios. 1992 3.6.1. Sending Registration Requests 1994 The following sections specify details for the values the mobile node 1995 MUST supply in the fields of Registration Request messages. 1997 3.6.1.1. IP Fields 1999 This section provides the specific rules by which mobile nodes pick 2000 values for the IP header fields of a Registration Request. 2002 IP Source Address: 2004 o When registering on a foreign network with a co-located care-of 2005 address, the IP source address MUST be the care-of address. 2007 o Otherwise, if the mobile node does not have a home address, the IP 2008 source address MUST be 0.0.0.0. 2010 o In all other circumstances, the IP source address MUST be the 2011 mobile node's home address. 2013 IP Destination Address: 2015 o When the mobile node has discovered the agent with which it is 2016 registering, through some means (e.g., link-layer) that does not 2017 provide the IP address of the agent (the IP address of the agent 2018 is unknown to the mobile node), then the "All Mobility Agents" 2019 multicast address (224.0.0.11) MUST be used. In this case, the 2020 mobile node MUST use the agent's link-layer unicast address in 2021 order to deliver the datagram to the correct agent. 2023 o When registering with a foreign agent, the address of the agent as 2024 learned from the IP source address of the corresponding Agent 2025 Advertisement MUST be used. This MAY be an address which does not 2026 appear as an advertised care-of address in the Agent 2027 Advertisement. In addition, when transmitting this Registration 2028 Request message, the mobile node MUST use a link-layer destination 2029 address copied from the link-layer source address of the Agent 2030 Advertisement message in which it learned this foreign agent's IP 2031 address. 2033 o When the mobile node is registering directly with its home agent 2034 and knows the (unicast) IP address of its home agent, the 2035 destination address MUST be set to this address. 2037 o If the mobile node is registering directly with its home agent, 2038 but does not know the IP address of its home agent, the mobile 2039 node may use dynamic home agent address resolution to 2040 automatically determine the IP address of its home agent 2041 (Section 3.6.1.2). In this case, the IP destination address is 2042 set to the subnet-directed broadcast address of the mobile node's 2043 home network. This address MUST NOT be used as the destination IP 2044 address if the mobile node is registering via a foreign agent, 2045 although it MAY be used as the Home Agent address in the body of 2046 the Registration Request when registering via a foreign agent. 2048 IP Time to Live: 2050 o The IP TTL field MUST be set to 1 if the IP destination address is 2051 set to the "All Mobility Agents" multicast address as described 2052 above. Otherwise a suitable value should be chosen in accordance 2053 with standard IP practice [18]. 2055 3.6.1.2. Registration Request Fields 2057 This section provides specific rules by which mobile nodes pick 2058 values for the fields within the fixed portion of a Registration 2059 Request. 2061 A mobile node MAY set the 'S' bit in order to request that the home 2062 agent maintain prior mobility binding(s). Otherwise, the home agent 2063 deletes any previous binding(s) and replaces them with the new 2064 binding specified in the Registration Request. Multiple simultaneous 2065 mobility bindings are likely to be useful when a mobile node using at 2066 least one wireless network interface moves within wireless 2067 transmission range of more than one foreign agent. IP explicitly 2068 allows duplication of datagrams. When the home agent allows 2069 simultaneous bindings, it will tunnel a separate copy of each 2070 arriving datagram to each care-of address, and the mobile node will 2071 receive multiple copies of datagrams destined to it. 2073 The mobile node SHOULD set the 'D' bit if it is registering with a 2074 co-located care-of address. Otherwise, the 'D' bit MUST NOT be set. 2076 A mobile node MAY set the 'B' bit to request its home agent to 2077 forward to it, a copy of broadcast datagrams received by its home 2078 agent from the home network. The method used by the home agent to 2079 forward broadcast datagrams depends on the type of care-of address 2080 registered by the mobile node, as determined by the 'D' bit in the 2081 mobile node's Registration Request: 2083 o If the 'D' bit is set, then the mobile node has indicated that it 2084 will decapsulate any datagrams tunneled to this care-of address 2085 itself (the mobile node is using a co-located care-of address). 2086 In this case, to forward such a received broadcast datagram to the 2087 mobile node, the home agent MUST tunnel it to this care-of 2088 address. The mobile node de-tunnels the received datagram in the 2089 same way as any other datagram tunneled directly to it. 2091 o If the 'D' bit is NOT set, then the mobile node has indicated that 2092 it is using a foreign agent care-of address, and that the foreign 2093 agent will thus decapsulate arriving datagrams before forwarding 2094 them to the mobile node. In this case, to forward such a received 2095 broadcast datagram to the mobile node, the home agent MUST first 2096 encapsulate the broadcast datagram in a unicast datagram addressed 2097 to the mobile node's home address, and then MUST tunnel this 2098 resulting datagram to the mobile node's care-of address. 2100 When decapsulated by the foreign agent, the inner datagram will 2101 thus be a unicast IP datagram addressed to the mobile node, 2102 identifying to the foreign agent the intended destination of the 2103 encapsulated broadcast datagram, and will be delivered to the 2104 mobile node in the same way as any tunneled datagram arriving for 2105 the mobile node. The foreign agent MUST NOT decapsulate the 2106 encapsulated broadcast datagram and MUST NOT use a local network 2107 broadcast to transmit it to the mobile node. The mobile node thus 2108 MUST decapsulate the encapsulated broadcast datagram itself, and 2109 thus MUST NOT set the 'B' bit in its Registration Request in this 2110 case unless it is capable of decapsulating datagrams. 2112 The mobile node MAY request alternative forms of encapsulation by 2113 setting the 'M' bit and/or the 'G' bit, but only if the mobile node 2114 is decapsulating its own datagrams (the mobile node is using a co- 2115 located care-of address) or if its foreign agent has indicated 2116 support for these forms of encapsulation by setting the corresponding 2117 bits in the Mobility Agent Advertisement Extension of an Agent 2118 Advertisement received by the mobile node. Otherwise, the mobile 2119 node MUST NOT set these bits. 2121 The Lifetime field is chosen as follows: 2123 o If the mobile node is registering with a foreign agent, the 2124 Lifetime SHOULD NOT exceed the value in the Registration Lifetime 2125 field of the Agent Advertisement message received from the foreign 2126 agent. When the method by which the care-of address is learned 2127 does not include a Lifetime, the default ICMP Router Advertisement 2128 Lifetime (1800 seconds) MAY be used. 2130 o The mobile node MAY ask a home agent to delete a particular 2131 mobility binding, by sending a Registration Request with the 2132 care-of address for this binding, with the Lifetime field set to 2133 zero (Section 3.8.2). 2135 o Similarly, a Lifetime of zero is used when the mobile node 2136 deregisters all care-of addresses, such as upon returning home. 2138 The Home Address field MUST be set to the mobile node's home address, 2139 if this information is known. Otherwise, the Home Address MUST be 2140 set to zeroes. 2142 The Home Agent field MUST be set to the address of the mobile node's 2143 home agent, if the mobile node knows this address. Otherwise, the 2144 mobile node MAY use dynamic home agent address resolution to learn 2145 the address of its home agent. In this case, the mobile node MUST 2146 set the Home Agent field to the subnet-directed broadcast address of 2147 the mobile node's home network. Each home agent receiving such a 2148 Registration Request with a broadcast destination address MUST reject 2149 the mobile node's registration and SHOULD return a rejection 2150 Registration Reply indicating its unicast IP address for use by the 2151 mobile node in a future registration attempt. 2153 The Care-of Address field MUST be set to the value of the particular 2154 care-of address that the mobile node wishes to (de)register. In the 2155 special case in which a mobile node wishes to deregister all care-of 2156 addresses, it MUST set this field to its home address. 2158 The mobile node chooses the Identification field in accordance with 2159 the style of replay protection it uses with its home agent. This is 2160 part of the mobility security association the mobile node shares with 2161 its home agent. See Section 5.7 for the method by which the mobile 2162 node computes the Identification field. 2164 3.6.1.3. Extensions 2166 This section describes the ordering of any mandatory and any optional 2167 Extensions that a mobile node appends to a Registration Request. 2168 This ordering is REQUIRED: 2170 a. The IP header, followed by the UDP header, followed by the fixed- 2171 length portion of the Registration Request, followed by 2173 b. If present, any non-authentication Extensions expected to be used 2174 by the home agent or other authorizing agent (which may or may 2175 not also be useful to the foreign agent), followed by 2177 c. All authorization-enabling extensions (see Section 1.6), followed 2178 by 2180 d. If present, any non-authentication Extensions used only by the 2181 foreign agent, followed by 2183 e. The Mobile-Foreign Authentication Extension, if present. 2185 Note that items (a) and (c) MUST appear in every Registration Request 2186 sent by the mobile node. Items (b), (d), and (e) are optional. 2187 However, item (e) MUST be included when the mobile node and the 2188 foreign agent share a mobility security association. 2190 3.6.2. Receiving Registration Replies 2192 Registration Replies will be received by the mobile node in response 2193 to its Registration Requests. Registration Replies generally fall 2194 into three categories: 2196 o the registration was accepted, 2197 o the registration was denied by the foreign agent, or 2198 o the registration was denied by the home agent. 2200 The remainder of this section describes the Registration Reply 2201 handling by a mobile node in each of these three categories. 2203 3.6.2.1. Validity Checks 2205 Registration Replies with an invalid, non-zero UDP checksum MUST be 2206 silently discarded. 2208 In addition, the low-order 32 bits of the Identification field in the 2209 Registration Reply MUST be compared to the low-order 32 bits of the 2210 Identification field in the most recent Registration Request sent to 2211 the replying agent. If they do not match, the Reply MUST be silently 2212 discarded. 2214 Also, the Registration Reply MUST be checked for presence of an 2215 authorization-enabling extension. For all Registration Reply 2216 messages containing a Status Code indicating status from the Home 2217 Agent, the mobile node MUST check for the presence of an 2218 authorization-enabling extension, acting in accordance with the Code 2219 field in the Reply. The rules are as follows: 2221 a. If the mobile node and the foreign agent share a mobility 2222 security association, exactly one Mobile-Foreign Authentication 2223 Extension MUST be present in the Registration Reply, and the 2224 mobile node MUST check the Authenticator value in the Extension. 2225 If no Mobile-Foreign Authentication Extension is found, or if 2226 more than one Mobile-Foreign Authentication Extension is found, 2227 or if the Authenticator is invalid, the mobile node MUST silently 2228 discard the Reply and SHOULD log the event as a security 2229 exception. 2231 b. If the Code field indicates that service is denied by the home 2232 agent, or if the Code field indicates that the registration was 2233 accepted by the home agent, exactly one Mobile-Home 2234 Authentication Extension MUST be present in the Registration 2235 Reply, and the mobile node MUST check the Authenticator value in 2236 the Extension. If the Registration Reply was generated by the 2237 home agent but no Mobile-Home Authentication Extension is found, 2238 or if more than one Mobile-Home Authentication Extension is 2239 found, or if the Authenticator is invalid, the mobile node MUST 2240 silently discard the Reply and SHOULD log the event as a security 2241 exception. 2243 If the Code field indicates an authentication failure, either at the 2244 foreign agent or the home agent, then it is quite possible that any 2245 authenticators in the Registration Reply will also be in error. This 2246 could happen, for example, if the shared secret between the mobile 2247 node and home agent was erroneously configured. The mobile node 2248 SHOULD log such errors as security exceptions. 2250 3.6.2.2. Registration Request Accepted 2252 If the Code field indicates that the request has been accepted, the 2253 mobile node SHOULD configure its routing table appropriately for its 2254 current point of attachment (Section 4.2.1). 2256 If the mobile node is returning to its home network and that network 2257 is one which implements ARP, the mobile node MUST follow the 2258 procedures described in Section 4.6 with regard to ARP, proxy ARP, 2259 and gratuitous ARP. 2261 If the mobile node has registered on a foreign network, it SHOULD re- 2262 register before the expiration of the Lifetime of its registration. 2263 As described in Section 3.6, for each pending Registration Request, 2264 the mobile node MUST maintain the remaining lifetime of this pending 2265 registration, as well as the original Lifetime from the Registration 2266 Request. When the mobile node receives a valid Registration Reply, 2267 the mobile node MUST decrease its view of the remaining lifetime of 2268 the registration by the amount by which the home agent decreased the 2269 originally requested Lifetime. This procedure is equivalent to the 2270 mobile node starting a timer for the granted Lifetime at the time it 2271 sent the Registration Request, even though the granted Lifetime is 2272 not known to the mobile node until the Registration Reply is 2273 received. Since the Registration Request is certainly sent before 2274 the home agent begins timing the registration Lifetime (also based on 2275 the granted Lifetime), this procedure ensures that the mobile node 2276 will re-register before the home agent expires and deletes the 2277 registration, in spite of possibly non-negligible transmission delays 2278 for the original Registration Request and Reply that started the 2279 timing of the Lifetime at the mobile node and its home agent. 2281 3.6.2.3. Registration Request Denied 2283 If the Code field indicates that service is being denied, the mobile 2284 node SHOULD log the error. In certain cases the mobile node may be 2285 able to "repair" the error. These include: 2287 Code 69: (Denied by foreign agent, Lifetime too long) 2289 In this case, the Lifetime field in the Registration Reply will 2290 contain the maximum Lifetime value which that foreign agent is 2291 willing to accept in any Registration Request. The mobile node 2292 MAY attempt to register with this same agent, using a Lifetime in 2293 the Registration Request that MUST be less than or equal to the 2294 value specified in the Reply. 2296 Code 133: (Denied by home agent, Identification mismatch) 2298 In this case, the Identification field in the Registration Reply 2299 will contain a value that allows the mobile node to synchronize 2300 with the home agent, based upon the style of replay protection in 2301 effect (Section 5.7). The mobile node MUST adjust the parameters 2302 it uses to compute the Identification field based upon the 2303 information in the Registration Reply, before issuing any future 2304 Registration Requests. 2306 Code 136: (Denied by home agent, Unknown home agent address) 2308 This code is returned by a home agent when the mobile node is 2309 performing dynamic home agent address resolution as described in 2310 Section 3.6.1.1 and Section 3.6.1.2. In this case, the Home Agent 2311 field within the Reply will contain the unicast IP address of the 2312 home agent returning the Reply. The mobile node MAY then attempt 2313 to register with this home agent in future Registration Requests. 2314 In addition, the mobile node SHOULD adjust the parameters it uses 2315 to compute the Identification field based upon the corresponding 2316 field in the Registration Reply, before issuing any future 2317 Registration Requests. 2319 3.6.3. Registration Retransmission 2321 When no Registration Reply has been received within a reasonable 2322 time, another Registration Request MAY be transmitted. When 2323 timestamps are used, a new registration Identification is chosen for 2324 each retransmission; thus it counts as a new registration. When 2325 nonces are used, the unanswered Request is retransmitted unchanged; 2326 thus the retransmission does not count as a new registration 2327 (Section 5.7). In this way a retransmission will not require the 2328 home agent to resynchronize with the mobile node by issuing another 2329 nonce in the case in which the original Registration Request (rather 2330 than its Registration Reply) was lost by the network. 2332 The maximum time until a new Registration Request is sent SHOULD be 2333 no greater than the requested Lifetime of the Registration Request. 2334 The minimum value SHOULD be large enough to account for the size of 2335 the messages, twice the round trip time for transmission to the home 2336 agent, and at least an additional 100 milliseconds to allow for 2337 processing the messages before responding. The round trip time for 2338 transmission to the home agent will be at least as large as the time 2339 required to transmit the messages at the link speed of the mobile 2340 node's current point of attachment. Some circuits add another 200 2341 milliseconds of satellite delay in the total round trip time to the 2342 home agent. The minimum time between Registration Requests MUST NOT 2343 be less than 1 second. Each successive retransmission timeout period 2344 SHOULD be at least twice the previous period, as long as that is less 2345 than the maximum as specified above. 2347 3.7. Foreign Agent Considerations 2349 The foreign agent plays a mostly passive role in Mobile IP 2350 registration. It relays Registration Requests between mobile nodes 2351 and home agents, and, when it provides the care-of address, 2352 decapsulates datagrams for delivery to the mobile node. It SHOULD 2353 also send periodic Agent Advertisement messages to advertise its 2354 presence as described in Section 2.3, if not detectable by link-layer 2355 means. 2357 A foreign agent MUST NOT transmit a Registration Request except when 2358 relaying a Registration Request received from a mobile node, to the 2359 mobile node's home agent. A foreign agent MUST NOT transmit a 2360 Registration Reply except when relaying a Registration Reply received 2361 from a mobile node's home agent, or when replying to a Registration 2362 Request received from a mobile node in the case in which the foreign 2363 agent is denying service to the mobile node. In particular, a 2364 foreign agent MUST NOT generate a Registration Request or Reply 2365 because a mobile node's registration Lifetime has expired. A foreign 2366 agent also MUST NOT originate a Registration Request message that 2367 asks for deregistration of a mobile node; however, it MUST relay 2368 well-formed (de)Registration Requests originated by a mobile node. 2370 3.7.1. Configuration and Registration Tables 2372 Each foreign agent MUST be configured with a care-of address. In 2373 addition, for each pending or current registration the foreign agent 2374 MUST maintain a visitor list entry containing the following 2375 information obtained from the mobile node's Registration Request: 2377 o the link-layer source address of the mobile node 2378 o the IP Source Address (the mobile node's Home Address) or its co- 2379 located care-of address (see description of the 'R' bit in 2380 Section 2.1.1) 2381 o the IP Destination Address (as specified in Section 3.6.1.1 2382 o the UDP Source Port 2383 o the Home Agent address 2384 o the Identification field 2385 o the requested registration Lifetime, and 2386 o the remaining Lifetime of the pending or current registration. 2388 If there is an NAI extension in the Registration Request message 2389 (often, for example, when the mobile node's Home Address is zero), 2390 then the foreign agent MUST follow the procedures specified in RFC 2391 2794 [2]. In particular, if the foreign agent cannot manage pending 2392 registration request records with such a zero Home Address for the 2393 mobile node, the foreign agent MUST return a Registration Reply with 2394 Code indicating NONZERO_HOMEADDR_REQD (see [2]). 2396 The foreign agent MAY configure a maximum number of pending 2397 registrations that it is willing to maintain (typically 5). 2398 Additional registrations SHOULD then be rejected by the foreign agent 2399 with code 66. The foreign agent MAY delete any pending Registration 2400 Request after the request has been pending for more than 7 seconds; 2401 in this case, the foreign agent SHOULD reject the Request with code 2402 78 (registration timeout). 2404 As with any node on the Internet, a foreign agent MAY also share 2405 mobility security associations with any other nodes. When relaying a 2406 Registration Request from a mobile node to its home agent, if the 2407 foreign agent shares a mobility security association with the home 2408 agent, it MUST add a Foreign-Home Authentication Extension to the 2409 Request. In this case, when the Registration Reply has nonzero 2410 lifetime, the foreign agent MUST check the required Foreign-Home 2411 Authentication Extension in the Registration Reply from the home 2412 agent (Section 3.3 and Section 3.4). Similarly, when receiving a 2413 Registration Request from a mobile node, if the foreign agent shares 2414 a mobility security association with the mobile node, it MUST check 2415 the required Mobile-Foreign Authentication Extension in the Request 2416 and MUST add a Mobile-Foreign Authentication Extension to the 2417 Registration Reply to the mobile node. 2419 3.7.2. Receiving Registration Requests 2421 If the foreign agent accepts a Registration Request from a mobile 2422 node, it checks to make sure that the indicated home agent address 2423 does not belong to any network interface of the foreign agent. If 2424 not, the foreign agent then MUST relay the Request to the indicated 2425 home agent. Otherwise, if the foreign agent denies the Request, it 2426 MUST send a Registration Reply to the mobile node with an appropriate 2427 denial Code, except in cases where the foreign agent would be 2428 required to send out more than one such denial per second to the same 2429 mobile node. The following sections describe this behavior in more 2430 detail. 2432 If the foreign agent has configured one of its network interfaces 2433 with the IP address specified by the mobile node as its home agent 2434 address, the foreign agent MUST NOT forward the request again. If 2435 the foreign agent serves the mobile node as a home agent, the foreign 2436 agent follows the procedures specified in Section 3.8.2. Otherwise, 2437 if the foreign agent does not serve the mobile node as a home agent, 2438 the foreign agent rejects the Registration Request with code TBD-IANA 2439 (Invalid Home Agent Address). 2441 If a foreign agent receives a Registration Request from a mobile node 2442 in its visitor list, the existing visitor list entry for the mobile 2443 node SHOULD NOT be deleted or modified until the foreign agent 2444 receives a valid Registration Reply from the home agent with a Code 2445 indicating success. The foreign agent MUST record the new pending 2446 Request as a separate part of the existing visitor list entry for the 2447 mobile node. If the Registration Request requests deregistration, 2448 the existing visitor list entry for the mobile node SHOULD NOT be 2449 deleted until the foreign agent has received a successful 2450 Registration Reply. If the Registration Reply indicates that the 2451 Request (for registration or deregistration) was denied by the home 2452 agent, the existing visitor list entry for the mobile node MUST NOT 2453 be modified as a result of receiving the Registration Reply. 2455 3.7.2.1. Validity Checks 2457 Registration Requests with an invalid, non-zero UDP checksum MUST be 2458 silently discarded. Requests with non-zero bits in reserved fields 2459 MUST be rejected with code 70 (poorly formed request). Requests with 2460 the 'D' bit set to 0, nonzero lifetime, and specifying a care-of 2461 address not offered by the foreign agent, MUST be rejected with code 2462 77 (invalid care-of address). 2464 Also, the authentication in the Registration Request MUST be checked. 2465 If the foreign agent and the mobile node share a mobility security 2466 association, exactly one Mobile-Foreign Authentication Extension MUST 2467 be present in the Registration Request, and the foreign agent MUST 2468 check the Authenticator value in the Extension. If no Mobile-Foreign 2469 Authentication Extension is found, or if more than one Mobile-Foreign 2470 Authentication Extension is found, or if the Authenticator is 2471 invalid, the foreign agent MUST silently discard the Request and 2472 SHOULD log the event as a security exception. The foreign agent also 2473 SHOULD send a Registration Reply to the mobile node with Code 67. 2475 3.7.2.2. Forwarding a Valid Request to the Home Agent 2477 If the foreign agent accepts the mobile node's Registration Request, 2478 it MUST relay the Request to the mobile node's home agent as 2479 specified in the Home Agent field of the Registration Request. The 2480 foreign agent MUST NOT modify any of the fields beginning with the 2481 fixed portion of the Registration Request up through and including 2482 the Mobile-Home Authentication Extension or other authentication 2483 extension supplied by the mobile node as an authorization-enabling 2484 extension for the home agent. Otherwise, an authentication failure 2485 is very likely to occur at the home agent. In addition, the foreign 2486 agent proceeds as follows: 2488 o It MUST process and remove any extensions which do not precede any 2489 authorization-enabling extension. 2490 o It MAY append any of its own non-authentication Extensions of 2491 relevance to the home agent, if applicable, and 2492 o If the foreign agent shares a mobility security association with 2493 the home agent, and the Request has lifetime != 0, then it MUST 2494 append the Foreign-Home Authentication Extension, 2496 Specific fields within the IP header and the UDP header of the 2497 relayed Registration Request MUST be set as follows: 2499 IP Source Address 2501 The care-of address offered by the foreign agent for the mobile 2502 node sending the Registration Request. 2504 IP Destination Address 2506 Copied from the Home Agent field within the Registration Request. 2508 UDP Source Port 2510 variable 2512 UDP Destination Port 2514 434 2516 After forwarding a valid Registration Request to the home agent, the 2517 foreign agent MUST begin timing the remaining lifetime of the pending 2518 registration based on the Lifetime in the Registration Request. If 2519 this lifetime expires before receiving a valid Registration Reply, 2520 the foreign agent MUST delete its visitor list entry for this pending 2521 registration. 2523 3.7.2.3. Denying Invalid Requests 2525 If the foreign agent denies the mobile node's Registration Request 2526 for any reason, it SHOULD send the mobile node a Registration Reply 2527 with a suitable denial Code. In such a case, the Home Address, Home 2528 Agent, and Identification fields within the Registration Reply are 2529 copied from the corresponding fields of the Registration Request. 2531 If the Reserved field is nonzero, the foreign agent MUST deny the 2532 Request and SHOULD return a Registration Reply with status code 70 to 2533 the mobile node. If the Request is being denied because the 2534 requested Lifetime is too long, the foreign agent sets the Lifetime 2535 in the Reply to the maximum Lifetime value it is willing to accept in 2536 any Registration Request, and sets the Code field to 69. Otherwise, 2537 the Lifetime SHOULD be copied from the Lifetime field in the Request. 2539 Specific fields within the IP header and the UDP header of the 2540 Registration Reply MUST be set as follows: 2542 IP Source Address 2544 Copied from the IP Destination Address of Registration Request, 2545 unless the "All Agents Multicast" address was used. In this case, 2546 the foreign agent's address (on the interface from which the 2547 message will be sent) MUST be used. 2549 IP Destination Address 2551 If the Registration Reply is generated by the Foreign Agent in 2552 order to reject a mobile node's Registration Request, and the 2553 Registration Request contains a Home Address which is not 0.0.0.0, 2554 then the IP Destination Address is copied from the Home Address 2555 field of the Registration Request. Otherwise, if the Registration 2556 Reply is received from the Home Agent, and contains a Home Address 2557 which is not 0.0.0.0, then the IP Destination Address is copied 2558 from the Home Address field of the Registration Reply. Otherwise, 2559 the IP Destination Address of the Registration Reply is set to be 2560 255.255.255.255. 2562 UDP Source Port 2564 434 2566 UDP Destination Port 2568 Copied from the UDP Source Port of the Registration Request. 2570 3.7.3. Receiving Registration Replies 2572 The foreign agent updates its visitor list when it receives a valid 2573 Registration Reply from a home agent. It then relays the 2574 Registration Reply to the mobile node. The following sections 2575 describe this behavior in more detail. 2577 If upon relaying a Registration Request to a home agent, the foreign 2578 agent receives an ICMP error message instead of a Registration Reply, 2579 then the foreign agent SHOULD send to the mobile node a Registration 2580 Reply with an appropriate "Home Agent Unreachable" failure Code 2581 (within the range 80-95, inclusive). See Section 3.7.2.3 for details 2582 on building the Registration Reply. 2584 3.7.3.1. Validity Checks 2586 Registration Replies with an invalid, non-zero UDP checksum MUST be 2587 silently discarded. 2589 When a foreign agent receives a Registration Reply message, it MUST 2590 search its visitor list for a pending Registration Request with the 2591 same mobile node home address as indicated in the Reply. If there 2592 are multiple entries with the same home address, and if the 2593 Registration Reply has the Mobile Node NAI extension [2], the foreign 2594 agent MUST use the NAI to disambiguate the pending Registration 2595 Requests with the same home address. If no matching pending Request 2596 is found, and if the Registration Reply does not correspond with any 2597 pending Registration Request with a zero mobile node home address 2598 (see Section 3.7.1), the foreign agent MUST silently discard the 2599 Reply. The foreign agent MUST also silently discard the Reply if the 2600 low-order 32 bits of the Identification field in the Reply do not 2601 match those in the Request. 2603 Also, the authentication in the Registration Reply MUST be checked. 2604 If the foreign agent and the home agent share a mobility security 2605 association, exactly one Foreign-Home Authentication Extension MUST 2606 be present in the Registration Reply, and the foreign agent MUST 2607 check the Authenticator value in the Extension. If no Foreign-Home 2608 Authentication Extension is found, or if more than one Foreign-Home 2609 Authentication Extension is found, or if the Authenticator is 2610 invalid, the foreign agent MUST silently discard the Reply and SHOULD 2611 log the event as a security exception. The foreign agent also MUST 2612 reject the mobile node's registration and SHOULD send a Registration 2613 Reply to the mobile node with Code 68. 2615 3.7.3.2. Forwarding Replies to the Mobile Node 2617 A Registration Reply which satisfies the validity checks of 2618 Section 3.8.2.1 is relayed to the mobile node. The foreign agent 2619 MUST also update its visitor list entry for the mobile node to 2620 reflect the results of the Registration Request, as indicated by the 2621 Code field in the Reply. If the Code indicates that the home agent 2622 has accepted the registration and the Lifetime field is nonzero, the 2623 foreign agent SHOULD set the Lifetime in the visitor list entry to 2624 the minimum of the following two values: 2626 o the value specified in the Lifetime field of the Registration 2627 Reply, and 2629 o the foreign agent's own maximum value for allowable registration 2630 lifetime. 2632 If, instead, the Code indicates that the Lifetime field is zero, the 2633 foreign agent MUST delete its visitor list entry for the mobile node. 2634 Finally, if the Code indicates that the registration was denied by 2635 the home agent, the foreign agent MUST delete its pending 2636 registration list entry, but not its visitor list entry, for the 2637 mobile node. 2639 The foreign agent MUST NOT modify any of the fields beginning with 2640 the fixed portion of the Registration Reply up through and including 2641 the Mobile-Home Authentication Extension. Otherwise, an 2642 authentication failure is very likely to occur at the mobile node. 2643 In addition, the foreign agent SHOULD perform the following 2644 additional procedures: 2646 o It MUST process and remove any Extensions which are not covered by 2647 any authorization-enabling extension. 2648 o It MAY append its own non-authentication Extensions that supply 2649 information to the mobile node, if applicable, and 2650 o It MUST append the Mobile-Foreign Authentication Extension, if the 2651 foreign agent shares a mobility security association with the 2652 mobile node. 2654 Specific fields within the IP header and the UDP header of the 2655 relayed Registration Reply are set according to the same rules 2656 specified in Section 3.7.2.3. 2658 After forwarding a valid Registration Reply to the mobile node, the 2659 foreign agent MUST update its visitor list entry for this 2660 registration as follows. If the Registration Reply indicates that 2661 the registration was accepted by the home agent, the foreign agent 2662 resets its timer of the lifetime of the registration to the Lifetime 2663 granted in the Registration Reply; unlike the mobile node's timing of 2664 the registration lifetime as described in Section 3.6.2.2, the 2665 foreign agent considers this lifetime to begin when it forwards the 2666 Registration Reply message, ensuring that the foreign agent will not 2667 expire the registration before the mobile node does. On the other 2668 hand, if the Registration Reply indicates that the registration was 2669 rejected by the home agent, the foreign agent deletes its visitor 2670 list entry for this attempted registration. 2672 3.8. Home Agent Considerations 2674 Home agents play a reactive role in the registration process. The 2675 home agent receives Registration Requests from the mobile node 2676 (perhaps relayed by a foreign agent), updates its record of the 2677 mobility bindings for this mobile node, and issues a suitable 2678 Registration Reply in response to each. 2680 A home agent MUST NOT transmit a Registration Reply except when 2681 replying to a Registration Request received from a mobile node. In 2682 particular, the home agent MUST NOT generate a Registration Reply to 2683 indicate that the Lifetime has expired. 2685 3.8.1. Configuration and Registration Tables 2687 Each home agent MUST be configured with an IP address and with the 2688 prefix size for the home network. The home agent MUST be configured 2689 with the mobility security association of each authorized mobile node 2690 that it is serving as a home agent. 2692 When the home agent accepts a valid Registration Request from a 2693 mobile node that it serves as a home agent, the home agent MUST 2694 create or modify the entry for this mobile node in its mobility 2695 binding list containing: 2697 o the mobile node's home address 2698 o the mobile node's care-of address 2699 o the Identification field from the Registration Reply 2700 o the remaining Lifetime of the registration 2702 The home agent MAY optionally offer the capability to dynamically 2703 associate a home address to a mobile node upon receiving a 2704 Registration Request from that mobile node. The method by which a 2705 home address is allocated to the mobile node is beyond the scope of 2706 this document, but see [2]. After the home agent makes the 2707 association of the home address to the mobile node, the home agent 2708 MUST put that home address into the Home Address field of the 2709 Registration Reply. 2711 The home agent MAY also maintain mobility security associations with 2712 various foreign agents. When receiving a Registration Request from a 2713 foreign agent, if the home agent shares a mobility security 2714 association with the foreign agent, the home agent MUST check the 2715 Authenticator in the required Foreign-Home Authentication Extension 2716 in the message, based on this mobility security association, unless 2717 the Lifetime field equals 0. When processing a Registration Request 2718 with Lifetime=0, the HA MAY skip checking for the presence and 2719 validity of a Foreign-Home Authentication Extension. Similarly, when 2720 sending a Registration Reply to a foreign agent, if the home agent 2721 shares a mobility security association with the foreign agent, the 2722 home agent MUST include a Foreign-Home Authentication Extension in 2723 the message, based on this mobility security association. 2725 3.8.2. Receiving Registration Requests 2727 If the home agent accepts an incoming Registration Request, it MUST 2728 update its record of the the mobile node's mobility binding(s) and 2729 SHOULD send a Registration Reply with a suitable Code. Otherwise 2730 (the home agent has denied the Request), it SHOULD in most cases send 2731 a Registration Reply with an appropriate Code specifying the reason 2732 the Request was denied. The following sections describe this 2733 behavior in more detail. If the home agent does not support 2734 broadcasts (see Section 4.3), it MUST ignore the 'B' bit (as opposed 2735 to rejecting the Registration Request). 2737 3.8.2.1. Validity Checks 2739 Registration Requests with an invalid, non-zero UDP checksum MUST be 2740 silently discarded by the home agent. 2742 The authentication in the Registration Request MUST be checked. This 2743 involves the following operations: 2745 a. The home agent MUST check for the presence of at least one 2746 authorization-enabling extension, and ensure that all indicated 2747 authentications are carried out. At least one authorization- 2748 enabling extension MUST be present in the Registration Request; 2749 and the home agent MUST either check the Authenticator value in 2750 the extension or verify that the authenticator value has been 2751 checked by another agent with which it has a security 2752 association. 2754 If the home agent receives a Registration Request from a Mobile 2755 Node with which it does not have any security association, the 2756 home agent MUST silently discard the Registration Request. 2758 If the home agent receives a Registration Request without any 2759 authorization-enabling extension, the home agent MUST silently 2760 discard the Registration Request. 2762 If the Authenticator is invalid, the home agent MUST reject the 2763 mobile node's registration. Further action to be taken in this 2764 case depends upon whether the Request has a valid Foreign-Home 2765 authentication extension (as follows): 2767 * If there is a valid Foreign-Home authentication extension, the 2768 home agent MUST send a Registration Reply with Code 131. 2770 * Otherwise, if there is no Foreign-Home security association, 2771 the home agent MAY send a Registration Reply with Code 131. 2772 If the home agent sends a Registration Reply, it MUST contain 2773 a valid Mobile-Home Authentication Extension. In constructing 2774 the Reply, the home agent SHOULD choose a security association 2775 that is likely to exist in the mobile node; for example, this 2776 may be an older security association or one with a longer 2777 lifetime than the one that was attempted to be used by the 2778 mobile node in its Request. Deployments should take care when 2779 updating security associations to ensure that there is at 2780 least one common security association shared between the 2781 mobile node and home agent. In any case of a failed 2782 Authenticator, the home agent MUST then discard the Request 2783 without further processing and SHOULD log the error as a 2784 security exception. 2786 b. The home agent MUST check that the registration Identification 2787 field is correct using the context selected by the SPI within the 2788 authorization-enabling extension that the home agent used to 2789 authenticate the Mobile Node's Registration Request. See 2790 Section 5.7 for a description of how this is performed. If 2791 incorrect, the home agent MUST reject the Request and SHOULD send 2792 a Registration Reply to the mobile node with Code 133, including 2793 an Identification field computed in accordance with the rules 2794 specified in Section 5.7. The home agent MUST do no further 2795 processing with such a Request, though it SHOULD log the error as 2796 a security exception. 2798 c. If the home agent shares a mobility security association with the 2799 foreign agent, and this is a registration request (has non-zero 2800 lifetime), the home agent MUST check for the presence of a valid 2801 Foreign-Home Authentication Extension. Exactly one Foreign-Home 2802 Authentication Extension MUST be present in the Registration 2803 Request in this case, and the home agent MUST check the 2804 Authenticator value in the Extension. If no Foreign-Home 2805 Authentication Extension is found, or if more than one Foreign- 2806 Home Authentication Extension is found, or if the Authenticator 2807 is invalid, the home agent MUST reject the mobile node's 2808 registration and SHOULD send a Registration Reply to the mobile 2809 node with Code 132. The home agent MUST then discard the Request 2810 and SHOULD log the error as a security exception. 2812 d. If the home agent and the foreign agent do not share a mobility 2813 security association, and the Registration contains a Foreign- 2814 Home Authentication Extension, the home agent MUST discard the 2815 Request and SHOULD log the error as a security exception. 2817 In addition to checking the authentication in the Registration 2818 Request, home agents MUST deny Registration Requests that are sent to 2819 the subnet-directed broadcast address of the home network (as opposed 2820 to being unicast to the home agent). The home agent MUST discard the 2821 Request and SHOULD returning a Registration Reply with a Code of 136. 2822 In this case, the Registration Reply will contain the home agent's 2823 unicast address, so that the mobile node can re-issue the 2824 Registration Request with the correct home agent address. 2826 Note that some routers change the IP destination address of a 2827 datagram from a subnet-directed broadcast address to 255.255.255.255 2828 before injecting it into the destination subnet. In this case, home 2829 agents that attempt to pick up dynamic home agent discovery requests 2830 by binding a socket explicitly to the subnet-directed broadcast 2831 address will not see such packets. Home agent implementors should be 2832 prepared for both the subnet-directed broadcast address and 2833 255.255.255.255 if they wish to support dynamic home agent discovery. 2835 3.8.2.2. Accepting a Valid Request 2837 If the Registration Request satisfies the validity checks in 2838 Section 3.8.2.1, and the home agent is able to accommodate the 2839 Request, the home agent MUST update its mobility binding list for the 2840 requesting mobile node and MUST return a Registration Reply to the 2841 mobile node. In this case, the Reply Code will be either 0 if the 2842 home agent supports simultaneous mobility bindings, or 1 if it does 2843 not. See Section 3.8.3 for details on building the Registration 2844 Reply message. 2846 The home agent updates its record of the mobile node's mobility 2847 bindings as follows, based on the fields in the Registration Request: 2849 o If the Lifetime is zero and the Care-of Address equals the mobile 2850 node's home address, the home agent deletes all of the entries in 2851 the mobility binding list for the requesting mobile node. This is 2852 how a mobile node requests that its home agent cease providing 2853 mobility services. 2855 o If the Lifetime is zero and the Care-of Address does not equal the 2856 mobile node's home address, the home agent deletes only the entry 2857 containing the specified Care-of Address from the mobility binding 2858 list for the requesting mobile node. Any other active entries 2859 containing other care-of addresses will remain active. 2861 o If the Lifetime is nonzero, the home agent adds an entry 2862 containing the requested Care-of Address to the mobility binding 2863 list for the mobile node. If the 'S' bit is set and the home 2864 agent supports simultaneous mobility bindings, the previous 2865 mobility binding entries are retained. Otherwise, the home agent 2866 removes all previous entries in the mobility binding list for the 2867 mobile node. 2869 In all cases, the home agent MUST send a Registration Reply to the 2870 source of the Registration Request, which might indeed be a different 2871 foreign agent than that whose care-of address is being 2872 (de)registered. If the home agent shares a mobility security 2873 association with the foreign agent whose care-of address is being 2874 deregistered, and that foreign agent is different from the one which 2875 relayed the Registration Request, the home agent MAY additionally 2876 send a Registration Reply to the foreign agent whose care-of address 2877 is being deregistered. The home agent MUST NOT send such a Reply if 2878 it does not share a mobility security association with the foreign 2879 agent. If no Reply is sent, the foreign agent's visitor list will 2880 expire naturally when the original Lifetime expires. 2882 When a foreign agent relays a deregistration message containing a 2883 care-of address that it does not own, it MUST NOT add a Foreign-Home 2884 Authentication Extension to that deregistration. See Section 3.5.4 2885 for more details. 2887 The home agent MUST NOT increase the Lifetime above that specified by 2888 the mobile node in the Registration Request. However, it is not an 2889 error for the mobile node to request a Lifetime longer than the home 2890 agent is willing to accept. In this case, the home agent simply 2891 reduces the Lifetime to a permissible value and returns this value in 2892 the Registration Reply. The Lifetime value in the Registration Reply 2893 informs the mobile node of the granted lifetime of the registration, 2894 indicating when it SHOULD re-register in order to maintain continued 2895 service. After the expiration of this registration lifetime, the 2896 home agent MUST delete its entry for this registration in its 2897 mobility binding list. 2899 If the Registration Request duplicates an accepted current 2900 Registration Request, the new Lifetime MUST NOT extend beyond the 2901 Lifetime originally granted. A Registration Request is a duplicate 2902 if the home address, care-of address, and Identification fields all 2903 equal those of an accepted current registration. 2905 In addition, if the home network implements ARP [16], and the 2906 Registration Request asks the home agent to create a mobility binding 2907 for a mobile node which previously had no binding (the mobile node 2908 was previously assumed to be at home), then the home agent MUST 2909 follow the procedures described in Section 4.6 with regard to ARP, 2910 proxy ARP, and gratuitous ARP. If the mobile node already had a 2911 previous mobility binding, the home agent MUST continue to follow the 2912 rules for proxy ARP described in Section 4.6. 2914 3.8.2.3. Denying an Invalid Request 2916 If the Registration Request does not satisfy all of the validity 2917 checks in Section 3.8.2.1, or the home agent is unable to accommodate 2918 the Request, the home agent SHOULD return a Registration Reply to the 2919 mobile node with a Code that indicates the reason for the error. If 2920 a foreign agent was involved in relaying the Request, this allows the 2921 foreign agent to delete its pending visitor list entry. Also, this 2922 informs the mobile node of the reason for the error such that it may 2923 attempt to fix the error and issue another Request. 2925 This section lists a number of reasons the home agent might reject a 2926 Request, and provides the Code value it should use in each instance. 2927 See Section 3.8.3 for additional details on building the Registration 2928 Reply message. 2930 Many reasons for rejecting a registration are administrative in 2931 nature. For example, a home agent can limit the number of 2932 simultaneous registrations for a mobile node, by rejecting any 2933 registrations that would cause its limit to be exceeded, and 2934 returning a Registration Reply with error code 135. Similarly, a 2935 home agent may refuse to grant service to mobile nodes which have 2936 entered unauthorized service areas by returning a Registration Reply 2937 with a Code of 129. 2939 Requests with non-zero bits in reserved fields MUST be rejected with 2940 code 134 (poorly formed request). 2942 3.8.3. Sending Registration Replies 2944 If the home agent accepts a Registration Request, it then MUST update 2945 its record of the mobile node's mobility binding(s) and SHOULD send a 2946 Registration Reply with a suitable Code. Otherwise (the home agent 2947 has denied the Request), it SHOULD in most cases send a Registration 2948 Reply with an appropriate Code specifying the reason the Request was 2949 denied. The following sections provide additional detail for the 2950 values the home agent MUST supply in the fields of Registration Reply 2951 messages. 2953 3.8.3.1. IP/UDP Fields 2955 This section provides the specific rules by which home agents pick 2956 values for the IP and UDP header fields of a Registration Reply. 2958 IP Source Address 2960 Copied from the IP Destination Address of Registration Request, 2961 unless a multicast or broadcast address was used. If the IP 2962 Destination Address of the Registration Request was a broadcast or 2963 multicast address, the IP Source Address of the Registration Reply 2964 MUST be set to the home agent's (unicast) IP address. 2966 IP Destination Address 2968 Copied from the IP Source Address of the Registration Request. 2970 UDP Source Port 2972 Copied from the UDP Destination Port of the Registration Request. 2974 UDP Destination Port 2976 Copied from the UDP Source Port of the Registration Request. 2978 When sending a Registration Reply in response to a Registration 2979 Request that requested deregistration of the mobile node (the 2980 Lifetime is zero and the Care-of Address equals the mobile node's 2981 home address) and in which the IP Source Address was also set to the 2982 mobile node's home address (this is the normal method used by a 2983 mobile node to deregister when it returns to its home network), the 2984 IP Destination Address in the Registration Reply will be set to the 2985 mobile node's home address, as copied from the IP Source Address of 2986 the Request. 2988 In this case, when transmitting the Registration Reply, the home 2989 agent MUST transmit the Reply directly onto the home network as if 2990 the mobile node were at home, bypassing any mobility binding list 2991 entry that may still exist at the home agent for the destination 2992 mobile node. In particular, for a mobile node returning home after 2993 being registered with a care-of address, if the mobile node's new 2994 Registration Request is not accepted by the home agent, the mobility 2995 binding list entry for the mobile node will still indicate that 2996 datagrams addressed to the mobile node should be tunneled to the 2997 mobile node's registered care-of address; when sending the 2998 Registration Reply indicating the rejection of this Request, this 2999 existing binding list entry MUST be ignored, and the home agent MUST 3000 transmit this Reply as if the mobile node were at home. 3002 3.8.3.2. Registration Reply Fields 3004 This section provides the specific rules by which home agents pick 3005 values for the fields within the fixed portion of a Registration 3006 Reply. 3008 The Code field of the Registration Reply is chosen in accordance with 3009 the rules specified in the previous sections. When replying to an 3010 accepted registration, a home agent SHOULD respond with Code 1 if it 3011 does not support simultaneous registrations. 3013 The Lifetime field MUST be copied from the corresponding field in the 3014 Registration Request, unless the requested value is greater than the 3015 maximum length of time the home agent is willing to provide the 3016 requested service. In such a case, the Lifetime MUST be set to the 3017 length of time that service will actually be provided by the home 3018 agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed 3019 by the home agent (for this mobile node and care-of address). 3021 If the Home Address field of the Registration Request is nonzero, it 3022 MUST be copied into the Home Address field of the Registration Reply 3023 message. If the Home Agent cannot support the specified nonzero 3024 unicast address in the Home Address field of the Registration 3025 Request, then the Home Agent MUST reject the Registration Request 3026 with an error code of 129. 3028 Otherwise, if the Home Address field of the Registration Request is 3029 zero as specified in Section 3.6, the home agent SHOULD arrange for 3030 the selection of a home address for the mobile node, and insert the 3031 selected address into the Home Address field of the Registration 3032 Reply message. See [2] for further relevant details in the case 3033 where mobile nodes identify themselves using an NAI instead of their 3034 IP home address. 3036 If the Home Agent field in the Registration Request contains a 3037 unicast address of this home agent, then that field MUST be copied 3038 into the Home Agent field of the Registration Reply. Otherwise, the 3039 home agent MUST set the Home Agent field in the Registration Reply to 3040 its unicast address. In this latter case, the home agent MUST reject 3041 the registration with a suitable code (e.g., Code 136) to prevent the 3042 mobile node from possibly being simultaneously registered with two or 3043 more home agents. 3045 3.8.3.3. Extensions 3047 This section describes the ordering of any required and any optional 3048 Mobile IP Extensions that a home agent appends to a Registration 3049 Reply. The following ordering MUST be followed: 3051 a. The IP header, followed by the UDP header, followed by the fixed- 3052 length portion of the Registration Reply, 3054 b. If present, any non-authentication Extensions used by the mobile 3055 node (which may or may not also be used by the foreign agent), 3057 c. The Mobile-Home Authentication Extension, 3059 d. If present, any non-authentication Extensions used only by the 3060 foreign agent, and 3062 e. The Foreign-Home Authentication Extension, if present. 3064 Note that items (a) and (c) MUST appear in every Registration Reply 3065 sent by the home agent. Items (b), (d), and (e) are optional. 3066 However, item (e) MUST be included when the home agent and the 3067 foreign agent share a mobility security association. 3069 4. Routing Considerations 3071 This section describes how mobile nodes, home agents, and (possibly) 3072 foreign agents cooperate to route datagrams to/from mobile nodes that 3073 are connected to a foreign network. The mobile node informs its home 3074 agent of its current location using the registration procedure 3075 described in Section 3. See the protocol overview in Section 1.7 for 3076 the relative locations of the mobile node's home address with respect 3077 to its home agent, and the mobile node itself with respect to any 3078 foreign agent with which it might attempt to register. 3080 4.1. Encapsulation Types 3082 Home agents and foreign agents MUST support tunneling datagrams using 3083 IP in IP encapsulation [14]. Any mobile node that uses a co-located 3084 care-of address MUST support receiving datagrams tunneled using IP in 3085 IP encapsulation. Minimal encapsulation [15] and GRE encapsulation 3086 [13] are alternate encapsulation methods which MAY optionally be 3087 supported by mobility agents and mobile nodes. The use of these 3088 alternative forms of encapsulation, when requested by the mobile 3089 node, is otherwise at the discretion of the home agent. 3091 4.2. Unicast Datagram Routing 3093 4.2.1. Mobile Node Considerations 3095 When connected to its home network, a mobile node operates without 3096 the support of mobility services. That is, it operates in the same 3097 way as any other (fixed) host or router. The method by which a 3098 mobile node selects a default router when connected to its home 3099 network, or when away from home and using a co-located care-of 3100 address, is outside the scope of this document. ICMP Router 3101 Advertisement [5] is one such method. 3103 When registered on a foreign network, the mobile node chooses a 3104 default router by the following rules: 3106 o If the mobile node is registered using a foreign agent care-of 3107 address, it MAY use its foreign agent as a first-hop router. The 3108 foreign agent's MAC address can be learned from Agent 3109 Advertisement. Otherwise, the mobile node MUST choose its default 3110 router from among the Router Addresses advertised in the ICMP 3111 Router Advertisement portion of that Agent Advertisement message. 3113 o If the mobile node is registered directly with its home agent 3114 using a co-located care-of address, then the mobile node SHOULD 3115 choose its default router from among those advertised in any ICMP 3116 Router Advertisement message that it receives for which its 3117 externally obtained care-of address and the Router Address match 3118 under the network prefix. If the mobile node's externally 3119 obtained care-of address matches the IP source address of the 3120 Agent Advertisement under the network prefix, the mobile node MAY 3121 also consider that IP source address as another possible choice 3122 for the IP address of a default router. The network prefix MAY be 3123 obtained from the Prefix-Lengths Extension in the Router 3124 Advertisement, if present. The prefix MAY also be obtained 3125 through other mechanisms beyond the scope of this document. 3127 While they are away from the home network, mobile nodes MUST NOT 3128 broadcast ARP packets to find the MAC address of another Internet 3129 node. Thus, the (possibly empty) list of Router Addresses from the 3130 ICMP Router Advertisement portion of the message is not useful for 3131 selecting a default router, unless the mobile node has some means not 3132 involving broadcast ARP and not specified within this document for 3133 obtaining the MAC address of one of the routers in the list. 3134 Similarly, in the absence of unspecified mechanisms for obtaining MAC 3135 addresses on foreign networks, the mobile node MUST ignore redirects 3136 to other routers on foreign networks. 3138 4.2.2. Foreign Agent Considerations 3140 Upon receipt of an encapsulated datagram sent to its advertised 3141 care-of address, a foreign agent MUST compare the inner destination 3142 address to those entries in its visitor list. When the destination 3143 does not match the address of any mobile node currently in the 3144 visitor list, the foreign agent MUST NOT forward the datagram without 3145 modifications to the original IP header, because otherwise a routing 3146 loop is likely to result. The datagram SHOULD be silently discarded. 3147 ICMP Destination Unreachable MUST NOT be sent when a foreign agent is 3148 unable to forward an incoming tunneled datagram. Otherwise, the 3149 foreign agent forwards the decapsulated datagram to the mobile node. 3151 The foreign agent MUST NOT advertise to other routers in its routing 3152 domain, nor to any other mobile node, the presence of a mobile router 3153 (Section 4.5) or mobile node in its visitor list. 3155 The foreign agent MUST route datagrams it receives from registered 3156 mobile nodes. At a minimum, this means that the foreign agent must 3157 verify the IP Header Checksum, decrement the IP Time To Live, 3158 recompute the IP Header Checksum, and forward such datagrams to a 3159 default router. 3161 A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC 3162 address on a foreign network. It may obtain the MAC address by 3163 copying the information from an Agent Solicitation or a Registration 3164 Request transmitted from a mobile node. A foreign agent's ARP cache 3165 for the mobile node's IP address MUST NOT be allowed to expire before 3166 the mobile node's visitor list entry expires, unless the foreign 3167 agent has some way other than broadcast ARP to refresh its MAC 3168 address associated with the mobile node's IP address. 3170 Each foreign agent SHOULD support the mandatory features for reverse 3171 tunneling [12]. 3173 4.2.3. Home Agent Considerations 3175 The home agent MUST be able to intercept any datagrams on the home 3176 network addressed to the mobile node while the mobile node is 3177 registered away from home. Proxy and gratuitous ARP MAY be used in 3178 enabling this interception, as specified in Section 4.6. 3180 The home agent must examine the IP Destination Address of all 3181 arriving datagrams to see if it is equal to the home address of any 3182 of its mobile nodes registered away from home. If so, the home agent 3183 tunnels the datagram to the mobile node's currently registered 3184 care-of address or addresses. If the home agent supports the 3185 optional capability of multiple simultaneous mobility bindings, it 3186 tunnels a copy to each care-of address in the mobile node's mobility 3187 binding list. If the mobile node has no current mobility bindings, 3188 the home agent MUST NOT attempt to intercept datagrams destined for 3189 the mobile node, and thus will not in general receive such datagrams. 3190 However, if the home agent is also a router handling common IP 3191 traffic, it is possible that it will receive such datagrams for 3192 forwarding onto the home network. In this case, the home agent MUST 3193 assume the mobile node is at home and simply forward the datagram 3194 directly onto the home network. 3196 For multihomed home agents, the source address in the outer IP header 3197 of the encapsulated datagram MUST be the address sent to the mobile 3198 node in the home agent field of the registration reply. That is, the 3199 home agent cannot use the the address of some other network interface 3200 as the source address. 3202 See Section 4.1 regarding methods of encapsulation that may be used 3203 for tunneling. Nodes implementing tunneling SHOULD also implement 3204 the "tunnel soft state" mechanism [14], which allows ICMP error 3205 messages returned from the tunnel to correctly be reflected back to 3206 the original senders of the tunneled datagrams. 3208 Home agents MUST decapsulate packets addressed to themselves, sent by 3209 a mobile node for the purpose of maintaining location privacy, as 3210 described in Section 5.5. This feature is also required for support 3211 of reverse tunneling [12]. 3213 If the Lifetime for a given mobility binding expires before the home 3214 agent has received another valid Registration Request for that mobile 3215 node, then that binding is deleted from the mobility binding list. 3216 The home agent MUST NOT send any Registration Reply message simply 3217 because the mobile node's binding has expired. The entry in the 3218 visitor list of the mobile node's current foreign agent will expire 3219 naturally, probably at the same time as the binding expired at the 3220 home agent. When a mobility binding's lifetime expires, the home 3221 agent MUST delete the binding, but it MUST retain any other (non- 3222 expired) simultaneous mobility bindings that it holds for the mobile 3223 node. 3225 When a home agent receives a datagram, intercepted for one of its 3226 mobile nodes registered away from home, the home agent MUST examine 3227 the datagram to check if it is already encapsulated. If so, special 3228 rules apply in the forwarding of that datagram to the mobile node: 3230 o If the inner (encapsulated) Destination Address is the same as the 3231 outer Destination Address (the mobile node), then the home agent 3232 MUST also examine the outer Source Address of the encapsulated 3233 datagram (the source address of the tunnel). If this outer Source 3234 Address is the same as the mobile node's current care-of address, 3235 the home agent MUST silently discard that datagram in order to 3236 prevent a likely routing loop. If, instead, the outer Source 3237 Address is NOT the same as the mobile node's current care-of 3238 address, then the home agent SHOULD forward the datagram to the 3239 mobile node. In order to forward the datagram in this case, the 3240 home agent MAY simply alter the outer Destination Address to the 3241 care-of address, rather than re-encapsulating the datagram. 3243 o Otherwise (the inner Destination Address is NOT the same as the 3244 outer Destination Address), the home agent SHOULD encapsulate the 3245 datagram again (nested encapsulation), with the new outer 3246 Destination Address set equal to the mobile node's care-of 3247 address. That is, the home agent forwards the entire datagram to 3248 the mobile node in the same way as any other datagram 3249 (encapsulated already or not). 3251 4.3. Broadcast Datagrams 3253 When a home agent receives a broadcast datagram, it MUST NOT forward 3254 the datagram to any mobile nodes in its mobility binding list other 3255 than those that have requested forwarding of broadcast datagrams. A 3256 mobile node MAY request forwarding of broadcast datagrams by setting 3257 the 'B' bit in its Registration Request message (Section 3.3). For 3258 each such registered mobile node, the home agent SHOULD forward 3259 received broadcast datagrams to the mobile node, although it is a 3260 matter of configuration at the home agent as to which specific 3261 categories of broadcast datagrams will be forwarded to such mobile 3262 nodes. 3264 If the 'D' bit was set in the mobile node's Registration Request 3265 message, indicating that the mobile node is using a co-located 3266 care-of address, the home agent simply tunnels appropriate broadcast 3267 IP datagrams to the mobile node's care-of address. Otherwise (the 3268 'D' bit was NOT set), the home agent first encapsulates the broadcast 3269 datagram in a unicast datagram addressed to the mobile node's home 3270 address, and then tunnels this encapsulated datagram to the foreign 3271 agent. This extra level of encapsulation is required so that the 3272 foreign agent can determine which mobile node should receive the 3273 datagram after it is decapsulated. When received by the foreign 3274 agent, the unicast encapsulated datagram is detunneled and delivered 3275 to the mobile node in the same way as any other datagram. In either 3276 case, the mobile node must decapsulate the datagram it receives in 3277 order to recover the original broadcast datagram. 3279 4.4. Multicast Datagram Routing 3281 As mentioned previously, a mobile node that is connected to its home 3282 network functions in the same way as any other (fixed) host or 3283 router. Thus, when it is at home, a mobile node functions 3284 identically to other multicast senders and receivers. This section 3285 therefore describes the behavior of a mobile node that is visiting a 3286 foreign network. 3288 In order to receive multicasts, a mobile node MUST join the multicast 3289 group in one of two ways. First, a mobile node MAY join the group 3290 via a (local) multicast router on the visited subnet. This option 3291 assumes that there is a multicast router present on the visited 3292 subnet. If the mobile node is using a co-located care-of address, it 3293 SHOULD use this address as the source IP address of its IGMP [6] 3294 messages. Otherwise, it MAY use its home address. 3296 Alternatively, a mobile node which wishes to receive multicasts MAY 3297 join groups via a bi-directional tunnel to its home agent, assuming 3298 that its home agent is a multicast router. The mobile node tunnels 3299 IGMP messages to its home agent and the home agent forwards multicast 3300 datagrams down the tunnel to the mobile node. For packets tunneled 3301 to the home agent, the source address in the IP header SHOULD be the 3302 mobile node's home address. 3304 The rules for multicast datagram delivery to mobile nodes in this 3305 case are identical to those for broadcast datagrams (Section 4.3). 3306 Namely, if the mobile node is using a co-located care-of address (the 3307 'D' bit was set in the mobile node's Registration Request), then the 3308 home agent SHOULD tunnel the datagram to this care-of address; 3309 otherwise, the home agent MUST first encapsulate the datagram in a 3310 unicast datagram addressed to the mobile node's home address and then 3311 MUST tunnel the resulting datagram (nested tunneling) to the mobile 3312 node's care-of address. For this reason, the mobile node MUST be 3313 capable of decapsulating packets sent to its home address in order to 3314 receive multicast datagrams using this method. 3316 A mobile node that wishes to send datagrams to a multicast group also 3317 has two options: (1) send directly on the visited network; or (2) 3318 send via a tunnel to its home agent. Because multicast routing in 3319 general depends upon the IP source address, a mobile node which sends 3320 multicast datagrams directly on the visited network MUST use a co- 3321 located care-of address as the IP source address. Similarly, a 3322 mobile node which tunnels a multicast datagram to its home agent MUST 3323 use its home address as the IP source address of both the (inner) 3324 multicast datagram and the (outer) encapsulating datagram. This 3325 second option assumes that the home agent is a multicast router. 3327 4.5. Mobile Routers 3329 A mobile node can be a router that is responsible for the mobility of 3330 one or more entire networks moving together, perhaps on an airplane, 3331 a ship, a train, an automobile, a bicycle, or a kayak. The nodes 3332 connected to a network served by the mobile router may themselves be 3333 fixed nodes or mobile nodes or routers. In this document, such 3334 networks are called "mobile networks". 3336 A mobile router MAY act as a foreign agent and provide a foreign 3337 agent care-of address to mobile nodes connected to the mobile 3338 network. Typical routing to a mobile node via a mobile router in 3339 this case is illustrated by the following example: 3341 a. A laptop computer is disconnected from its home network and later 3342 attached to a network port in the seat back of an aircraft. The 3343 laptop computer uses Mobile IP to register on this foreign 3344 network, using a foreign agent care-of address discovered through 3345 an Agent Advertisement from the aircraft's foreign agent. 3347 b. The aircraft network is itself mobile. Suppose the node serving 3348 as the foreign agent on the aircraft also serves as the default 3349 router that connects the aircraft network to the rest of the 3350 Internet. When the aircraft is at home, this router is attached 3351 to some fixed network at the airline's headquarters, which is the 3352 router's home network. While the aircraft is in flight, this 3353 router registers from time to time over its radio link with a 3354 series of foreign agents below it on the ground. This router's 3355 home agent is a node on the fixed network at the airline's 3356 headquarters. 3358 c. Some correspondent node sends a datagram to the laptop computer, 3359 addressing the datagram to the laptop's home address. This 3360 datagram is initially routed to the laptop's home network. 3362 d. The laptop's home agent intercepts the datagram on the home 3363 network and tunnels it to the laptop's care-of address, which in 3364 this example is an address of the node serving as router and 3365 foreign agent on the aircraft. Normal IP routing will route the 3366 datagram to the fixed network at the airline's headquarters. 3368 e. The aircraft router and foreign agent's home agent there 3369 intercepts the datagram and tunnels it to its current care-of 3370 address, which in this example is some foreign agent on the 3371 ground below the aircraft. The original datagram from the 3372 correspondent node has now been encapsulated twice: once by the 3373 laptop's home agent and again by the aircraft's home agent. 3375 f. The foreign agent on the ground decapsulates the datagram, 3376 yielding a datagram still encapsulated by the laptop's home 3377 agent, with a destination address of the laptop's care-of 3378 address. The ground foreign agent sends the resulting datagram 3379 over its radio link to the aircraft. 3381 g. The foreign agent on the aircraft decapsulates the datagram, 3382 yielding the original datagram from the correspondent node, with 3383 a destination address of the laptop's home address. The aircraft 3384 foreign agent delivers the datagram over the aircraft network to 3385 the laptop's link-layer address. 3387 This example illustrated the case in which a mobile node is attached 3388 to a mobile network. That is, the mobile node is mobile with respect 3389 to the network, which itself is also mobile (here with respect to the 3390 ground). If, instead, the node is fixed with respect to the mobile 3391 network (the mobile network is the fixed node's home network), then 3392 either of two methods may be used to cause datagrams from 3393 correspondent nodes to be routed to the fixed node. 3395 A home agent MAY be configured to have a permanent registration for 3396 the fixed node, that indicates the mobile router's address as the 3397 fixed host's care-of address. The mobile router's home agent will 3398 usually be used for this purpose. The home agent is then responsible 3399 for advertising connectivity using normal routing protocols to the 3400 fixed node. Any datagrams sent to the fixed node will thus use 3401 nested tunneling as described above. 3403 Alternatively, the mobile router MAY advertise connectivity to the 3404 entire mobile network using normal IP routing protocols through a bi- 3405 directional tunnel to its own home agent. This method avoids the 3406 need for nested tunneling of datagrams. 3408 4.6. ARP, Proxy ARP, and Gratuitous ARP 3410 The use of ARP [16] requires special rules for correct operation when 3411 wireless or mobile nodes are involved. The requirements specified in 3412 this section apply to all home networks in which ARP is used for 3413 address resolution. 3415 In addition to the normal use of ARP for resolving a target node's 3416 link-layer address from its IP address, this document distinguishes 3417 two special uses of ARP: 3419 o A Proxy ARP [49] is an ARP Reply sent by one node on behalf of 3420 another node which is either unable or unwilling to answer its own 3421 ARP Requests. The sender of a Proxy ARP reverses the Sender and 3422 Target Protocol Address fields as described in [16], but supplies 3423 some configured link-layer address (generally, its own) in the 3424 Sender Hardware Address field. The node receiving the Reply will 3425 then associate this link-layer address with the IP address of the 3426 original target node, causing it to transmit future datagrams for 3427 this target node to the node with that link-layer address. 3429 o A Gratuitous ARP [45] is an ARP packet sent by a node in order to 3430 spontaneously cause other nodes to update an entry in their ARP 3431 cache. A gratuitous ARP MAY use either an ARP Request or an ARP 3432 Reply packet. In either case, the ARP Sender Protocol Address and 3433 ARP Target Protocol Address are both set to the IP address of the 3434 cache entry to be updated, and the ARP Sender Hardware Address is 3435 set to the link-layer address to which this cache entry should be 3436 updated. When using an ARP Reply packet, the Target Hardware 3437 Address is also set to the link-layer address to which this cache 3438 entry should be updated (this field is not used in an ARP Request 3439 packet). 3441 In either case, for a gratuitous ARP, the ARP packet MUST be 3442 transmitted as a local broadcast packet on the local link. As 3443 specified in [16], any node receiving any ARP packet (Request or 3444 Reply) MUST update its local ARP cache with the Sender Protocol 3445 and Hardware Addresses in the ARP packet, if the receiving node 3446 has an entry for that IP address already in its ARP cache. This 3447 requirement in the ARP protocol applies even for ARP Request 3448 packets, and for ARP Reply packets that do not match any ARP 3449 Request transmitted by the receiving node [16]. 3451 While a mobile node is registered on a foreign network, its home 3452 agent uses proxy ARP [49] to reply to ARP Requests it receives that 3453 seek the mobile node's link-layer address. When receiving an ARP 3454 Request, the home agent MUST examine the target IP address of the 3455 Request, and if this IP address matches the home address of any 3456 mobile node for which it has a registered mobility binding, the home 3457 agent MUST transmit an ARP Reply on behalf of the mobile node. After 3458 exchanging the sender and target addresses in the packet [49], the 3459 home agent MUST set the sender link-layer address in the packet to 3460 the link-layer address of its own interface over which the Reply will 3461 be sent. 3463 When a mobile node leaves its home network and registers a binding on 3464 a foreign network, its home agent uses gratuitous ARP to update the 3465 ARP caches of nodes on the home network. This causes such nodes to 3466 associate the link-layer address of the home agent with the mobile 3467 node's home (IP) address. When registering a binding for a mobile 3468 node for which the home agent previously had no binding (the mobile 3469 node was assumed to be at home), the home agent MUST transmit a 3470 gratuitous ARP on behalf of the mobile node. This gratuitous ARP 3471 packet MUST be transmitted as a broadcast packet on the link on which 3472 the mobile node's home address is located. Since broadcasts on the 3473 local link (such as Ethernet) are typically not guaranteed to be 3474 reliable, the gratuitous ARP packet SHOULD be retransmitted a small 3475 number of times to increase its reliability. 3477 When a mobile node returns to its home network, the mobile node and 3478 its home agent use gratuitous ARP to cause all nodes on the mobile 3479 node's home network to update their ARP caches to once again 3480 associate the mobile node's own link-layer address with the mobile 3481 node's home (IP) address. Before transmitting the (de)Registration 3482 Request message to its home agent, the mobile node MUST transmit this 3483 gratuitous ARP on its home network as a local broadcast on this link. 3484 The gratuitous ARP packet SHOULD be retransmitted a small number of 3485 times to increase its reliability, but these retransmissions SHOULD 3486 proceed in parallel with the transmission and processing of its 3487 (de)Registration Request. 3489 When the mobile node's home agent receives and accepts this 3490 (de)Registration Request, the home agent MUST also transmit a 3491 gratuitous ARP on the mobile node's home network. This gratuitous 3492 ARP also is used to associate the mobile node's home address with the 3493 mobile node's own link-layer address. A gratuitous ARP is 3494 transmitted by both the mobile node and its home agent, since in the 3495 case of wireless network interfaces, the area within transmission 3496 range of the mobile node will likely differ from that within range of 3497 its home agent. The ARP packet from the home agent MUST be 3498 transmitted as a local broadcast on the mobile node's home link, and 3499 SHOULD be retransmitted a small number of times to increase its 3500 reliability; these retransmissions, however, SHOULD proceed in 3501 parallel with the transmission and processing of its (de)Registration 3502 Reply. 3504 While the mobile node is away from home, it MUST NOT transmit any 3505 broadcast ARP Request or ARP Reply messages. Finally, while the 3506 mobile node is away from home, it MUST NOT reply to ARP Requests in 3507 which the target IP address is its own home address unless the ARP 3508 Request is unicast by a foreign agent with which the mobile node is 3509 attempting to register or a foreign agent with which the mobile node 3510 has an unexpired registration. In the latter case, the mobile node 3511 MUST use a unicast ARP Reply to respond to the foreign agent. Note 3512 that if the mobile node is using a co-located care-of address and 3513 receives an ARP Request in which the target IP address is this 3514 care-of address, then the mobile node SHOULD reply to this ARP 3515 Request. Note also that, when transmitting a Registration Request on 3516 a foreign network, a mobile node may discover the link-layer address 3517 of a foreign agent by storing the address as it is received from the 3518 Agent Advertisement from that foreign agent, but not by transmitting 3519 a broadcast ARP Request message. 3521 The specific order in which each of the above requirements for the 3522 use of ARP, proxy ARP, and gratuitous ARP are applied, relative to 3523 the transmission and processing of the mobile node's Registration 3524 Request and Registration Reply messages when leaving home or 3525 returning home, are important to the correct operation of the 3526 protocol. 3528 To summarize the above requirements, when a mobile node leaves its 3529 home network, the following steps, in this order, MUST be performed: 3531 o The mobile node decides to register away from home, perhaps 3532 because it has received an Agent Advertisement from a foreign 3533 agent and has not recently received one from its home agent. 3535 o Before transmitting the Registration Request, the mobile node 3536 disables its own future processing of any ARP Requests it may 3537 subsequently receive requesting the link-layer address 3538 corresponding to its home address, except insofar as necessary to 3539 communicate with foreign agents on visited networks. 3541 o The mobile node transmits its Registration Request. 3543 o When the mobile node's home agent receives and accepts the 3544 Registration Request, it performs a gratuitous ARP on behalf of 3545 the mobile node, and begins using proxy ARP to reply to ARP 3546 Requests that it receives requesting the mobile node's link-layer 3547 address. In the gratuitous ARP, the ARP Sender Hardware Address 3548 is set to the link-layer address of the home agent. If, instead, 3549 the home agent rejects the Registration Request, no ARP processing 3550 (gratuitous nor proxy) is performed by the home agent. 3552 When a mobile node later returns to its home network, the following 3553 steps, in this order, MUST be performed: 3555 o The mobile node decides to register at home, perhaps because it 3556 has received an Agent Advertisement from its home agent. 3558 o Before transmitting the Registration Request, the mobile node re- 3559 enables its own future processing of any ARP Requests it may 3560 subsequently receive requesting its link-layer address. 3562 o The mobile node performs a gratuitous ARP for itself. In this 3563 gratuitous ARP, the ARP Sender Hardware Address is set to the 3564 link-layer address of the mobile node. 3566 o The mobile node transmits its Registration Request. 3568 o When the mobile node's home agent receives and accepts the 3569 Registration Request, it stops using proxy ARP to reply to ARP 3570 Requests that it receives requesting the mobile node's link-layer 3571 address, and then performs a gratuitous ARP on behalf of the 3572 mobile node. In this gratuitous ARP, the ARP Sender Hardware 3573 Address is set to the link-layer address of the mobile node. If, 3574 instead, the home agent rejects the Registration Request, the home 3575 agent MUST NOT make any change to the way it performs ARP 3576 processing (gratuitous nor proxy) for the mobile node. In this 3577 latter case, the home agent should operate as if the mobile node 3578 has not returned home, and continue to perform proxy ARP on behalf 3579 of the mobile node. 3581 5. Security Considerations 3583 The mobile computing environment is potentially very different from 3584 the ordinary computing environment. In many cases, mobile computers 3585 will be connected to the network via wireless links. Such links are 3586 particularly vulnerable to passive eavesdropping, active replay 3587 attacks, and other active attacks. 3589 5.1. Message Authentication Codes 3591 Home agents and mobile nodes MUST be able to perform authentication. 3592 The default algorithm is HMAC-MD5 [10], with a key size of 128 bits. 3593 The foreign agent MUST also support authentication using HMAC-MD5 and 3594 key sizes of 128 bits or greater, with manual key distribution. Keys 3595 with arbitrary binary values MUST be supported. 3597 The "prefix+suffix" use of MD5 to protect data and a shared secret is 3598 considered vulnerable to attack by the cryptographic community. 3599 Where backward compatibility with existing Mobile IP implementations 3600 that use this mode is needed, new implementations SHOULD include 3601 keyed MD5 [19] as one of the additional authentication algorithms for 3602 use when producing and verifying the authentication data that is 3603 supplied with Mobile IP registration messages, for instance in the 3604 extensions specified in Section 3.5.2, Section 3.5.3, and 3605 Section 3.5.4. 3607 More authentication algorithms, algorithm modes, key distribution 3608 methods, and key sizes MAY also be supported for all of these 3609 extensions. 3611 5.2. Areas of Security Concern in this Protocol 3613 The registration protocol described in this document will result in a 3614 mobile node's traffic being tunneled to its care-of address. This 3615 tunneling feature could be a significant vulnerability if the 3616 registration were not authenticated. Such remote redirection, for 3617 instance as performed by the mobile registration protocol, is widely 3618 understood to be a security problem in the current Internet if not 3619 authenticated [30]. Moreover, the Address Resolution Protocol (ARP) 3620 is not authenticated, and can potentially be used to steal another 3621 host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings 3622 with it all of the risks associated with the use of ARP. 3624 5.3. Key Management 3626 This specification requires a strong authentication mechanism (keyed 3627 MD5) which precludes many potential attacks based on the Mobile IP 3628 registration protocol. However, because key distribution is 3629 difficult in the absence of a network key management protocol, 3630 messages with the foreign agent are not all required to be 3631 authenticated. In a commercial environment it might be important to 3632 authenticate all messages between the foreign agent and the home 3633 agent, so that billing is possible, and service providers do not 3634 provide service to users that are not legitimate customers of that 3635 service provider. 3637 5.4. Picking Good Random Numbers 3639 The strength of any authentication mechanism depends on several 3640 factors, including the innate strength of the authentication 3641 algorithm, the secrecy of the key used, the strength of the key used, 3642 and the quality of the particular implementation. This specification 3643 requires implementation of keyed MD5 for authentication, but does not 3644 preclude the use of other authentication algorithms and modes. For 3645 keyed MD5 authentication to be useful, the 128-bit key must be both 3646 secret (that is, known only to authorized parties) and pseudo-random. 3647 If nonces are used in connection with replay protection, they must 3648 also be selected carefully. Eastlake, et al. [8] provides more 3649 information on generating pseudo-random numbers. 3651 5.5. Privacy 3653 Users who have sensitive data that they do not wish others to see 3654 should use mechanisms outside the scope of this document (such as 3655 encryption) to provide appropriate protection. Users concerned about 3656 traffic analysis should consider appropriate use of link encryption. 3657 If absolute location privacy is desired, the mobile node can create a 3658 tunnel to its home agent. Then, datagrams destined for correspondent 3659 nodes will appear to emanate from the home network, and it may be 3660 more difficult to pinpoint the location of the mobile node. Such 3661 mechanisms are all beyond the scope of this document. 3663 5.6. Ingress Filtering 3665 Many routers implement security policies such as "ingress filtering" 3666 [35] that do not allow forwarding of packets that have a Source 3667 Address which appears topologically incorrect. In environments where 3668 this is a problem, mobile nodes may use reverse tunneling [12] with 3669 the foreign agent supplied care-of address as the Source Address. 3670 Reverse tunneled packets will be able to pass normally through such 3671 routers, while ingress filtering rules will still be able to locate 3672 the true topological source of the packet in the same way as packets 3673 from non-mobile nodes. 3675 5.7. Replay Protection for Registration Requests 3677 The Identification field is used to let the home agent verify that a 3678 registration message has been freshly generated by the mobile node, 3679 not replayed by an attacker from some previous registration. Two 3680 methods are described in this section: timestamps (mandatory) and 3681 "nonces" (optional). All mobile nodes and home agents MUST implement 3682 timestamp-based replay protection. These nodes MAY also implement 3683 nonce-based replay protection. 3685 The style of replay protection in effect between a mobile node and 3686 its home agent is part of the mobile security association. A mobile 3687 node and its home agent MUST agree on which method of replay 3688 protection will be used. The interpretation of the Identification 3689 field depends on the method of replay protection as described in the 3690 subsequent subsections. 3692 Whatever method is used, the low-order 32 bits of the Identification 3693 MUST be copied unchanged from the Registration Request to the Reply. 3694 The foreign agent uses those bits (and the mobile node's home 3695 address) to match Registration Requests with corresponding replies. 3696 The mobile node MUST verify that the low-order 32 bits of any 3697 Registration Reply are identical to the bits it sent in the 3698 Registration Request. 3700 The Identification in a new Registration Request MUST NOT be the same 3701 as in an immediately preceding Request, and SHOULD NOT repeat while 3702 the same security context is being used between the mobile node and 3703 the home agent. Retransmission as in Section 3.6.3 is allowed. 3705 5.7.1. Replay Protection using Timestamps 3707 The basic principle of timestamp replay protection is that the node 3708 generating a message inserts the current time of day, and the node 3709 receiving the message checks that this timestamp is sufficiently 3710 close to its own time of day. Unless specified differently in the 3711 security association between the nodes, a default value of 7 seconds 3712 MAY be used to limit the time difference. This value SHOULD be 3713 greater than 3 seconds. Obviously the two nodes must have adequately 3714 synchronized time-of-day clocks. As with any messages, time 3715 synchronization messages may be protected against tampering by an 3716 authentication mechanism determined by the security context between 3717 the two nodes. 3719 If timestamps are used, the mobile node MUST set the Identification 3720 field to a 64-bit value formatted as specified by the Network Time 3721 Protocol [11]. The low-order 32 bits of the NTP format represent 3722 fractional seconds, and those bits which are not available from a 3723 time source SHOULD be generated from a good source of randomness. 3724 Note, however, that when using timestamps, the 64-bit Identification 3725 used in a Registration Request from the mobile node MUST be greater 3726 than that used in any previous Registration Request, as the home 3727 agent uses this field also as a sequence number. Without such a 3728 sequence number, it would be possible for a delayed duplicate of an 3729 earlier Registration Request to arrive at the home agent (within the 3730 clock synchronization required by the home agent), and thus be 3731 applied out of order, mistakenly altering the mobile node's current 3732 registered care-of address. 3734 Upon receipt of a Registration Request with an authorization-enabling 3735 extension, the home agent MUST check the Identification field for 3736 validity. In order to be valid, the timestamp contained in the 3737 Identification field MUST be close enough to the home agent's time of 3738 day clock and the timestamp MUST be greater than all previously 3739 accepted timestamps for the requesting mobile node. Time tolerances 3740 and resynchronization details are specific to a particular mobility 3741 security association. 3743 If the timestamp is valid, the home agent copies the entire 3744 Identification field into the Registration Reply it returns the Reply 3745 to the mobile node. If the timestamp is not valid, the home agent 3746 copies only the low-order 32 bits into the Registration Reply, and 3747 supplies the high-order 32 bits from its own time of day. In this 3748 latter case, the home agent MUST reject the registration by returning 3749 Code 133 (identification mismatch) in the Registration Reply. 3751 As described in Section 3.6.2.1, the mobile node MUST verify that the 3752 low-order 32 bits of the Identification in the Registration Reply are 3753 identical to those in the rejected registration attempt, before using 3754 the high-order bits for clock resynchronization. 3756 5.7.2. Replay Protection using Nonces 3758 The basic principle of nonce replay protection is that node A 3759 includes a new random number in every message to node B, and checks 3760 that node B returns that same number in its next message to node A. 3761 Both messages use an authentication code to protect against 3762 alteration by an attacker. At the same time node B can send its own 3763 nonces in all messages to node A (to be echoed by node A), so that it 3764 too can verify that it is receiving fresh messages. 3766 The home agent may be expected to have resources for computing 3767 pseudo-random numbers useful as nonces [8]. It inserts a new nonce 3768 as the high-order 32 bits of the identification field of every 3769 Registration Reply. The home agent copies the low-order 32 bits of 3770 the Identification from the Registration Request message into the 3771 low-order 32 bits of the Identification in the Registration Reply. 3772 When the mobile node receives an authenticated Registration Reply 3773 from the home agent, it saves the high-order 32 bits of the 3774 identification for use as the high-order 32 bits of its next 3775 Registration Request. 3777 The mobile node is responsible for generating the low-order 32 bits 3778 of the Identification in each Registration Request. Ideally it 3779 should generate its own random nonces. However it may use any 3780 expedient method, including duplication of the random value sent by 3781 the home agent. The method chosen is of concern only to the mobile 3782 node, because it is the node that checks for valid values in the 3783 Registration Reply. The high-order and low-order 32 bits of the 3784 identification chosen SHOULD both differ from their previous values. 3785 The home agent uses a new high-order value and the mobile node uses a 3786 new low-order value for each registration message. The foreign agent 3787 uses the low-order value (and the mobile host's home address) to 3788 correctly match registration replies with pending Requests 3789 (Section 3.7.1). 3791 If a registration message is rejected because of an invalid nonce, 3792 the Reply always provides the mobile node with a new nonce to be used 3793 in the next registration. Thus the nonce protocol is self- 3794 synchronizing. 3796 6. IANA Considerations 3798 Mobile IP specifies several new number spaces for values to be used 3799 in various message fields. These number spaces include the 3800 following: 3802 o Mobile IP message types sent to UDP port 434, as defined in 3803 Section 1.8. 3805 o types of extensions to Registration Request and Registration Reply 3806 messages (see Section 3.3 and Section 3.4, and also consult 3807 ([12],[43],[2],[3],[7]). 3809 o values for the Code in the Registration Reply message (see 3810 Section 3.4, and also consult ([12],[43],[2],[3],[7]). 3812 o Mobile IP defines so-called Agent Solicitation and Agent 3813 Advertisement messages. These messages are in fact Router 3814 Discovery messages [5] augmented with mobile-IP specific 3815 extensions. Thus, they do not define a new name space, but do 3816 define additional Router Discovery extensions as described below 3817 in Section 6.2. Also see Section 2.1 and consult ([3], [7]). 3819 There are additional Mobile IP numbering spaces specified in [3]. 3821 Information about assignment of mobile-ip numbers derived from 3822 specifications external to this document is given by IANA at 3823 http://www.iana.org/numbers.html. From that URL, follow the 3824 hyperlinks to "M" within the "Directory of General Assigned Numbers", 3825 and subsequently to the specific section for "Mobile IP Numbers". 3827 In this revised specification, a new Code value (for the field in the 3828 Registration Reply message) is needed within the range typically used 3829 for Foreign Agent messages. This error code is needed to indicate 3830 the status "Invalid Home Agent Address". See Section 3.7.2 for 3831 details. 3833 6.1. Mobile IP Message Types 3835 Mobile IP messages are defined to be those that are sent to a message 3836 recipient at port 434 (UDP or TCP). The number space for Mobile IP 3837 messages is specified in Section 1.8. Approval of new extension 3838 numbers is subject to Expert Review, and a specification is required 3839 [22]. The currently standardized message types have the following 3840 numbers, and are specified in the indicated sections. 3842 Type Name Section 3843 ---- -------------------------------------------- --------- 3844 1 Registration Request 3.3 3845 3 Registration Reply 3.4 3847 6.2. Extensions to RFC 1256 Router Advertisement 3849 RFC 1256 defines two ICMP message types, Router Advertisement and 3850 Router Solicitation. Mobile IP defines a number space for extensions 3851 to Router Advertisement, which could be used by protocols other than 3852 Mobile IP. The extension types currently standardized for use with 3853 Mobile IP have the following numbers. 3855 Type Name Reference 3856 ---- -------------------------------------------- --------- 3857 0 One-byte Padding 2.1.3 3858 16 Mobility Agent Advertisement 2.1.1 3859 19 Prefix-Lengths 2.1.2 3861 Approval of new extension numbers for use with Mobile IP is subject 3862 to Expert Review, and a specification is required [22]. 3864 6.3. Extensions to Mobile IP Registration Messages 3866 The Mobile IP messages, specified within this document, and listed in 3867 Section 1.8 and Section 6.1, may have extensions. Mobile IP message 3868 extensions all share the same number space, even if they are to be 3869 applied to different Mobile IP messages. The number space for Mobile 3870 IP message extensions is specified within this document. Approval of 3871 new extension numbers is subject to Expert Review, and a 3872 specification is required [22]. 3874 Type Name Reference 3875 ---- -------------------------------------------- --------- 3876 0 One-byte Padding 3877 32 Mobile-Home Authentication 3.5.2 3878 33 Mobile-Foreign Authentication 3.5.3 3879 34 Foreign-Home Authentication 3.5.4 3881 6.4. Code Values for Mobile IP Registration Reply Messages 3883 The Mobile IP Registration Reply message, specified in Section 3.4, 3884 has a Code field. The number space for the Code field values is also 3885 specified in Section 3.4. The Code number space is structured 3886 according to whether the registration was successful, or whether the 3887 foreign agent denied the registration request, or lastly whether the 3888 home agent denied the registration request, as follows: 3890 +---------+------------------------------------------------------+ 3891 | Code #s | Guideline | 3892 +---------+------------------------------------------------------+ 3893 | 0-8 | Success Codes | 3894 | | | 3895 | 9-63 | Allocation guidelines not specified in this document | 3896 | | | 3897 | 64-127 | Error Codes from the Foreign Agent | 3898 | | | 3899 | 128-192 | Error Codes from the Home Agent | 3900 | | | 3901 | 193-200 | Error Codes from the Gateway Foreign Agent [29] | 3902 | | | 3903 | 201-255 | Allocation guidelines not specified in this document | 3904 +---------+------------------------------------------------------+ 3906 Approval of new Code values requires Expert Review [22]. 3908 Table 1: Guidelines for Allocation of Code Values 3910 7. Acknowledgments 3912 Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp 3913 and John Ioannidis (JI) (Columbia University), for forming the 3914 working group, chairing it, and putting so much effort into its early 3915 development. Columbia's early Mobile IP work can be found in 3916 [37],[38],[39]. 3918 Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, 3919 Erik Nordmark, Basavaraj Patil, and Phil Roberts for their 3920 contributions to the group while performing the duties of 3921 chairperson, as well as for their many useful comments. 3923 Thanks to the active members of the Mobile IP Working Group, 3924 particularly those who contributed text, including (in alphabetical 3925 order) 3927 Ran Atkinson (Naval Research Lab), 3928 Samita Chakrabarti (Sun Microsystems) 3929 Ken Imboden (Candlestick Networks, Inc.) 3930 Dave Johnson (Carnegie Mellon University), 3931 Frank Kastenholz (FTP Software), 3932 Anders Klemets (KTH), 3933 Chip Maguire (KTH), 3934 Alison Mankin (ISI) 3935 Andrew Myles (Macquarie University), 3936 Thomas Narten (IBM), 3937 Al Quirt (Bell Northern Research), 3938 Yakov Rekhter (IBM), 3939 Fumio Teraoka (Sony), and 3940 Alper Yegin (NTT DoCoMo) 3942 Thanks to Charlie Kunzinger and to Bill Simpson, the editors who 3943 produced the first drafts for of this document, reflecting the 3944 discussions of the Working Group. Much of the new text in the later 3945 revisions preceding RFC 2002 is due to Jim Solomon and Dave Johnson. 3947 Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank 3948 Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for 3949 their generous support in hosting interim Working Group meetings. 3951 Section 1.10 and Section 1.11, which specify new extension formats to 3952 be used with aggregatable extension types, were included from a 3953 specification document (entitled "Mobile IP Extensions 3954 Rationalization (MIER)", which was written by 3955 Mohamed M.Khalil, Nortel Networks 3956 Raja Narayanan, nVisible Networks 3957 Haseeb Akhtar, Nortel Networks 3958 Emad Qaddoura, Nortel Networks 3960 Thanks to these authors, and also for the additional work on MIER, 3961 which was contributed by Basavaraj Patil, Pat Calhoun, Neil 3962 Justusson, N. Asokan, and Jouni Malinen. 3964 Thanks to Vijay Devarapalli, who put in many hours to convert the 3965 source for this text document into XML format. 3967 8. References 3969 8.1. Normative References 3971 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3972 Levels", BCP 14, RFC 2119, March 1997. 3974 [2] Calhoun, P. and C. Perkins, "Mobile IP Network Access 3975 Identifier Extension for IPv4", RFC 2794, March 2000. 3977 [3] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 3978 Challenge/Response Extensions (Revised)", RFC 4721, 3979 January 2007. 3981 [4] Cong, D., Hamlen, M., and C. Perkins, "The Definitions of 3982 Managed Objects for IP Mobility Support using SMIv2", RFC 2006, 3983 October 1996. 3985 [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 3986 September 1991. 3988 [6] Deering, S., "Host extensions for IP multicasting", STD 5, 3989 RFC 1112, August 1989. 3991 [7] Dommety, G. and K. Leung, "Mobile IP Vendor/ 3992 Organization-Specific Extensions", RFC 3115, April 2001. 3994 [8] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3995 Requirements for Security", BCP 106, RFC 4086, June 2005. 3997 [9] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 3999 [10] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 4000 for Message Authentication", RFC 2104, February 1997. 4002 [11] Mills, D., "Network Time Protocol (Version 3) Specification, 4003 Implementation", RFC 1305, March 1992. 4005 [12] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", 4006 RFC 3024, January 2001. 4008 [13] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 4009 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 4011 [14] Perkins, C., "IP Encapsulation within IP", RFC 2003, 4012 October 1996. 4014 [15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4015 October 1996. 4017 [16] Plummer, D., "Ethernet Address Resolution Protocol: Or 4018 converting network protocol addresses to 48.bit Ethernet 4019 address for transmission on Ethernet hardware", STD 37, 4020 RFC 826, November 1982. 4022 [17] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 4023 August 1980. 4025 [18] Postel, J., "Internet Protocol", STD 5, RFC 791, 4026 September 1981. 4028 [19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 4029 April 1992. 4031 [20] Solomon, J., "Applicability Statement for IP Mobility Support", 4032 RFC 2005, October 1996. 4034 [21] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 4035 August 2002. 4037 [22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 4038 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 4040 8.2. Informative References 4042 [23] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for 4043 PPP IPCP", RFC 2290, February 1998. 4045 [24] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. 4046 Vaidya, "Long Thin Networks", RFC 2757, January 2000. 4048 [25] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over 4049 Satellite Channels using Standard Mechanisms", BCP 28, 4050 RFC 2488, January 1999. 4052 [26] Paxson, V. and M. Allman, "Computing TCP's Retransmission 4053 Timer", RFC 2988, November 2000. 4055 [27] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network 4056 Address Translation (NAT) Devices", RFC 3519, April 2003. 4058 [28] Glass, S. and M. Chandra, "Registration Revocation in Mobile 4059 IPv4", RFC 3543, August 2003. 4061 [29] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 4062 Regional Registration", RFC 4857, June 2007. 4064 [30] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", 4065 ACM Computer Communications Review, 19(2), March 1989. 4067 [31] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 4068 Shelby, "Performance Enhancing Proxies Intended to Mitigate 4069 Link-Related Degradations", RFC 3135, June 2001. 4071 [32] Caceres, R. and L. Iftode, "Improving the Performance of 4072 Reliable Transport Protocols in Mobile Computing Environments", 4073 IEEE Journal on Selected Areas in Communication, 13(5):850-- 4074 857, June 1995. 4076 [33] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. 4077 Vaidya, "End-to-end Performance Implications of Links with 4078 Errors", BCP 50, RFC 3155, August 2001. 4080 [34] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 4081 March 1997. 4083 [35] Ferguson, P. and D. Senie, "Network Ingress Filtering: 4084 Defeating Denial of Service Attacks which employ IP Source 4085 Address Spoofing", BCP 38, RFC 2827, May 2000. 4087 [36] Jacobson, V., "Compressing TCP/IP headers for low-speed serial 4088 links", RFC 1144, February 1990. 4090 [37] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-Based Protocols 4091 for Mobile Interworking", In Proceedings of the SIGCOMM '01 4092 Conference: Communications Architectures and Protocols, Pages 4093 235--245, September 1991. 4095 [38] Ioannidis, J. and G. Maguire, "The Design and Implementation of 4096 a Mobile Internetworking Architecture", In Proceedings of the 4097 Winter USENIX Technical Conference, Pages 489--500, 4098 January 1993. 4100 [39] Ioannidis, J., "Protocols for Mobile Interworking", PhD 4101 Dissertation - Columbia University in the City of New York , 4102 July 1993. 4104 [40] Jacobson, V., "Congestion Avoidance and Control", In 4105 Proceedings of the SIGCOMM '88 Workshop, ACM SIGCOMM, ACM 4106 Press, Pages 314--329, August 1998. 4108 [41] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 4109 RFC 2863, June 2000. 4111 [42] McGregor, G., "The PPP Internet Protocol Control Protocol 4112 (IPCP)", RFC 1332, May 1992. 4114 [43] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for 4115 Mobile IP", RFC 2356, June 1998. 4117 [44] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 4119 [45] Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols", 4120 Addison-Wesley, Reading, Massachussets, 1994. 4122 [46] Perkins, C. and P. Calhoun, "Authentication, Authorization, and 4123 Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, 4124 March 2005. 4126 [47] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 4127 RFC 1661, July 1994. 4129 [48] IANA Assigned Numbers Online Database, "Mobile IPv4 Numbers", 4130 http://www.iana.org/assignments/mobileip-numbers . 4132 [49] Postel, J., "Multi-LAN address resolution", RFC 925, 4133 October 1984. 4135 Appendix A. Pre-RFC5378 Disclaimer 4137 This document may contain material from IETF Documents or IETF 4138 Contributions published or made publicly available before November 4139 10, 2008. The person(s) controlling the copyright in some of this 4140 material may not have granted the IETF Trust the right to allow 4141 modifications of such material outside the IETF Standards Process. 4142 Without obtaining an adequate license from the person(s) controlling 4143 the copyright in such materials, this document may not be modified 4144 outside the IETF Standards Process, and derivative works of it may 4145 not be created outside the IETF Standards Process, except to format 4146 it for publication as an RFC or to translate it into languages other 4147 than English. 4149 Appendix B. Link-Layer Considerations 4151 The mobile node MAY use link-layer mechanisms to decide that its 4152 point of attachment has changed. Such indications include the Down/ 4153 Testing/Up interface status [41], and changes in cell or 4154 administration. The mechanisms will be specific to the particular 4155 link-layer technology, and are outside the scope of this document. 4157 The Point-to-Point-Protocol (PPP) [47] and its Internet Protocol 4158 Control Protocol (IPCP) [42], negotiates the use of IP addresses. 4160 The mobile node SHOULD first attempt to specify its home address, so 4161 that if the mobile node is attaching to its home network, the 4162 unrouted link will function correctly. When the home address is not 4163 accepted by the peer, but a transient IP address is dynamically 4164 assigned to the mobile node, and the mobile node is capable of 4165 supporting a co-located care-of address, the mobile node MAY register 4166 that address as a co-located care-of address. When the peer 4167 specifies its own IP address, that address MUST NOT be assumed to be 4168 a foreign agent care-of address or the IP address of a home agent. 4169 PPP extensions for Mobile IP have been specified in RFC 2290 [23]. 4170 Please consult that document for additional details for how to handle 4171 care-of address assignment from PPP in a more efficient manner. 4173 Appendix C. TCP Considerations 4175 C.1. TCP Timers 4177 When high-delay (e.g. SATCOM) or low-bandwidth (e.g. High-Frequency 4178 Radio) links are in use, some TCP stacks may have insufficiently 4179 adaptive (non-standard) retransmission timeouts. There may be 4180 spurious retransmission timeouts, even when the link and network are 4181 actually operating properly, but just with a high delay because of 4182 the medium in use. This can cause an inability to create or maintain 4183 TCP connections over such links, and can also cause unneeded 4184 retransmissions which consume already scarce bandwidth. Vendors are 4185 encouraged to follow the algorithms in RFC 2988 [26] when 4186 implementing TCP retransmission timers. Vendors of systems designed 4187 for low-bandwidth, high-delay links should consult RFCs 2757 and 2488 4188 [24], [25]. Designers of applications targeted to operate on mobile 4189 nodes should be sensitive to the possibility of timer-related 4190 difficulties. 4192 C.2. TCP Congestion Management 4194 Mobile nodes often use media which are more likely to introduce 4195 errors, effectively causing more packets to be dropped. This 4196 introduces a conflict with the mechanisms for congestion management 4197 found in modern versions of TCP [40]. Now, when a packet is dropped, 4198 the correspondent node's TCP implementation is likely to react as if 4199 there were a source of network congestion, and initiate the slow- 4200 start mechanisms [40] designed for controlling that problem. 4201 However, those mechanisms are inappropriate for overcoming errors 4202 introduced by the links themselves, and have the effect of magnifying 4203 the discontinuity introduced by the dropped packet. This problem has 4204 been analyzed by Caceres, et al. [32]. TCP approaches to the problem 4205 of handling errors that might interfere with congestion management 4206 are discussed in documents from the [pilc] working group [31] [33]. 4207 While such approaches are beyond the scope of this document, they 4208 illustrate that providing performance transparency to mobile nodes 4209 involves understanding mechanisms outside the network layer. 4210 Problems introduced by higher media error rates also indicate the 4211 need to avoid designs which systematically drop packets; such designs 4212 might otherwise be considered favorably when making engineering 4213 tradeoffs. 4215 Appendix D. Example Scenarios 4217 This section shows example Registration Requests for several common 4218 scenarios. 4220 D.1. Registering with a Foreign Agent Care-of Address 4222 The mobile node receives an Agent Advertisement from a foreign agent 4223 and wishes to register with that agent using the advertised foreign 4224 agent care-of address. The mobile node wishes only IP-in-IP 4225 encapsulation, does not want broadcasts, and does not want 4226 simultaneous mobility bindings: 4228 IP fields: 4229 Source Address = mobile node's home address 4230 Destination Address = copied from the IP source address of the 4231 Agent Advertisement 4232 Time to Live = 1 4233 UDP fields: 4234 Source Port = 4235 Destination Port = 434 4236 Registration Request fields: 4237 Type = 1 4238 S=0,B=0,D=0,M=0,G=0 4239 Lifetime = the Registration Lifetime copied from the 4240 Mobility Agent Advertisement Extension of the 4241 Router Advertisement message 4242 Home Address = the mobile node's home address 4243 Home Agent = IP address of mobile node's home agent 4244 Care-of Address = the Care-of Address copied from the 4245 Mobility Agent Advertisement Extension of the 4246 Router Advertisement message 4247 Identification = Network Time Protocol timestamp or Nonce 4248 Extensions: 4249 An authorization-enabling extension (e.g., the Mobile-Home 4250 Authentication Extension) 4252 D.2. Registering with a Co-Located Care-of Address 4254 The mobile node enters a foreign network that contains no foreign 4255 agents. The mobile node obtains an address from a DHCP server [34] 4256 for use as a co-located care-of address. The mobile node supports 4257 all forms of encapsulation (IP-in-IP, minimal encapsulation, and 4258 GRE), desires a copy of broadcast datagrams on the home network, and 4259 does not want simultaneous mobility bindings: 4261 IP fields: 4262 Source Address = care-of address obtained from DHCP server 4263 Destination Address = IP address of home agent 4264 Time to Live = 64 4265 UDP fields: 4266 Source Port = 4267 Destination Port = 434 4268 Registration Request fields: 4269 Type = 1 4270 S=0,B=1,D=1,M=1,G=1 4271 Lifetime = 1800 (seconds) 4272 Home Address = the mobile node's home address 4273 Home Agent = IP address of mobile node's home agent 4274 Care-of Address = care-of address obtained from DHCP server 4275 Identification = Network Time Protocol timestamp or Nonce 4276 Extensions: 4277 The Mobile-Home Authentication Extension 4279 D.3. Deregistration 4281 The mobile node returns home and wishes to deregister all care-of 4282 addresses with its home agent. 4284 IP fields: 4285 Source Address = mobile node's home address 4286 Destination Address = IP address of home agent 4287 Time to Live = 1 4288 UDP fields: 4289 Source Port = 4290 Destination Port = 434 4291 Registration Request fields: 4292 Type = 1 4293 S=0,B=0,D=0,M=0,G=0 4294 Lifetime = 0 4295 Home Address = the mobile node's home address 4296 Home Agent = IP address of mobile node's home agent 4297 Care-of Address = the mobile node's home address 4298 Identification = Network Time Protocol timestamp or Nonce 4299 Extensions: 4300 An authorization-enabling extension (e.g., the Mobile-Home 4301 Authentication Extension) 4303 Appendix E. Applicability of Prefix-Lengths Extension 4305 Caution is indicated with the use of the Prefix-Lengths Extension 4306 over wireless links, due to the irregular coverage areas provided by 4307 wireless transmitters. As a result, it is possible that two foreign 4308 agents advertising the same prefix might indeed provide different 4309 connectivity to prospective mobile nodes. The Prefix-Lengths 4310 Extension SHOULD NOT be included in the advertisements sent by agents 4311 in such a configuration. 4313 Foreign agents using different wireless interfaces would have to 4314 cooperate using special protocols to provide identical coverage in 4315 space, and thus be able to claim to have wireless interfaces situated 4316 on the same subnetwork. In the case of wired interfaces, a mobile 4317 node disconnecting and subsequently connecting to a new point of 4318 attachment, may well send in a new Registration Request no matter 4319 whether the new advertisement is on the same medium as the last 4320 recorded advertisement. And, finally, in areas with dense 4321 populations of foreign agents it would seem unwise to require the 4322 propagation via routing protocols of the subnet prefixes associated 4323 with each individual wireless foreign agent; such a strategy could 4324 lead to quick depletion of available space for routing tables, 4325 unwarranted increases in the time required for processing routing 4326 updates, and longer decision times for route selection if routes 4327 (which are almost always unnecessary) are stored for wireless 4328 "subnets". 4330 Appendix F. Interoperability Considerations 4332 This document specifies revisions to RFC 2002 that are intended to 4333 improve interoperability by resolving ambiguities contained in the 4334 earlier text. Implementations that perform authentication according 4335 to the new more precisely specified algorithm would be interoperable 4336 with earlier implementations that did what was originally expected 4337 for producing authentication data. That was a major source of non- 4338 interoperability before. 4340 However, this specification does have new features that, if used, 4341 would cause interoperability problems with older implementations. 4342 All features specified in RFC 2002 will work with the new 4343 implementations, except for V-J compression [36]. The following list 4344 details some of the possible areas of compatibility problems that may 4345 be experienced by nodes conforming to this revised specification, 4346 when attempting to interoperate with nodes obeying RFC 2002. 4348 o A client that expects some of the newly mandatory features (like 4349 reverse tunneling) from a foreign agent would still be 4350 interoperable as long as it pays attention to the `T' bit. 4352 o Mobile nodes that use the NAI extension to identify themselves 4353 would not work with old mobility agents. 4355 o Mobile nodes that use a zero home address and expect to receive 4356 their home address in the Registration Reply would not work with 4357 old mobility agents. 4359 o Mobile nodes that attempt to authenticate themselves without using 4360 the Mobile-Home authentication extension will be unable to 4361 successful register with their home agent. 4363 In all of these cases, a robust and well-configured mobile node is 4364 very likely to be able to recover if it takes reasonable actions upon 4365 receipt of a Registration Reply with an error code indicating the 4366 cause for rejection. For instance, if a mobile node sends a 4367 registration request that is rejected because it contains the wrong 4368 kind of authentication extension, then the mobile node could retry 4369 the registration with a mobile-home authentication extension, since 4370 the foreign agent and/or home agent in this case will not be 4371 configured to demand the alternative authentication data. 4373 Appendix G. Changes since RFC 3344 4375 The following revisions to details of the specification in this 4376 document were made after RFC 3344 was published. A list of changes 4377 from RFC 2002 made during the development of RFC 3344 [21] may be 4378 found in the latter document. For items marked with issue numbers, 4379 more information is available by consulting the MIP4 mailing list 4380 archives. 4382 o Showed more bit definitions in the Agent Advertisement message 4383 structure (see Section 2.1.1). New advertisement bits have been 4384 defined by other specification documents, but not reflected in 4385 previous publications of this specification; this has led to 4386 confusion. Citations for the other specification documents have 4387 also been included. 4389 o (Issue 6) The behavior of the home agent was changed to avoid 4390 mandating error replies to Registration Requests that were 4391 invalidated because the foreign agent failed authentication. The 4392 intention is to make the home agent more robust against Denial of 4393 Service attacks in which the malicious device has no intention of 4394 providing a valid registration request but only wants to congest 4395 traffic on the home network. See section Section 3.8.2.1. 4397 o Due to non-unique assignment of IPv4 addresses in many domains, it 4398 is possible for different mobile nodes to have the same home 4399 address. If they use the NAI, the foreign agent can still 4400 distinguish them. Language was added to Section 3.7.1 and 4401 Section 3.7.3.1 to specify that the foreign agent MUST use the NAI 4402 to distinguish mobile nodes with the same home address. 4404 o (Issue 45) Specified that a foreign agent MUST NOT apply a 4405 Foreign-Home Authentication extension to a mobile node's 4406 deregistration request. Also, the foreign agent MUST NOT apply a 4407 Foreign-Home Authentication extension unless Care-of Address in 4408 the Registration Request matches an address advertised by the 4409 foreign agent. 4411 o Specified that the mobility security association to be used by the 4412 Foreign Agent and Home Agent depends upon values contained in the 4413 message data, not the IP headers. 4415 o (Issues 9, 18) Created a new error code for use by the foreign 4416 agent, for the case when the foreign agent does not serve the 4417 mobile node as a home agent. Formerly, the foreign agent could 4418 use error code 136 for this case. 4420 o (Issue 17) Specified that, if the Home Agent cannot support the 4421 requested nonzero unicast address in the Home Address field of the 4422 Registration Request, then the it MUST reject the registration 4423 with an error code of 129. See section Section 3.8.3.2. 4425 o (Issue 19) Specified that multiple authorization-enabling 4426 extensions may be present in the Registration Request message, but 4427 that the home agent has to (somehow) ensure that all have been 4428 checked (see section Section 3.8.3.1). 4430 o (Issue 20) Specified that the foreign agent SHOULD NOT modify any 4431 of the fields of the Registration Reply message that are covered 4432 by the Mobile-Home Authentication Extension, when it relays the 4433 packet to the mobile node. 4435 o (Issue 21) Clarified that the foreign agent removes extensions 4436 that do not precede any authorization-enabling extension, not just 4437 the Mobile-Home Authentication extension (section 3.7.3.2). 4439 o (Issue 44) Specified that the address advertised by the foreign 4440 agent in Agent Advertisements is the care-of address offered on 4441 that network interface, not necessarily the address of the network 4442 interface (section 3.7.2.2). 4444 o (Issue 45) Clarification in section 3.7.2.1 that code 77 can only 4445 apply to a Registration Request with nonzero lifetime. 4447 o Created a new error code for use when a Foreign Agent can detect 4448 that the Home Agent address field is incorrect. 4450 o Prohibited the use of the Foreign-Home Authorization Extension on 4451 deregistration messages. 4453 o Cleaned up some more wording having to do with authorization- 4454 enabling extensions. 4456 o For consistency, changed some wording about copying UDP ports. 4458 o Added wording to clearly not disallow dynamically configuring 4459 netmask and security information at the mobile node. 4461 o Revamped Changes section. 4463 o Updated citations. 4465 Appendix H. Example Messages 4467 H.1. Example ICMP Agent Advertisement Message Format 4469 0 1 2 3 4470 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 4471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4472 | Type | Code | Checksum | 4473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4474 | Num Addrs |Addr Entry Size| Lifetime | 4475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4476 | Router Address[1] | 4477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4478 | Preference Level[1] | 4479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4480 | Router Address[2] | 4481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4482 | Preference Level[2] | 4483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4484 | .... | 4485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4486 | Type = 16 | Length | Sequence Number | 4487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4488 | Registration Lifetime |R|B|H|F|M|G|r|T|U|X|I|reserved | 4489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4490 | Care-of Address[1] | 4491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4492 | Care-of Address[2] | 4493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4494 | .... | 4495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4496 : Optional Extensions : 4497 : .... ...... ...... : 4498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4500 H.2. Example Registration Request Message Format 4502 The UDP header is followed by the Mobile IP fields shown below: 4504 0 1 2 3 4505 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 4506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4507 | Type = 1 |S|B|D|M|G|r|T|x| Lifetime | 4508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4509 | Home Address | 4510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4511 | Home Agent | 4512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4513 | Care-of Address | 4514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4515 | | 4516 + Identification + 4517 | | 4518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4519 | Optional Non-Auth Extensions for HA ... | 4520 | ( variable length ) | 4521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4522 | Type =32 | Length | SPI | 4523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4524 | SPI (cont..) | | 4525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4526 : MN-HA Authenticator ( variable length ) : 4527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4528 : Optional Non-Auth Extensions for FA ......... 4529 : Optional MN-FA Authentication Extension... 4530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4532 H.3. Example Registration Reply Message Format 4534 The UDP header is followed by the Mobile IP fields shown below: 4536 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 4537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4538 | Type = 3 | Code | Lifetime | 4539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 | Home Address | 4541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4542 | Home Agent | 4543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4544 | | 4545 + Identification + 4546 | | 4547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4548 | Optional HA Non-Auth Extensions ... | 4549 | ( variable length ) | 4550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4551 | Type =32 | Length | SPI | 4552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4553 | SPI (cont...) | | 4554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4555 : MN-HA Authenticator ( variable length ) : 4556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4557 : Optional Extensions used by FA......... 4558 : Optional MN-FA Authentication Extension... 4559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4561 Author's Address 4563 Charles E. Perkins 4564 WiChorus Inc. 4565 3590 N. 1st Street, Suite 300 4566 San Jose, CA 95134 4567 USA 4569 Email: charliep@computer.org