idnits 2.17.1 draft-ietf-mobileip-ipv6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 November 1997) is 9646 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-10 == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-ipv6-spec-v2-00 -- Unexpected draft version: The latest known version of draft-ferguson-ingress-filtering is -02, but you're referring to -03. == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-02 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-01 == Outdated reference: A later version (-02) exists of draft-ietf-ipngwg-discovery-v2-00 ** Obsolete normative reference: RFC 2002 (ref. '13') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 793 (ref. '16') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '17') (Obsoleted by RFC 3232) == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-addrconf-v2-00 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group David B. Johnson 2 INTERNET-DRAFT Carnegie Mellon University 3 Charles Perkins 4 Sun Microsystems 5 21 November 1997 7 Mobility Support in IPv6 9 11 Status of This Memo 13 This document is a submission by the Mobile IP Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of current Internet-Drafts, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document specifies the operation of mobile computers using IPv6. 37 Each mobile node is always identified by its home address, regardless 38 of its current point of attachment to the Internet. While situated 39 away from its home, a mobile node is also associated with a care-of 40 address, which provides information about the mobile node's current 41 location. IPv6 packets addressed to a mobile node's home address are 42 transparently routed to its care-of address. The protocol enables 43 IPv6 nodes to cache the binding of a mobile node's home address with 44 its care-of address, and to then send packets destined for the mobile 45 node directly to it at this care-of address. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Comparison with Mobile IP for IPv4 3 57 3. Terminology 4 58 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Specification Language . . . . . . . . . . . . . . . . . 6 62 4. Overview of Mobile IPv6 7 63 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 9 65 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 10 66 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 13 68 5. New IPv6 Destination Options 15 69 5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 15 70 5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 19 71 5.3. Binding Request Option . . . . . . . . . . . . . . . . . 23 72 5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 24 74 6. Requirements for IPv6 Nodes 26 76 7. Correspondent Node Operation 28 77 7.1. Receiving Packets from a Mobile Node . . . . . . . . . . 28 78 7.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 28 79 7.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 29 80 7.4. Requests to Delete a Binding . . . . . . . . . . . . . . 30 81 7.5. Sending Binding Acknowledgements . . . . . . . . . . . . 30 82 7.6. Sending Binding Requests . . . . . . . . . . . . . . . . 30 83 7.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 31 84 7.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 32 85 7.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 33 87 8. Home Agent Operation 35 88 8.1. Dynamic Home Agent Address Discovery . . . . . . . . . . 35 89 8.2. Primary Care-of Address Registration . . . . . . . . . . 35 90 8.3. Primary Care-of Address De-registration . . . . . . . . . 38 91 8.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 38 92 8.5. Renumbering the Home Subnet . . . . . . . . . . . . . . . 39 94 9. Mobile Node Operation 41 95 9.1. Sending Packets While Away from Home . . . . . . . . . . 41 96 9.2. Movement Detection . . . . . . . . . . . . . . . . . . . 42 97 9.3. Forming New Care-of Addresses . . . . . . . . . . . . . . 45 98 9.4. Sending Binding Updates to the Home Agent . . . . . . . . 46 99 9.5. Sending Binding Updates to Correspondent Nodes . . . . . 47 100 9.6. Sending Binding Updates to the Previous Default Router . 49 101 9.7. Retransmitting Binding Updates . . . . . . . . . . . . . 50 102 9.8. Rate Limiting for Sending Binding Updates . . . . . . . . 50 103 9.9. Receiving ICMP Errors in Response to Binding Updates . . 50 104 9.10. Receiving Binding Acknowledgements . . . . . . . . . . . 50 105 9.11. Receiving Binding Requests . . . . . . . . . . . . . . . 51 106 9.12. Using Multiple Care-of Addresses . . . . . . . . . . . . 52 107 9.13. Returning Home . . . . . . . . . . . . . . . . . . . . . 52 109 10. Routing Multicast Packets 54 111 11. Constants 55 113 12. IANA Considerations 56 115 13. Security Considerations 57 116 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 57 117 13.2. Home Address Options . . . . . . . . . . . . . . . . . . 57 118 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 58 120 Appendix A. Changes from Previous Draft 60 122 Acknowledgements 62 124 References 63 126 Chair's Address 65 128 Authors' Addresses 66 129 1. Introduction 131 This document specifies the operation of mobile computers using 132 Internet Protocol Version 6 (IPv6) [5]. Without specific support 133 for mobility in IPv6, packets destined to a mobile node (host or 134 router) would not be able to reach it while the mobile node is away 135 from its home link (the link on which its home IPv6 subnet prefix is 136 in use), since routing is based on the subnet prefix in a packet's 137 destination IP address. In order to continue communication in spite 138 of its movement, a mobile node could change its IP address each time 139 it moves to a new link, but the mobile node would then not be able 140 to maintain transport and higher-layer connections when it changes 141 location. Mobility support in IPv6 is particularly important, as 142 mobile computers are likely to account for a majority or at least a 143 substantial fraction of the population of the Internet during the 144 lifetime of IPv6. 146 The protocol operation defined here, known as Mobile IPv6, allows a 147 mobile node to move from one link to another without changing the 148 mobile node's IP address. A mobile node is always addressable by 149 its "home address", an IP address assigned to the mobile node within 150 its home subnet prefix on its home link. Packets may be routed to 151 the mobile node using this address regardless of the mobile node's 152 current point of attachment to the Internet, and the mobile node may 153 continue to communicate with other nodes (stationary or mobile) after 154 moving to a new link. The movement of a mobile node away from its 155 home link is thus transparent to transport and higher-layer protocols 156 and applications. 158 The Mobile IPv6 protocol is just as suitable for mobility across 159 homogeneous media as for mobility across heterogeneous media. For 160 example, Mobile IPv6 facilitates node movement from one Ethernet 161 segment to another as well as it facilitates node movement from an 162 Ethernet segment to a wireless LAN cell, with the mobile node's IP 163 address remaining unchanged in spite of such movement. 165 One can think of the Mobile IPv6 protocol as solving the "macro" 166 mobility management problem. More "micro" mobility management 167 applications -- for example, handoff among wireless transceivers, 168 each of which covers only a very small geographic area -- are 169 possibly more suited to other solutions. For example, in many 170 current wireless LAN products, link-layer mobility mechanisms allow a 171 "handoff" of a mobile node from one cell to another, reestablishing 172 link-layer connectivity to the node in each new location. As long 173 as such handoff occurs only within cells of the mobile node's home 174 link, such link-layer mobility mechanisms are likely to offer faster 175 convergence and lower overhead than Mobile IPv6. Extensions to the 176 Mobile IPv6 protocol are also possible to support a more local, 177 hierarchical form of mobility management, but such extensions are 178 beyond the scope of this document. 180 The protocol specified in this document solves the problem of 181 transparently routing packets to and from mobile nodes while away 182 from home. However, it does not attempt to solve all general 183 problems related to the use of mobile computers or wireless networks. 184 In particular, this protocol does not attempt to solve: 186 - Handling links with partial reachability, such as typical 187 wireless networks. Some aspects of this problem are addressed 188 by the movement detection procedure described in Section 9.2, 189 but no attempt has been made to fully solve this problem in its 190 general form. Most aspects of this problem can be solved by the 191 workaround of restricting such networks to only one router per 192 link, although there are still possible hidden terminal problems 193 when two nodes on the same link (on opposite sides of the router) 194 attempt to communicate directly. 196 - Access control on a link being visited by a mobile node. This 197 is a general problem any time an untrusted node is allowed 198 to connect to any link layer. It is independent whether the 199 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 200 address on the link. 202 2. Comparison with Mobile IP for IPv4 204 [This section will include a comparison between the Mobile IPv6 205 protocol and the Mobile IPv4 protocol [13, 12, 14]. However, this 206 comparison has not yet been written. It will be filled in with the 207 next revision to this draft.] 209 3. Terminology 211 3.1. General Terms 213 IP 215 Internet Protocol Version 6 (IPv6). 217 node 219 A device that implements IP. 221 router 223 A node that forwards IP packets not explicitly addressed to 224 itself. 226 host 228 Any node that is not a router. 230 link 232 A communication facility or medium over which nodes can 233 communicate at the link layer, such as an Ethernet (simple or 234 bridged). A link is the layer immediately below IP. 236 interface 238 A node's attachment to a link. 240 subnet prefix 242 A bit string that consists of some number of initial bits of an 243 IP address. 245 link-layer address 247 A link-layer identifier for an interface, such as IEEE 802 248 addresses on Ethernet links. 250 packet 252 An IP header plus payload. 254 3.2. Mobile IPv6 Terms 256 home address 258 An IP address assigned to a mobile node within its home link. 260 home subnet prefix 262 The IP subnet prefix corresponding to a mobile node's home 263 address. 265 home link 267 The link on which a mobile node's home subnet prefix is 268 defined. Standard IP routing mechanisms will deliver packets 269 destined for a mobile node's home address to its home link. 271 mobile node 273 A node that can change its point of attachment from one link to 274 another, while still being reachable via its home address. 276 movement 278 A change in a mobile node's point of attachment to the Internet 279 such that it is no longer connected to the same link as it was 280 previously. If a mobile node is not currently attached to its 281 home link, the mobile node is said to be "away from home". 283 correspondent node 285 A peer node with which a mobile node is communicating. The 286 correspondent node may be either mobile or stationary. 288 foreign subnet prefix 290 Any IP subnet prefix other than the mobile node's home subnet 291 prefix. 293 foreign link 295 Any link other than the mobile node's home link. 297 home agent 299 A router on a mobile node's home link with which the mobile 300 node has registered its current care-of address. While the 301 mobile node is away from home, the home agent intercepts 302 packets on the home link destined to the mobile node's home 303 address, encapsulates them, and tunnels them to the mobile 304 node's registered care-of address. 306 care-of address 308 An IP address associated with a mobile node while visiting a 309 foreign link; the subnet prefix of this IP address is a foreign 310 subnet prefix. Among the multiple care-of addresses that a 311 mobile node may have at a time (e.g., with different subnet 312 prefixes), the one registered with the mobile node's home agent 313 is called its "primary" care-of address. 315 binding 317 The association of the home address of a mobile node with a 318 care-of address for that mobile node, along with the remaining 319 lifetime of that association. 321 3.3. Specification Language 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 325 document are to be interpreted as described in RFC 2119 [3]. 327 4. Overview of Mobile IPv6 329 4.1. Basic Operation 331 A mobile node is always addressable by its home address, whether it 332 is currently attached to its home link or is away from home. While 333 a mobile node is at home, packets addressed to its home address are 334 routed to it using conventional Internet routing mechanisms in the 335 same way as if the node were never mobile. Since the subnet prefix 336 of a mobile node's home address is the subnet prefix (or one of the 337 subnet prefixes) on the mobile node's home link (it is the mobile 338 node's home subnet prefix), packets addressed to it will be routed to 339 its home link. 341 While a mobile node is attached to some foreign link away from 342 home, it is also addressable by one or more care-of addresses, in 343 addition to its home address. A care-of address is an IP address 344 associated with a mobile node while visiting a particular foreign 345 link. The subnet prefix of a mobile node's care-of address is the 346 subnet prefix (or one of the subnet prefixes) on the foreign link 347 being visited by the mobile node; if the mobile node is connected 348 to this foreign link while using that care-of address, packets 349 addressed to this care-of address will be routed to the mobile node 350 in its location away from home. The association between a mobile 351 node's home address and care-of address is known as a "binding" 352 for the mobile node. A mobile node typically acquires its care-of 353 address through stateless [18] or stateful (e.g., DHCPv6 [2]) 354 address autoconfiguration, according to the methods of IPv6 Neighbor 355 Discovery [11]. Other methods of acquiring a care-of address 356 are also possible, but such methods are beyond the scope of this 357 document. 359 While away from home, the mobile node registers one of its bindings 360 with a router on its home link, requesting this router to function 361 as the "home agent" for the mobile node. This binding registration 362 is done by the mobile node sending a packet with a "Binding Update" 363 destination option to the home agent, which replies by returning a 364 packet containing a "Binding Acknowledgement" destination option to 365 the mobile node. The care-of address in this binding registered 366 with its home agent is known as the mobile node's "primary care-of 367 address". The mobile node's home agent thereafter uses proxy 368 Neighbor Discovery to intercept any IPv6 packets addressed to the 369 mobile node's home address (or home addresses) on the home link, 370 and tunnels each intercepted packet to the mobile node's primary 371 care-of address. To tunnel each intercepted packet, the home agent 372 encapsulates the packet using IPv6 encapsulation [4], addressed to 373 the mobile node's primary care-of address. 375 The Binding Update and Binding Acknowledgement destination options, 376 together with a "Binding Request" destination option, are also used 377 to allow IPv6 nodes communicating with a mobile node, to dynamically 378 learn and cache the mobile node's binding. When sending a packet 379 to any IPv6 destination, a node checks its cached bindings for an 380 entry for the packet's destination address. If a cached binding for 381 this destination address is found, the node uses an IPv6 Routing 382 header [5] (instead of IPv6 encapsulation) to route the packet to 383 the mobile node by way of the care-of address indicated in this 384 binding. If, instead, the sending node has no cached binding for 385 this destination address, the node sends the packet normally (with 386 no Routing header), and the packet is subsequently intercepted and 387 tunneled by the mobile node's home agent as described above. A node 388 communicating with a mobile node is referred to in this document as a 389 "correspondent node" of the mobile node. 391 Since a Binding Update, Binding Acknowledgement, and Binding Request 392 are each represented in a packet as an IPv6 destination option [5], 393 they may be included in any IPv6 packet. Any of these options can be 394 sent in either of two ways: 396 - A Binding Update, Binding Acknowledgement, or Binding Request can 397 be included within any IPv6 packet carrying any payload such as 398 TCP [16] or UDP [15]. 400 - A Binding Update, Binding Acknowledgement, or Binding Request can 401 be sent as a separate IPv6 packet containing no payload. In this 402 case, the Next Header field in the last extension header in the 403 packet is set to the value 59, to indicate "No Next Header" [5]. 405 Mobile IPv6 also defines one additional IPv6 destination option. 406 When a mobile node sends a packet while away from home, it will 407 generally set the Source Address in the packet's IPv6 header to one 408 of its current care-of addresses, and will also include a "Home 409 Address" destination option in the packet, giving the mobile node's 410 home address. Many routers implement security policies such as 411 "ingress filtering" [6] that do not allow forwarding of packets 412 that appear to have a Source Address that is not topologically 413 correct. By using the care-of address as the IPv6 header Source 414 Address, the packet will be able to pass normally through such 415 routers, yet ingress filtering rules will still be able to locate 416 the true physical source of the packet in the same way as packets 417 from non-mobile nodes. By also including the Home Address option, 418 the sending mobile node can communicate its home address to the 419 correspondent node receiving this packet, allowing the use of the 420 care-of address to be transparent above the Mobile IPv6 support 421 level (e.g., at the transport layer). The inclusion of a Home 422 Address option in a packet affects only the correspondent node's 423 receipt of this single packet; no state is created or modified in the 424 correspondent node as a result of receiving a Home Address option in 425 a packet. 427 4.2. New IPv6 Destination Options 429 As discussed in general in Section 4.1, the following four new IPv6 430 destination options are defined for Mobile IPv6: 432 Binding Update 434 A Binding Update option is used by a mobile node to notify 435 a correspondent node or the mobile node's home agent of 436 its current binding. The Binding Update sent to the mobile 437 node's home agent to register its primary care-of address is 438 marked as a "home registration". Any packet that includes a 439 Binding Update option MUST also include either an AH [7] or 440 ESP [8] header providing sender authentication, data integrity 441 protection, and replay protection. The Binding Update option 442 is described in detail in Section 5.1. 444 Binding Acknowledgement 446 A Binding Acknowledgement option is used to acknowledge receipt 447 of a Binding Update, if an acknowledgement was requested 448 in the Binding Update. Any packet that includes a Binding 449 Acknowledgement option MUST also include either an AH [7] or 450 ESP [8] header providing sender authentication, data integrity 451 protection, and replay protection. The Binding Acknowledgement 452 option is described in detail in Section 5.2. 454 Binding Request 456 A Binding Request option is used to request a mobile node 457 to send a Binding Update to the requesting node, containing 458 the mobile node's current binding. This option is typically 459 used by a correspondent node to refresh a cached binding for 460 a mobile node, when the cached binding is in active use but 461 the binding's lifetime is close to expiration. No special 462 authentication is required for the Binding Request option. The 463 Binding Request option is described in detail in Section 5.3. 465 Home Address 467 A Home Address option is used in a packet sent by a mobile 468 node to inform the recipient of that packet of the mobile 469 node's home address. For packets sent by a mobile node while 470 away from home, the mobile node generally uses one of its 471 care-of addresses as the Source Address in the packet's IPv6 472 header. By including a Home Address option in the packet, the 473 correspondent node receiving the packet is able to substitute 474 the mobile node's home address for this care-of address when 475 processing the packet, thus making the use of the care-of 476 address transparent to the correspondent node. If the IP 477 header of a packet carrying a Home Address option is covered 478 by authentication, then the Home Address option MUST also 479 be covered by this authentication, but no other special 480 authentication is required for the Home Address option. The 481 Home Address option is described in detail in Section 5.4. 483 Extensions to the format of these options MAY be included after the 484 fixed portion of the option data specified in this document. The 485 presence of such extensions will be indicated by the Option Length 486 field within the option. When the Option Length is greater than the 487 length required for the option specified here, the remaining octets 488 are interpreted as extensions. Currently, no extensions have been 489 defined. 491 4.3. Conceptual Data Structures 493 This document describes the Mobile IPv6 protocol in terms of the 494 following two conceptual data structures used in the maintenance of 495 cached bindings: 497 Binding Cache 499 A cache, maintained by each IPv6 node, of bindings for 500 other nodes. The Binding Cache MAY be implemented in any 501 manner consistent with the external behavior described 502 in this document, for example by being combined with the 503 node's Destination Cache as maintained through Neighbor 504 Discovery [11]. When sending a packet, the Binding Cache 505 MUST be searched before the Neighbor Discovery conceptual 506 Destination Cache [11]. Each Binding Cache entry conceptually 507 contains the following fields: 509 - The home address of the mobile node for which this is the 510 Binding Cache entry. This field is used as the key for 511 searching the Binding Cache for the destination address of 512 a packet being routed. If the destination address of the 513 packet matches the home address in the Binding Cache entry, 514 this entry SHOULD be used in routing that packet. 516 - The care-of address for the mobile node indicated by 517 the home address field in this Binding Cache entry. If 518 the destination address of a packet being routed by a 519 node matches the home address in this entry, the packet 520 SHOULD be routed to this care-of address, as described in 521 Section 7.9, for packets originated by this node, or in 522 Section 8.4, if this node is the mobile node's home agent 523 and the packet was intercepted by it on the home link. 525 - A lifetime value, indicating the remaining lifetime 526 for this Binding Cache entry. The lifetime value is 527 initialized from the Lifetime field in the Binding Update 528 that created or last modified this Binding Cache entry. 529 Once the lifetime on this entry expires, the entry MUST be 530 deleted from the Binding Cache. 532 - A flag indicating whether or not this Binding Cache entry 533 is a "home registration" entry. 535 - The value of ID Length field received in the Binding Update 536 that created or last modified this Binding Cache entry. 538 - The maximum value of the Sequence Number field received in 539 previous Binding Updates for this mobile node home address. 540 All comparisons between Sequence Number values MUST be 541 performed modulo 2**16. 543 - Recent usage information for this Binding Cache entry, 544 as needed for the cache replacement policy in use in the 545 Binding Cache and to assist in determining whether a 546 Binding Request should be sent when the lifetime on this 547 entry nears expiration. 549 - The time at which a Binding Request was last sent for this 550 entry, as needed to implement the rate limiting restriction 551 for sending Binding Requests. 553 An entry in a node's Binding Cache for which the node is 554 serving as a home agent is marked as a "home registration" 555 entry and SHOULD NOT be deleted by the home agent until the 556 expiration of its binding lifetime. Other Binding Cache 557 entries MAY be replaced at any time by any reasonable local 558 cache replacement policy but SHOULD NOT be unnecessarily 559 deleted. Any node's Binding Cache may contain at most one 560 entry for each mobile node home address. The contents of a 561 node's Binding Cache MUST NOT be changed in response to a Home 562 Address option in a received packet. 564 Binding Update List 566 A list, maintained by each mobile node, recording information 567 for each Binding Update sent by this mobile node, for which 568 the Lifetime sent in that Binding Update has not yet expired. 569 The Binding Update List includes all bindings sent by the 570 mobile node: those to correspondent nodes, to the mobile 571 node's home agent, and to a previous default router of the 572 mobile node. The Binding Update List MAY be implemented in any 573 manner consistent with the external behavior described in this 574 document. Each Binding Update List entry conceptually contains 575 the following fields: 577 - The IP address of the node to which a Binding Update was 578 sent. This node might still have a Binding Cache entry 579 derived from this binding update, if the Binding Update was 580 successfully received by that node (e.g., not lost by the 581 network) and if that node has not deleted the entry before 582 its expiration (e.g., to reclaim space in its Binding Cache 583 for other entries). 585 - The home address for which that Binding Update was sent. 586 This will be the mobile node's home address for most 587 Binding Updates (Sections 9.4 and 9.5), but will be 588 the mobile node's previous care-of address for Binding 589 Updates sent to the mobile node's previous default router 590 (Section 9.6). 592 - The care-of address sent in that Binding Update. This 593 value is necessary for determining if the mobile node has 594 sent a Binding Update giving its new care-of address to 595 this destination after changing its care-of address. 597 - The remaining lifetime of that binding. This lifetime is 598 initialized from the Lifetime value sent in the Binding 599 Update and is decremented until it reaches zero, at which 600 time this entry MUST be deleted from the binding update 601 list. 603 - The maximum value of the Sequence Number field sent 604 in previous Binding Updates to this destination. All 605 comparisons between Sequence Number values MUST be 606 performed modulo 2**16. 608 - The state of any retransmissions needed for this Binding 609 Update, if the Acknowledge (A) bit was set in this Binding 610 Update. This state includes the time remaining until the 611 next retransmission attempt for the Binding Update, and 612 the current state of the exponential back-off process for 613 retransmissions. 615 - The time at which a Binding Update was last sent to this 616 destination, as needed to implement the rate limiting 617 restriction for sending Binding Updates. 619 - A flag that, when set, indicates that future Binding 620 Updates should not be sent to this destination. The 621 mobile node sets this flag in the Binding Update List 622 entry when it receives an ICMP Parameter Problem, Code 2, 623 error message in response to a Binding Update sent to that 624 destination, as described in Section 9.9. 626 4.4. Binding Management 628 When a mobile node configures a new care-of address and decides to 629 use this new address as its primary care-of address, the mobile 630 node registers this new binding with its home agent by sending 631 the home agent a Binding Update. The mobile node indicates 632 that an acknowledgement is needed for this Binding Update and 633 continues to periodically retransmit it until acknowledged. The 634 home agent acknowledges the Binding Update by returning a Binding 635 Acknowledgement to the mobile node. 637 When a mobile node receives a packet tunneled to it from its 638 home agent, the mobile node assumes that the original sending 639 correspondent node has no Binding Cache entry for the mobile node, 640 since the correspondent node would otherwise have sent the packet 641 directly to the mobile node using a Routing header. The mobile node 642 thus returns a Binding Update to the correspondent node, allowing 643 it to cache the mobile node's binding for routing future packets. 644 Although the mobile node may request an acknowledgement for this 645 Binding Update, it need not, since subsequent packets from the 646 correspondent node will continue to be intercepted and tunneled by 647 the mobile node's home agent, effectively causing any needed Binding 648 Update retransmission. 650 A correspondent node with a Binding Cache entry for a mobile node 651 may refresh this binding, for example if the binding's lifetime 652 is near expiration, by sending a Binding Request to the mobile 653 node. Normally, a correspondent node will only refresh a Binding 654 Cache entry in this way if it is actively communicating with the 655 mobile node and has indications, such as an open TCP connection to 656 the mobile node, that it will continue this communication in the 657 future. When a mobile node receives a Binding Request, it replies by 658 returning a Binding Update to the node sending the Binding Request. 660 A mobile node may use more than one care-of address at the same 661 time, although only one care-of address may be registered for it at 662 its home agent as its primary care-of address. The mobile node's 663 home agent will tunnel all intercepted packets for the mobile node 664 to its (single) registered primary care-of address, but the mobile 665 node will accept packets that it receives at any of its current 666 care-of addresses. Use of more than one care-of address by a mobile 667 node may be useful, for example, to improve smooth handoff when the 668 mobile node moves from one wireless link to another. If each of 669 these wireless links is connected to the Internet through a separate 670 base station, such that the wireless transmission range from the 671 two base stations overlap, the mobile node may be able to remain 672 connected to both links while in the area of overlap. In this case, 673 the mobile node could acquire a new care-of address on the new link 674 before moving out of transmission range and disconnecting from the 675 old link. The mobile node may thus still accept packets at its 676 old care-of address while it works to update its home agent and 677 correspondent nodes, notifying them of its new care-of address on the 678 new link. 680 Since correspondent nodes cache bindings, it is expected that 681 correspondent nodes usually will route packets directly to the mobile 682 node's care-of address, so that the home agent is rarely involved 683 with packet transmission to the mobile node. This is essential for 684 scalability and reliability, and for minimizing overall network load. 685 By caching the care-of address of a mobile node, optimal routing of 686 packets can be achieved from the correspondent node to the mobile 687 node. Routing packets directly to the mobile node's care-of address 688 also eliminates congestion at the mobile node's home agent and home 689 link. In addition, the impact of of any possible failure of the home 690 agent, the home link, or intervening networks leading to or from the 691 home link is reduced, since these nodes and links are not involved in 692 the delivery of most packets to the mobile node. 694 5. New IPv6 Destination Options 696 5.1. Binding Update Option 698 The Binding Update destination option is used by a mobile node to 699 notify other nodes of a new care-of address. 701 The Binding Update option is encoded in type-length-value (TLV) 702 format as follows: 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Option Type | Option Length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 |A|H|C| Reserved| ID Length | Sequence Number | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Lifetime | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | | 714 + + 715 | | 716 + Care-of Address + 717 | (only present if C bit set) | 718 + + 719 | | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Option Type 724 195 ??? 726 Option Length 728 8-bit unsigned integer. Length of the option, in octets, 729 excluding the Option Type and Option Length fields. For the 730 current definition of the Binding Update option, the minimum 731 value for this field is 8; this length is increased by 8 if the 732 Care-of Address Present (C) bit is set. 734 Acknowledge (A) 736 The Acknowledge (A) bit is set by the sending node to request a 737 Binding Acknowledgement (Section 5.2) be returned upon receipt 738 of the Binding Update option. 740 Home Registration (H) 742 The Home Registration (H) bit is set by the sending mobile node 743 to request the receiving node to act as this node's home agent. 745 The Destination Address in the IP header of the packet carrying 746 this option MUST be that of a router sharing the same subnet 747 prefix as the home address of the mobile node in the binding 748 (given by the Home Address field in the Home Address option in 749 the packet). 751 Care-of Address Present (C) 753 The Care-of Address Present (C) bit indicates the presence of 754 the Care-of Address field in the Binding Update. The care-of 755 address for this binding is either the address in the Care-of 756 Address field in the Binding Update, if this bit is set, or the 757 Source Address in the packet's IPv6 header, if this bit is not 758 set. 760 Reserved 762 Sent as 0; ignored on reception. 764 ID Length 766 The ID Length field is valid only for a "home registration" 767 Binding Update. This field MUST be zero if the Home 768 Registration (H) bit is not set in the Binding Update. The 769 ID Length field is set by the sending mobile node to the 770 (nonzero) length of its interface identifier in its home 771 address (given in the Home Address option in the packet) to 772 request its home agent to use this interface identifier to form 773 all other appropriate home addresses for the mobile node. The 774 home agent becomes the home agent not only for the individual 775 home address given in this binding, but also for all other 776 home addresses for this mobile node formed from this interface 777 identifier. That is, for each on-link prefix on the home link, 778 the home agent uses this interface identifier to form other 779 valid addresses for the mobile node on the home link, and acts 780 as a home agent also for those addresses. In addition, the 781 home agent forms the link-local address and site-local address 782 corresponding to this interface identifier, and defends each 783 for purposes of Duplicate Address Detection. Details of this 784 operation are described in Section 8.2. 786 Sequence Number 788 Used by the receiving node to sequence Binding Updates and by 789 the sending node to match a returned Binding Acknowledgement 790 with this Binding Update. Each Binding Update sent by a mobile 791 node MUST use a Sequence Number greater than the Sequence 792 Number value sent in the previous Binding Update (if any) to 793 the same destination address (modulo 2**16). There is no 794 requirement, however, that the Sequence Number value strictly 795 increase by 1 with each new Binding Update sent or received. 797 Lifetime 799 32-bit unsigned integer. The number of seconds remaining 800 before the binding must be considered expired. A value of all 801 one bits (0xffffffff) indicates infinity. A value of zero 802 indicates that the Binding Cache entry for the mobile node 803 should be deleted. 805 Care-of Address 807 This field in the Binding Update is optional and is only 808 present when the Care-of Address Present (C) bit is set. If 809 present, it gives the care-of address of the mobile node for 810 this binding. For most Binding Updates sent, it is expected 811 that this field will not be present, and instead that the 812 care-of address for the binding will be given by the Source 813 Address field in the packet's IPv6 header. 815 Any packet including a Binding Update option MUST also include a Home 816 Address option. The home address of the mobile node in the binding 817 given in the Binding Update option is indicated by the Home Address 818 field in the Home Address option in the packet. 820 Any packet that includes a Binding Update option MUST also include 821 either an AH [7] or ESP [8] header providing sender authentication, 822 data integrity protection, and replay protection. 824 If the care-of address in the binding (either the Care-of Address 825 field in the Binding Update option or the Source Address field in 826 the packet's IPv6 header) is equal to the home address of the mobile 827 node, the Binding Update option indicates that any existing binding 828 for the mobile node should be deleted. Likewise, if the Lifetime 829 field in the Binding Update option is equal to 0, the Binding Update 830 option indicates that any existing binding for the mobile node should 831 be deleted. In each of these cases, no Binding Cache entry for the 832 mobile node should be created in response to receiving the Binding 833 Update. 835 The last Sequence Number value sent to a destination is stored by the 836 mobile node in the Binding Update List entry for that destination; 837 the last Sequence Number value received from a mobile node is stored 838 by a correspondent node in the Binding Cache entry for that mobile 839 node. Thus, the mobile node's and the correspondent node's knowledge 840 of the last sequence number expire at the same time. If the sending 841 mobile node has no Binding Update List entry, the Sequence Number 842 may start at any value; if the receiving correspondent node has no 843 Binding Cache entry, it should accept a Binding Update with any 844 Sequence Number value. 846 The three highest-order bits of the Option Type are encoded to 847 indicate specific processing of the option [5]. For the Binding 848 Update option, these three bits are set to 110, indicating that any 849 IPv6 node processing this option that does not recognize the Option 850 Type must discard the packet and, only if the packet's Destination 851 Address was not a multicast address, return an ICMP Parameter 852 Problem, Code 2, message to the packet's Source Address; and that the 853 data within the option cannot change en-route to the packet's final 854 destination. 856 Extensions to the Binding Update option format may be included after 857 the fixed portion of the Binding Update option specified above. 858 The presence of such extensions will be indicated by the Option 859 Length field. When the Option Length is greater than the length 860 defined above, the remaining octets are interpreted as extensions. 861 Currently, no extensions have been defined. 863 5.2. Binding Acknowledgement Option 865 The Binding Acknowledgement destination option is used to acknowledge 866 receipt of a Binding Update option (Section 5.1). When a node 867 receives a packet containing a Binding Update option, with this 868 node being the destination node of the packet, this node MUST 869 return a Binding Acknowledgement to the source of the packet, if the 870 Acknowledge (A) bit is set in the Binding Update. 872 The Binding Acknowledgement option is encoded in type-length-value 873 (TLV) format as follows: 875 0 1 2 3 876 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 877 +-+-+-+-+-+-+-+-+ 878 | Option Type | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Option Length | Status | Sequence Number | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Lifetime | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Refresh | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Option Type 889 2 ??? 891 Option Length 893 8-bit unsigned integer. Length of the option, in octets, 894 excluding the Option Type and Option Length fields. For the 895 current definition of the Binding Acknowledgement option, this 896 field MUST be set to 12. 898 Status 900 8-bit unsigned integer indicating the disposition of the 901 Binding Update. Values of the Status field less than 128 902 indicate that the Binding Update was accepted by the receiving 903 node. The following such Status values are currently defined: 905 0 Binding Update accepted 907 Values of the Status field greater than or equal to 128 908 indicate that the Binding Update was rejected by the receiving 909 node. The following such Status values are currently defined: 911 128 Reason unspecified 912 129 Poorly formed Binding Update 913 130 Administratively prohibited 914 131 Insufficient resources 915 132 Home registration not supported 916 133 Not home subnet 917 134 Sequence Number field value too small 918 135 Dynamic home agent address discovery response 919 136 Incorrect interface identifier length 921 Up-to-date values of the Status field are to be specified in 922 the most recent "Assigned Numbers" [17]. 924 Sequence Number 926 The Sequence Number in the Binding Acknowledgement is copied 927 from the Sequence Number field in the Binding Update option, 928 for use by the mobile node in matching this Acknowledgement 929 with an outstanding Binding Update. 931 Lifetime 933 The granted lifetime for which this node will attempt to retain 934 the entry for this mobile node in its Binding Cache. If the 935 node sending the Binding Acknowledgement is serving as the 936 mobile node's home agent, the Lifetime period also indicates 937 the period for which this node will continue this service; if 938 the mobile node requires home agent service from this node 939 beyond this period, the mobile node MUST send a new Binding 940 Update to it before the expiration of this period, in order to 941 extend the lifetime. 943 Refresh 945 The recommended period at which the mobile node SHOULD send 946 a new Binding Update to this node in order to "refresh" the 947 mobile node's binding in this node's Binding Cache. This 948 refreshing of the binding is useful in case the node fails and 949 loses its cache state. The Refresh period is determined by 950 the node sending the Binding Acknowledgement (the node caching 951 the binding). If this node is serving as the mobile node's 952 home agent, the Refresh value may be set, for example, based on 953 whether the node stores the mobile node's binding in volatile 954 storage or in nonvolatile storage. If the node sending the 955 Binding Acknowledgement is not serving as the mobile node's 956 home agent, the Refresh period SHOULD be set equal to the 957 Lifetime period in the Binding Acknowledgement; even if this 958 node loses this cache entry due to a failure of the node, 959 packets from it can still reach the mobile node through the 960 mobile node's home agent, causing a new Binding Update to this 961 node to allow it to recreate this cache entry. 963 Any packet that includes a Binding Acknowledgement option MUST 964 also include either an AH [7] or ESP [8] header providing sender 965 authentication, data integrity protection, and replay protection. 967 If the node returning the Binding Acknowledgement accepted the 968 Binding Update for which the Acknowledgement is being returned (the 969 value of the Status field in the Acknowledgement is less than 128), 970 this node will have an entry for the mobile node in its Binding Cache 971 and MUST use this entry (which includes the care-of address received 972 in the Binding Update) in sending the packet containing the Binding 973 Acknowledgement to the mobile node. The details of sending this 974 packet to the mobile node are the same as for sending any packet to a 975 mobile node using a binding, and are described in Section 7.9. The 976 packet is sent using a Routing header, routing the packet to the 977 mobile node by way of its care-of address recorded in the Binding 978 Cache entry. 980 If the node returning the Binding Acknowledgement instead 981 rejected the Binding Update (the value of the Status field in the 982 Acknowledgement is greater than or equal to 128), this node MUST 983 similarly use a Routing header in sending the packet containing the 984 Binding Acknowledgement, as described in Section 7.9, but MUST NOT 985 use its Binding Cache in forming the IP header or Routing header 986 in this packet. Rather, the care-of address used by this node in 987 sending the packet containing the Binding Acknowledgement MUST be 988 copied from the care-of address received in the rejected Binding 989 Update; this node MUST NOT modify its Binding Cache in response 990 to receiving this rejected Binding Update and MUST ignore its 991 Binding Cache in sending the packet in which it returns this Binding 992 Acknowledgement. The packet is sent using a Routing header, routing 993 the packet to the home address of the rejected Binding Update by 994 way of the care-of address indicated in the packet containing the 995 Binding Update. When sending a Binding Acknowledgement to reject a 996 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 997 packet containing no payload (with the Next Header field in the last 998 extension header in the packet set to indicate "No Next Header" [5]). 1000 The three highest-order bits of the Option Type are encoded to 1001 indicate specific processing of the option [5]. For the Binding 1002 Acknowledgement option, these three bits are set to 000, indicating 1003 that any IPv6 node processing this option that does not recognize the 1004 Option Type must skip over this option and continue processing the 1005 header, and that the data within the option cannot change en-route to 1006 the packet's final destination. 1008 Extensions to the Binding Acknowledgement option format may be 1009 included after the fixed portion of the Binding Acknowledgement 1010 option specified above. The presence of such extensions will be 1011 indicated by the Option Length field. When the Option Length is 1012 greater than the length defined above, the remaining octets are 1013 interpreted as extensions. Currently, no extensions have been 1014 defined. 1016 5.3. Binding Request Option 1018 The Binding Request destination option is used to request a mobile 1019 node's binding from the mobile node. When a mobile node receives 1020 a packet containing a Binding Request option, it SHOULD return a 1021 Binding Update (Section 5.1) to the source of the Binding Request. 1023 The Binding Request option is encoded in type-length-value (TLV) 1024 format as follows: 1026 0 1 1027 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Option Type | Option Length | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 Option Type 1034 3 ??? 1036 Option Length 1038 8-bit unsigned integer. Length of the option, in octets, 1039 excluding the Option Type and Option Length fields. For the 1040 current definition of the Binding Request option, this field 1041 MUST be set to 0. 1043 The three highest-order bits of the Option Type are encoded to 1044 indicate specific processing of the option [5]. For the Binding 1045 Request option, these three bits are set to 000, indicating that any 1046 IPv6 node processing this option that does not recognize the Option 1047 Type must skip over this option and continue processing the header, 1048 and that the data within the option cannot change en-route to the 1049 packet's final destination. 1051 Extensions to the Binding Request option format may be included after 1052 the fixed portion of the Binding Request option specified above. 1053 The presence of such extensions will be indicated by the Option 1054 Length field. When the Option Length is greater than 0 octets, 1055 the remaining octets are interpreted as extensions. Currently, no 1056 extensions have been defined. 1058 5.4. Home Address Option 1060 The Home Address destination option is used in a packet sent by a 1061 mobile node to inform the recipient of that packet of the mobile 1062 node's home address. For packets sent by a mobile node while 1063 away from home, the mobile node generally uses one of its care-of 1064 addresses as the Source Address in the packet's IPv6 header. By 1065 including a Home Address option in the packet, the correspondent 1066 node receiving the packet is able to substitute the mobile node's 1067 home address for this care-of address when processing the packet, 1068 thus making the use of the care-of address transparent to the 1069 correspondent node. 1071 The Home Address option is encoded in type-length-value (TLV) format 1072 as follows: 1074 0 1 2 3 1075 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 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Option Type | Option Length | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | | 1080 + + 1081 | | 1082 + Home Address + 1083 | | 1084 + + 1085 | | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 Option Type 1090 196 ??? 1092 Option Length 1094 8-bit unsigned integer. Length of the option, in octets, 1095 excluding the Option Type and Option Length fields. For the 1096 current definition of the Home Address option, this field MUST 1097 be set to 16. 1099 Home Address 1101 The home address of the mobile node sending the packet. 1103 The inclusion of a Home Address option in a packet affects only 1104 the correspondent node's receipt of this single packet; no state 1105 is created or modified in the correspondent node as a result of 1106 receiving a Home Address option in a packet. In particular, the 1107 receipt of a packet containing a Home Address option MUST NOT alter 1108 the contents of the receiver's Binding Cache due to the presence of 1109 the Home Address option, and the mapping between the home address 1110 and care-of address indicated by the Home Address option MUST NOT be 1111 used as a basis for routing subsequent packets sent by this receiving 1112 node. 1114 No special authentication of the Home Address option is required, 1115 except that if the IPv6 header of a packet is covered by 1116 authentication, then that authentication MUST also cover the Home 1117 Address option; this coverage is achieved automatically by the 1118 definition of the Option Type code for the Home Address option, 1119 since it indicates that the option is included in the authentication 1120 computation. If the packet carries no IP authentication, then the 1121 contents of the Home Address option, as well as the Source Address 1122 field or any other field in the IPv6 header, may have been forged or 1123 altered during transit. Upon receipt of a packet containing a Home 1124 Address option, the receiving node replaces the Source Address in 1125 the IPv6 header with the Home Address in the Home Address option. 1126 By requiring that any authentication of the IPv6 header also cover 1127 the Home Address option, the security of the Source Address field in 1128 the IPv6 header is not compromised by the presence of a Home Address 1129 option. Security issues related to the Home Address option are 1130 discussed further in Section 13. 1132 The three highest-order bits of the Option Type are encoded to 1133 indicate specific processing of the option [5]. For the Home Address 1134 option, these three bits are set to 110, indicating that any IPv6 1135 node processing this option that does not recognize the Option Type 1136 must discard the packet and, only if the packet's Destination Address 1137 was not a multicast address, return an ICMP Parameter Problem, 1138 Code 2, message to the packet's Source Address; and that the data 1139 within the option cannot change en-route to the packet's final 1140 destination. 1142 Extensions to the Home Address option format may be included after 1143 the fixed portion of the Home Address option specified above. 1144 The presence of such extensions will be indicated by the Option 1145 Length field. When the Option Length is greater than 8 octets, 1146 the remaining octets are interpreted as extensions. Currently, no 1147 extensions have been defined. 1149 6. Requirements for IPv6 Nodes 1151 Mobile IPv6 places some special requirements on the functions 1152 provided by different IPv6 nodes. This section summarizes those 1153 requirements, identifying the functionality each requirement is 1154 intended to support. Further details on this functionality is 1155 provided in the following sections. 1157 Since any IPv6 node may at any time be a correspondent node of a 1158 mobile node, the following requirements pertain to all IPv6 nodes: 1160 - Every IPv6 node MUST be able to process a Home Address option 1161 received in a packet. 1163 - Every IPv6 node SHOULD be able to process a Binding Update option 1164 received in a packet, and to return a Binding Acknowledgement 1165 option if requested. 1167 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 1168 bindings received in accepted Binding Updates. 1170 In order for a mobile node to operate correctly while away from 1171 home, at least one IPv6 router in the mobile node's home link must 1172 function as a home agent for the mobile node. The following special 1173 requirements pertain to all IPv6 routers capable of serving as a home 1174 agent: 1176 - Every home agent MUST be able to maintain an entry in its Binding 1177 Cache for each mobile node for which it is serving as the home 1178 agent. Each such Binding Cache entry records the mobile node's 1179 binding with its primary care-of address and is marked as a "home 1180 registration". 1182 - Every home agent MUST be able to intercept packets (using proxy 1183 Neighbor Discovery) on the local subnet addressed to a mobile 1184 node for which it is currently serving as the home agent while 1185 that mobile node is away from home. 1187 - Every home agent MUST be able to encapsulate such intercepted 1188 packets in order to tunnel them to the primary care-of address 1189 for the mobile node indicated in its binding. 1191 - Every home agent MUST be able to return a Binding Acknowledgement 1192 in response to a Binding Update received with the Acknowledge (A) 1193 bit set. 1195 - Every home agent MUST be able to accept packets addressed to the 1196 Home-Agents anycast address for the subnet on which it is serving 1197 as a home agent, and MUST be able to participate in dynamic home 1198 agent address discovery. 1200 Finally, the following requirements pertain all IPv6 nodes capable of 1201 functioning as mobile nodes: 1203 - Every IPv6 mobile node MUST be able to perform IPv6 1204 decapsulation [4]. 1206 - Every IPv6 mobile node MUST support sending Binding Updates, as 1207 specified in Sections 9.4, 9.5, and 9.6; and MUST be able to 1208 receive and process Binding Acknowledgements, as specified in 1209 Section 9.10. 1211 - Every IPv6 mobile node MUST maintain a Binding Update List in 1212 which it records the IP address of each other node to which it 1213 has sent a Binding Update, for which the Lifetime sent in that 1214 binding has not yet expired. 1216 - Every IPv6 mobile node MUST support receiving a Binding Request 1217 by responding with a Binding Update. 1219 - Every IPv6 mobile node MUST support sending packets containing a 1220 Home Address option; this option MUST be included in all packets 1221 sent while away from home, if the packet would otherwise have 1222 been sent with the mobile node's home address as the IP Source 1223 Address. 1225 7. Correspondent Node Operation 1227 A correspondent node is any node communicating with a mobile node. 1228 The correspondent node, itself, may be fixed or mobile, and may 1229 possibly also be functioning as a home agent for Mobile IPv6. The 1230 procedures in this section thus apply to all IPv6 nodes. 1232 7.1. Receiving Packets from a Mobile Node 1234 Packets sent by a mobile node while away from home generally include 1235 a Home Address option. When any node receives a packet containing 1236 a Home Address option, it MUST process the option in a manner 1237 consistent with copying the Home Address field from the Home Address 1238 option into the IPv6 header, replacing the original value of the 1239 Source Address field there. Further processing of the packet (e.g., 1240 at the transport layer) thus need not know that the original Source 1241 Address was a care-of address, or that the Home Address option was 1242 used in the packet. Since the sending mobile node uses its home 1243 address at the transport layer when sending such a packet, the use of 1244 the care-of address and Home Address option is thus transparent to 1245 both the mobile node and the correspondent node above the level of 1246 the Home Address option generation and processing. 1248 7.2. Receiving Binding Updates 1250 Upon receiving a Binding Update option in some packet, the receiving 1251 node MUST validate the Binding Update according to the following 1252 tests: 1254 - The packet contains a valid AH [7] or ESP [8] header that 1255 provides sender authentication, integrity protection, and replay 1256 protection. 1258 - The Option Length field in the Binding Update option is greater 1259 than or equal to the length specified in Section 5.1. 1261 - The Sequence Number field in the Binding Update option is greater 1262 than the Sequence Number received in the previous Binding Update 1263 for this home address, if any. The Sequence Number comparison is 1264 performed modulo 2**16. 1266 - The packet MUST contain a valid Home Address option. The home 1267 address for the binding is specified by the Home Address field of 1268 the Home Address option. 1270 Any Binding Update not satisfying all of these tests MUST be 1271 silently ignored, and the packet carrying the Binding Update MUST be 1272 discarded. 1274 If the Binding Update is valid according to the tests above, then the 1275 Binding Update is processed further as follows: 1277 - If the Destination Address in the packet's IPv6 header is the 1278 Home-Agents anycast address for a local subnet and this address 1279 is assigned to one of this node's network interfaces, then the 1280 mobile node sending this Binding Update is attempting dynamic 1281 home agent address discovery. Processing for this type of 1282 received Binding Update is described in Section 8.1. (If the 1283 Destination Address is not assigned to one of this node's network 1284 interfaces, then the packet would have been forwarded as a normal 1285 packet and the Binding Update, as a destination option, would not 1286 be processed in any way by this node.) 1288 - If the Lifetime specified in the Binding Update is nonzero and 1289 the specified Care-of Address is not equal to the home address 1290 for the binding (as given in the Home Address option in the 1291 packet), then this is a request to cache a binding for the mobile 1292 node. Processing for this type of received Binding Update is 1293 described in Section 7.3. 1295 - If the Lifetime specified in the Binding Update is zero or the 1296 specified Care-of Address matches the home address for the 1297 binding, then this is a request to delete the mobile node's 1298 cached binding. Processing for this type of received Binding 1299 Update is described in Section 7.4. 1301 7.3. Requests to Cache a Binding 1303 If a node receives a valid Binding Update requesting it to cache a 1304 binding for a mobile node, as specified in Section 7.2, then the node 1305 MUST examine the Home Registration (H) bit in the Binding Update 1306 to determine how to further process the Binding Update. If the 1307 Home Registration (H) bit is set, the Binding Update is processed 1308 according to the procedure specified in Section 8.2. 1310 If the Home Registration (H) bit is not set, then the receiving 1311 node SHOULD create a new entry in its Binding Cache for this mobile 1312 node (or update its existing Binding Cache entry for this mobile 1313 node, if such an entry already exists). The home address of the 1314 mobile node is taken from the Home Address field in the packet's Home 1315 Address option. The new Binding Cache entry records the association 1316 between this home address and the care-of address for the binding, as 1317 specified in either the Care-of Address field of the Binding Update 1318 or in the Source Address field in the packet's IPv6 header. Any 1319 Binding Cache entry created or updated in response to processing this 1320 Binding Update MUST be deleted after the expiration of the Lifetime 1321 period specified in the Binding Update. 1323 7.4. Requests to Delete a Binding 1325 If a node receives a valid Binding Update requesting it to delete a 1326 cached binding for a mobile node, as specified in Section 7.2, then 1327 the node MUST examine the Home Registration (H) bit in the Binding 1328 Update to determine how to further process the Binding Update. If 1329 the Home Registration (H) bit is set, the Binding Update is processed 1330 according to the procedure specified in Section 8.3. 1332 If the Home Registration (H) bit is not set, then the receiving node 1333 MUST delete any existing entry in its Binding Cache for this mobile 1334 node. The home address of the mobile node is taken from the Home 1335 Address field in the packet's Home Address option. 1337 7.5. Sending Binding Acknowledgements 1339 When any node receives a packet containing a Binding Update option 1340 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 1341 Acknowledgement option acknowledging receipt of the Binding Update. 1342 If the node accepts the Binding Update and creates or updates an 1343 entry in its Binding Cache for this binding, the Status field in 1344 the Binding Acknowledgement MUST be set to a value less than 128; 1345 if the node rejects the Binding Update and does not create or 1346 update an entry for this binding, the Status field in the Binding 1347 Acknowledgement MUST be set to a value greater than or equal to 128. 1348 Specific values for the Status field are described in Section 5.2 and 1349 in the most recent "Assigned Numbers" [17]. 1351 As described in Section 5.2, the packet in which the Binding 1352 Acknowledgement is returned MUST include either an AH [7] or ESP [8] 1353 header providing sender authentication, data integrity protection, 1354 and replay protection; and the packet MUST be sent using a Routing 1355 header in the same way as any other packet sent to a mobile node 1356 using a care-of address (even if the binding was rejected), as 1357 described in Section 7.9. The packet is routed first to the care-of 1358 address contained in the Binding Update being acknowledged, and 1359 then to the mobile node's home address. This use of the Routing 1360 header ensures that the Binding Acknowledgement will be routed to the 1361 current location of the node sending the Binding Update, whether the 1362 Binding Update was accepted or rejected. 1364 7.6. Sending Binding Requests 1366 Entries in a node's Binding Cache MUST be deleted when their lifetime 1367 expires. If such an entry is still in active use in sending packets 1368 to a mobile node, the next packet sent to the mobile node will be 1369 routed normally, to the mobile node's home link, where it will be 1370 intercepted and forwarded to the mobile node. The mobile node will 1371 then return a Binding Update to the sender, allowing it to create 1372 a new Binding Cache entry for sending future packets to the mobile 1373 node. Communication with the mobile node continues uninterrupted, 1374 but the forwarding of this packet through the mobile node's home 1375 agent creates additional overhead and latency in delivering packets 1376 to the mobile node. 1378 If the sender knows that the Binding Cache entry is still in active 1379 use, it MAY send a Binding Request to the mobile node in an attempt 1380 to avoid this overhead and latency due to deleting and recreating 1381 the Binding Cache entry. Since a Binding Request is a destination 1382 option, it may, for example, be included in any packet already being 1383 sent to the mobile node, such as a packet that is part of ongoing TCP 1384 communication with the mobile node. When the mobile node receives a 1385 packet from some sender containing a Binding Request, it returns a 1386 Binding Update to that sender, giving its current binding and a new 1387 lifetime. 1389 7.7. Cache Replacement Policy 1391 Any entry in a node's Binding Cache MUST be deleted after the 1392 expiration of the Lifetime specified in the Binding Update from which 1393 the entry was created or was last updated. Conceptually, a node 1394 maintains a separate timer for each entry in its Binding Cache. When 1395 creating or updating a Binding Cache entry in response to a received 1396 and accepted Binding Update, the node sets the timer for this entry 1397 to the specified Lifetime period. When a Binding Cache entry's timer 1398 expires, the node deletes the entry. 1400 Each node's Binding Cache will, by necessity, have a finite size. 1401 A node MAY use any reasonable local policy for managing the space 1402 within its Binding Cache, except that any entry marked as a "home 1403 registration" (Section 8.2) MUST NOT be deleted from the cache until 1404 the expiration of its lifetime period. When attempting to add a 1405 new "home registration" entry in response to a Binding Update with 1406 the Home Registration (H) bit set, if insufficient space exists (or 1407 can be reclaimed) in the node's Binding Cache, the node MUST reject 1408 the Binding Update and SHOULD return a Binding Acknowledgement to 1409 the sending mobile node, in which the Status field is set to 131 1410 (insufficient resources). When otherwise attempting to add a new 1411 entry to its Binding Cache, a node MAY, if needed, choose to drop any 1412 entry already in its Binding Cache, other than a "home registration" 1413 entry, in order to make space for the new entry. For example, a 1414 "least-recently used" (LRU) strategy for cache entry replacement 1415 among entries not marked as a "home registration" is likely to work 1416 well. 1418 Any binding dropped from a node's Binding Cache due to lack of cache 1419 space will be rediscovered and a new cache entry created, if the 1420 binding is still in active use by the node for sending packets. If 1421 the node sends a packet to a destination for which it has dropped the 1422 entry from its Binding Cache, the packet will be routed normally, 1423 leading to the mobile node's home link. There, the packet will be 1424 intercepted by the mobile node's home agent and tunneled to the 1425 mobile node's current primary care-of address. As when a Binding 1426 Cache entry is initially created, this indirect routing to the mobile 1427 node through its home agent will result in the mobile node sending 1428 a Binding Update to this sending node when it receives the tunneled 1429 packet, allowing it to add an entry again for this destination to its 1430 Binding Cache. 1432 7.8. Receiving ICMP Error Messages 1434 When a correspondent node sends a packet to a mobile node, if the 1435 correspondent node has a Binding Cache entry for the destination 1436 address of the packet, then the correspondent node uses a Routing 1437 header to deliver the packet to the mobile node through the care-of 1438 address in the binding recorded in the Binding Cache entry. Any ICMP 1439 error message caused by the packet on its way to the mobile node will 1440 be returned normally to the correspondent node. 1442 On the other hand, if the correspondent node has no Binding Cache 1443 entry for the mobile node, the packet will be routed to the mobile 1444 node's home link, where it will be intercepted by the mobile node's 1445 home agent, encapsulated, and tunneled to the mobile node's primary 1446 care-of address. Any ICMP error message caused by the packet on 1447 its way to the mobile node while in the tunnel, will be returned to 1448 the mobile node's home agent (the source of the tunnel). By the 1449 definition of IPv6 encapsulation [4], this encapsulating node MUST 1450 relay certain ICMP error messages back to the original sender of the 1451 packet, which in this case is the correspondent node. 1453 Likewise, if a packet for a mobile node arrives at the mobile node's 1454 previous default router (e.g., the mobile node moved after the packet 1455 was sent), the router will encapsulate and tunnel the packet to the 1456 mobile node's new care-of address (if it has a Binding Cache entry 1457 for the mobile node). As above, any ICMP error message caused by the 1458 packet while in this tunnel will be returned to the previous default 1459 router (the source of the tunnel), which MUST relay certain ICMP 1460 error messages back to the correspondent node [4]. 1462 Thus, in all cases, any meaningful ICMP error messages caused 1463 by packets from a correspondent node to a mobile node will be 1464 returned to the correspondent node. If the correspondent node 1465 receives persistent ICMP Destination Unreachable messages after 1466 sending packets to a mobile node based on an entry in its Binding 1467 Cache, the correspondent node SHOULD delete this Binding Cache 1468 entry. If the correspondent node subsequently transmits another 1469 packet to the mobile node, the packet will be routed to the mobile 1470 node's home link, intercepted by the mobile node's home agent, and 1471 tunneled to the mobile node's primary care-of address using IPv6 1472 encapsulation. The mobile node will then return a Binding Update to 1473 the correspondent node, allowing it to recreate a (correct) Binding 1474 Cache entry for the mobile node. 1476 7.9. Sending Packets to a Mobile Node 1478 Before sending any packet, the sending node SHOULD examine its 1479 Binding Cache for an entry for the destination address to which the 1480 packet is being sent. If the sending node has a Binding Cache entry 1481 for this address, the sending node SHOULD use a Routing header to 1482 route the packet to this mobile node (the destination node) by way 1483 of the care-of address in the binding recorded in that Binding Cache 1484 entry. For example, assuming use of a Type 0 Routing header [5], if 1485 no other use of a Routing header is involved in the routing of this 1486 packet, the mobile node sets the fields in the packet's IPv6 header 1487 and Routing header as follows: 1489 - The Destination Address in the packet's IPv6 header is set to 1490 the mobile node's care-of address copied from the Binding Cache 1491 entry. 1493 - The Routing header is initialized to contain a single route 1494 segment, with an Address of the mobile node's home address (the 1495 original destination address to which the packet was being sent). 1497 Following the definition of a Type 0 Routing header [5], this packet 1498 will be routed to the mobile node's care-of address, where it will 1499 be delivered to the mobile node (the mobile node has associated the 1500 care-of address with its network interface). Normal processing of 1501 the Routing header by the mobile node will then proceed as follows: 1503 - The mobile node swaps the Destination Address in the packet's 1504 IPv6 header and the Address specified in the Routing header. 1505 This results in the packet's IP Destination Address being set to 1506 the mobile node's home address. 1508 - The mobile node then resubmits the packet to its IPv6 module for 1509 further processing. Since the mobile node recognizes its own 1510 home address as one if its current IP addresses, the packet is 1511 processed further within the mobile node, in the same way then as 1512 if the mobile node was at home. 1514 If, instead, the sending node has no Binding Cache entry for the 1515 destination address to which the packet is being sent, the sending 1516 node simply sends the packet normally, with no Routing header. If 1517 the destination node is not a mobile node (or is a mobile node that 1518 is currently at home), the packet will be delivered directly to this 1519 node and processed normally by it. If, however, the destination node 1520 is a mobile node that is currently away from home, the packet will 1521 be intercepted by the mobile node's home agent and tunneled (using 1522 IPv6 encapsulation [4]) to the mobile node's current primary care-of 1523 address, as described in Section 8.4. The mobile node will then send 1524 a Binding Update to the sending node, as described in Section 9.5, 1525 allowing the sending node to create a Binding Cache entry for its use 1526 in sending subsequent packets to this mobile node. 1528 8. Home Agent Operation 1530 8.1. Dynamic Home Agent Address Discovery 1532 If a received Binding Update indicates that the mobile node sending 1533 it is attempting dynamic home agent address discovery, as described 1534 in Section 7.2, then the receiving node MUST process the Binding 1535 Update as specified in this section. 1537 A mobile node attempts dynamic home agent address discovery by 1538 sending its "home registration" Binding Update to the Home-Agents 1539 anycast address for its home IP subnet prefix (the packet MUST also 1540 include a Home Address option, as described in Section 9.4). A home 1541 agent receiving such a Binding Update that is serving this subnet 1542 (the home agent is configured with this anycast address on one of its 1543 network interfaces) MUST reject the Binding Update and SHOULD return 1544 a Binding Acknowledgement indicating this rejection, with the Source 1545 Address of the packet carrying the Binding Acknowledgement set to 1546 one of the unicast addresses of the home agent. The Status field in 1547 the Binding Acknowledgement MUST be set to 135 (dynamic home agent 1548 address discovery response). The mobile node, upon receiving this 1549 Binding Acknowledgement, MAY then resend its Binding Update to the 1550 unicast home agent address given in the Acknowledgement. 1552 8.2. Primary Care-of Address Registration 1554 General processing of a received Binding Update that requests a 1555 binding to be cached, is described in Section 7.3. However, if the 1556 Home Registration (H) bit is set in the Binding Update, then the 1557 receiving node MUST process the Binding Update as specified in this 1558 section, rather than following the general procedure specified in 1559 Section 7.3. 1561 To begin processing the Binding Update, the home agent MUST perform 1562 the following sequence of tests: 1564 - If the node is not a router that implements home agent 1565 functionality, then the node MUST reject the Binding Update and 1566 SHOULD return a Binding Acknowledgement to the mobile node, in 1567 which the Status field is set to 132 (home registration not 1568 supported). 1570 - Else, if the home address for the binding (the Home Address field 1571 in the packet's Home Address option) is not an on-link IPv6 1572 address with respect to the home agent's current Prefix List, 1573 then the home agent MUST reject the Binding Update and SHOULD 1574 return a Binding Acknowledgement to the mobile node, in which the 1575 Status field is set to 133 (not home subnet). 1577 - Else, if the ID Length field is nonzero in the Binding Update 1578 and this length differs from the length of the home agent's own 1579 interface identifier on the interface for which it is being 1580 asked to serve as home agent for this mobile node (the interface 1581 defined by the subnet prefix in the mobile node's home address in 1582 the binding), then the home agent MUST reject the Binding Update 1583 and SHOULD return a Binding Acknowledgement to the mobile node, 1584 in which the Status field is set to 136 (incorrect interface 1585 identifier length). 1587 - Else, if the home agent chooses to reject the Binding Update for 1588 any other reason (e.g., insufficient resources to serve another 1589 mobile node as a home agent), then the home agent SHOULD return a 1590 Binding Acknowledgement to the mobile node, in which the Status 1591 field is set to an appropriate value to indicate the reason for 1592 the rejection. 1594 If the home agent does not reject the Binding Update as described 1595 above, then it becomes the home agent for the mobile node. The new 1596 home agent (the receiving node) MUST then create a new entry or 1597 update the existing entry in its Binding Cache for this mobile node's 1598 home address (given in the Home Address option in the packet), as 1599 described in Section 7.3. In addition, the home agent MUST mark 1600 this Binding Cache entry as a "home registration" to indicate that 1601 the node is serving as a home agent for this binding. Binding 1602 Cache entries marked as a "home registration" MUST be excluded from 1603 the normal cache replacement policy used for the Binding Cache 1604 (Section 7.7) and MUST NOT be removed from the Binding Cache until 1605 the expiration of the Lifetime period. 1607 If the home agent was not already serving as a home agent for this 1608 mobile node (the home agent did not already have a Binding Cache 1609 entry for this home address marked as a "home registration"), then 1610 the home agent MUST multicast onto the home link a "gratuitous" 1611 Neighbor Advertisement message [11] on behalf of the mobile node, in 1612 order to begin intercepting packets addressed to it while it is away 1613 from home. Specifically, the home agent follows the following steps: 1615 - The home agent examines the value of the ID Length field in 1616 the Binding Update. If this value is zero, the following step 1617 is carried out only for the individual home address specified 1618 (in the Home Address option in the packet) for this binding. 1619 If, instead, this field is nonzero, then the following step is 1620 carried out for each address for the mobile node formed from 1621 the mobile node's interface identifier (from the specified home 1622 address) together with each one of the subnet prefixes currently 1623 considered by the home agent to be on-link (including both the 1624 link-local and site-local prefix). 1626 - For each specific IP address for the mobile node determined in 1627 the first step above, the home agent multicast onto the home link 1628 (to the all-nodes multicast address) a Neighbor Advertisement 1629 message [11] on behalf of the mobile node, to advertise the 1630 home agent's own link-layer address for this IP address. The 1631 Target Address in the Neighbor Advertisement message MUST be set 1632 to this IP address for the mobile node, and the Advertisement 1633 MUST include a Target Link-layer Address option specifying the 1634 home agent's link-layer address. The Solicited Flag (S) in the 1635 Advertisement MUST NOT be set, since it was not solicited by any 1636 Neighbor Solicitation message. The Override Flag (O) in the 1637 Advertisement MUST be set, indicating that the Advertisement 1638 SHOULD override any existing Neighbor Cache entry at any node 1639 receiving it. 1641 Any node on the home link receiving one of the Neighbor Advertisement 1642 messages described above will thus update its Neighbor Cache to 1643 associate the mobile node's address with the home agent's link 1644 layer address, causing it to transmit any future packets for the 1645 mobile node normally destined to this address instead to the mobile 1646 node's home agent. Since multicasts on the local link (such as 1647 Ethernet) are typically not guaranteed to be reliable, the home 1648 agent MAY retransmit this Neighbor Advertisement message up to 1649 MAX_ADVERT_REXMIT times to increase its reliability. It is still 1650 possible that some nodes on the home link will not receive any of 1651 these Neighbor Advertisements, but these nodes will eventually be 1652 able to detect the link-layer address change for the mobile node's 1653 home address, through use of Neighbor Unreachability Detection [11]. 1655 In addition, while this node is serving as a home agent for this 1656 mobile node (it still has a "home registration" entry for this mobile 1657 node in its Binding Cache), it MUST act as a proxy for this mobile 1658 node to reply to any received Neighbor Solicitation messages for 1659 it. When a home agent receives a Neighbor Solicitation message, it 1660 MUST check if the Target Address specified in the message matches 1661 the home address of any mobile node for which it has a Binding 1662 Cache entry marked as a "home registration". This check MUST 1663 include all possible home addresses for the mobile node, based on 1664 the subnet prefixes currently considered to be on-link by the home 1665 agent (including the corresponding link-local address and site-local 1666 address), if the ID Length field was nonzero in the Binding Update 1667 that created this "home registration" binding at the home agent. If 1668 such an entry exists in the home agent's Binding Cache, the home 1669 agent MUST reply to the Neighbor Solicitation message with a Neighbor 1670 Advertisement message, giving the home agent's own link-layer address 1671 as the link-layer address for the specified Target Address. Acting 1672 as a proxy in this way allows other nodes on the mobile node's home 1673 link to resolve the mobile node's IPv6 home address, and allows 1674 the home agent to to defend these addresses on the home link for 1675 Duplicate Address Detection [11]. 1677 Any packet addressed to the mobile node's home address (including 1678 addresses formed from other on-link prefixes, if the ID Length field 1679 was nonzero in the Binding Update) will thus be received by the 1680 mobile node's home agent while the mobile node is registered away 1681 from home. For any such packet received by the home agent for the 1682 mobile node, the home agent SHOULD tunnel the packet to the mobile 1683 node at its primary care-of address, as described in Section 8.4. 1684 However, packets addressed to the mobile node's link-local address or 1685 site-local address MUST NOT be tunneled to the mobile node. Instead, 1686 such packets MUST be discarded, and for each, the home agent SHOULD 1687 return an ICMP Destination Unreachable, Code 3, message to the 1688 packet's Source Address (unless this Source Address is a multicast 1689 address). 1691 8.3. Primary Care-of Address De-registration 1693 General processing of a received Binding Update that requests a 1694 binding to be deleted, is described in Section 7.4. However, if the 1695 Home Registration (H) bit is set in the Binding Update, then the 1696 receiving node MUST process the Binding Update as specified in this 1697 section, rather than following the general procedure specified in 1698 Section 7.4. 1700 To begin processing the Binding Update, the home agent MUST perform 1701 the following sequence of tests: 1703 - If the node is not a router that implements home agent 1704 functionality, then the node MUST reject the Binding Update and 1705 SHOULD return a Binding Acknowledgement to the mobile node, in 1706 which the Status field is set to 132 (home registration not 1707 supported). 1709 - Else, if the home address for the binding (the Home Address 1710 field in the packet's Home Address option) is not an on-link 1711 IPv6 address with respect to the home agent's current Prefix 1712 List, then it MUST reject the Binding Update and SHOULD return a 1713 Binding Acknowledgement to the mobile node, in which the Status 1714 field is set to 133 (not home subnet). 1716 If the home agent does not reject the Binding Update as described 1717 above, then it MUST delete any existing entry in its Binding Cache 1718 for this mobile node. 1720 8.4. Tunneling Intercepted Packets to a Mobile Node 1722 For any packet sent to a mobile node from the mobile node's home 1723 agent (for which the home agent is the original sender of the 1724 packet), the home agent is operating as a correspondent node of 1725 the mobile node for this packet and the procedures described in 1726 Section 7.9 apply. The home agent (as a correspondent node) uses a 1727 Routing header to route the packet to the mobile node by way of the 1728 care-of address in the home agent's Binding Cache (the mobile node's 1729 primary care-of address, in this case). 1731 In addition, while the mobile node is away from home and this node is 1732 acting as the mobile node's home agent, the home agent intercepts any 1733 packets on the home link addressed to the mobile node's home address, 1734 as described in Section 8.2. The home agent cannot use a Routing 1735 header to forward these intercepted packets to the mobile node, 1736 since it cannot modify the packet in flight without invalidating any 1737 existing IPv6 Authentication header present in the packet [7]. 1739 For forwarding each intercepted packet to the mobile node, the 1740 home agent MUST tunnel the packet to the mobile node using IPv6 1741 encapsulation [4]; the tunnel entry point node is the home agent, 1742 and the tunnel exit point node is the mobile node itself (using its 1743 primary care-of address as registered with the home agent). When a 1744 home agent encapsulates an intercepted packet for forwarding to the 1745 mobile node, the home agent sets the Source Address in the prepended 1746 tunnel IP header to the home agent's own IP address, and sets the 1747 Destination Address in the tunnel IP header to the mobile node's 1748 primary care-of address. When received by the mobile node (using its 1749 primary care-of address), normal processing of the tunnel header [4] 1750 will result in decapsulation and processing of the original packet by 1751 the mobile node. 1753 8.5. Renumbering the Home Subnet 1755 Neighbor Discovery [11] specifies a mechanism by which all nodes on a 1756 subnet can gracefully autoconfigure new addresses, say by each node 1757 combining a new routing prefix with its existing link-layer address. 1758 As currently specified, this mechanism works when the nodes are on 1759 the same link as the router issuing the necessary multicast packets 1760 to advertise the new routing prefix(es) appropriate for the link. 1762 However, for mobile nodes away from home, special care must be taken 1763 to allow the mobile nodes to renumber gracefully. The most direct 1764 method of ensuring this is for the home agent to encapsulate and 1765 tunnel the multicast packets to the primary care-of address of each 1766 mobile node for which it is serving as the home agent. The rules for 1767 this are as follows: 1769 - A mobile node assumes that its routing prefix has not changed 1770 unless it receives an authenticated Router Advertisement message 1771 from its home agent that the prefix has changed. 1773 - When the mobile node is at home, the home agent does not tunnel 1774 Router Advertisements to it. 1776 - The mobile node's home agent serves as a proxy for the mobile 1777 node's home address and link-local address, including defending 1778 these addresses for Duplicate Address Detection, while the mobile 1779 node is registered with the home agent away from home. 1781 - When a home subnet prefix changes, the home agent tunnels Router 1782 Advertisement packets to each mobile node registered with it that 1783 is currently away from home and using a home address with the 1784 affected routing prefix. Such tunneled Router Advertisements 1785 MUST be authenticated [7]. 1787 - When a mobile node receives a tunneled Router Advertisement 1788 containing a new routing prefix, it MUST perform the standard 1789 autoconfiguration operation to create its new address. 1791 - When a mobile node returns to its home link, it must again 1792 perform Duplicate Address Detection at the earliest possible 1793 moment after it has deleted its "home registration" binding with 1794 its home agent. 1796 - A mobile node MAY send a Router Solicitation to its home agent at 1797 any time, within the constraints imposed by rate control defined 1798 by Neighbor Discovery [11]. 1800 9. Mobile Node Operation 1802 9.1. Sending Packets While Away from Home 1804 While a mobile node is away from home, it continues to use its home 1805 address as well as also using one or more care-of addresses. When 1806 sending a packet while away from home, a mobile node MAY choose among 1807 these in selecting the address that it will use as the source of the 1808 packet, as follows: 1810 - For most packets, the mobile node will generally use its home 1811 address as the source of the packet. Doing so makes its mobility 1812 and the fact that it is currently away from home transparent to 1813 the correspondent nodes with which it communicates. For packets 1814 sent that are part of transport-level connections established 1815 while the mobile node was at home, the mobile node MUST use 1816 its home address. Likewise, for packets sent that are part of 1817 transport-level connections that the mobile node may still be 1818 using after moving to a new location, the mobile node SHOULD use 1819 its home address. 1821 - For short-term communication, particularly for communication 1822 that may easily be retried if it fails, the mobile node MAY 1823 choose to use one of its care-of addresses as the source of the 1824 packet. An example of this type of communication might be DNS 1825 queries sent by the mobile node [9, 10]. Using the mobile node's 1826 care-of address as the source for such queries will generally 1827 have a lower overhead than using the mobile node's home address, 1828 since no extra options need be used in either the query or its 1829 reply, and all packets can be routed normally, directly between 1830 their source and destination without relying on Mobile IP. If the 1831 mobile node has no particular knowledge that the communication 1832 being sent fits within this type of communication, however, the 1833 mobile node SHOULD use its home address. 1835 If the mobile node uses one of its care-of addresses as the source 1836 of some packet while away from home, no special Mobile IP processing 1837 is required for sending this packet. The packet is simply addressed 1838 and transmitted in the same way as any normal IPv6 packet, setting 1839 the Source Address field in the packet's IPv6 header to this care-of 1840 address. 1842 On the other hand, if the mobile node uses its home address as the 1843 source of a packet while away from home, special Mobile IP processing 1844 of this packet is required. Since Mobile IP is transparent to higher 1845 protocol layers (e.g., to TCP), the packet is initially constructed 1846 using the mobile node's home address as the packet's Source Address, 1847 in the same way as if the mobile node were at home. However, while 1848 away from home, Mobile IP processes each outgoing packet as follows: 1850 - If the Source Address field in the packet's IPv6 header is not 1851 the mobile node's home address, skip all following steps and send 1852 the packet normally. 1854 - Otherwise, insert a Home Address option into the packet, with the 1855 Home Address field copied from the original value of the Source 1856 Address field in the packet. 1858 - Change the Source Address field in the packet's IPv6 header to 1859 one of the mobile node's care-of addresses This will typically 1860 be the mobile node's current primary care-of address, but MUST 1861 be a care-of address with a subnet prefix that is on-link on the 1862 network interface on which the mobile node will transmit the 1863 packet. 1865 This addition of the Home Address option to a packet MUST be 1866 performed before outgoing IPsec processing, such as the addition of 1867 an AH [7] or ESP [8] header to the packet, is performed. Likewise, 1868 IPsec processing for a received packet containing a Home Address 1869 option MUST be performed before the packet is possibly modified as 1870 part of processing the Home Address option. By using the care-of 1871 address as the Source Address in the IPv6 header, with the mobile 1872 node's home address instead in the Home Address option, the packet 1873 will be able to safely pass through any router implementing ingress 1874 filtering [6]. 1876 9.2. Movement Detection 1878 A mobile node MAY use any combination of mechanisms available to it 1879 to detect when it has moved from one link to another. The primary 1880 movement detection mechanism for Mobile IPv6 defined here uses the 1881 facilities of IPv6 Neighbor Discovery, including Router Discovery and 1882 Neighbor Unreachability Detection. The description here is based on 1883 the conceptual model of the organization and data structures defined 1884 by Neighbor Discovery [11]. 1886 Mobile nodes SHOULD use Router Discovery to discover new routers and 1887 on-link subnet prefixes; a mobile node MAY send Router Solicitation 1888 messages, or MAY wait for unsolicited (periodic) Router Advertisement 1889 messages, as specified for Router Discovery [11]. Based on received 1890 Router Advertisement messages, a mobile node (in the same way as any 1891 other node) maintains an entry in its Default Router List for each 1892 router, and an entry in its Prefix List for each subnet prefix, that 1893 it currently considers to be on-link. Each entry in these lists has 1894 an associated invalidation timer value (extracted from the Router 1895 Advertisement) used to expire the entry when it becomes invalid. 1897 While away from home, a mobile node SHOULD select one router from 1898 its Default Router List to use as its default router, and one subnet 1899 prefix advertised by that router from its Prefix List to use as 1900 the subnet prefix in its primary care-of address. A mobile node 1901 MAY also have associated additional care-of addresses, using other 1902 subnet prefixes from its Prefix List. The method by which a mobile 1903 node selects and forms a care-of address from the available subnet 1904 prefixes is described in Section 9.3. The mobile node registers 1905 its primary care-of address with its home agent, as described in 1906 Section 9.4. 1908 While a mobile node is away from home and using some router as its 1909 default router, it is important for the mobile node to be able to 1910 quickly detect when that router becomes unreachable, so that it can 1911 switch to a new default router and to a new primary care-of address. 1912 Since some links (notably wireless) do not necessarily work equally 1913 well in both directions, it is likewise important for the mobile 1914 node to detect when it becomes unreachable to packets sent from its 1915 default router, so that the mobile node can take steps to ensure that 1916 any correspondent nodes attempting to communicate with it can still 1917 reach it through some other route. 1919 To detect when its default router becomes unreachable, a mobile 1920 node SHOULD use Neighbor Unreachability Detection. As specified in 1921 Neighbor Discovery [11], while the mobile node is actively sending 1922 packets to (or through) its default router, the mobile node can 1923 detect that the router (as its neighbor) is still reachable either 1924 through indications from upper layer protocols on the mobile node 1925 that a connection is making "forward progress" (e.g., receipt of TCP 1926 acknowledgements for new data transmitted), or through receipt of a 1927 Neighbor Advertisement message form its default router in response 1928 to an explicit Neighbor Solicitation messages to it. Note that 1929 although this mechanism only detects that the mobile node's default 1930 router has become unreachable to the mobile node while the mobile 1931 node is actively sending packets to it, this is the only time that 1932 this direction of reachability confirmation is needed. Confirmation 1933 that the mobile node is still reachable from the router is handled 1934 separately, as described below. 1936 For a mobile node to detect when it has become unreachable to its 1937 default router, however, the mobile node cannot efficiently rely on 1938 Neighbor Unreachability Detection alone, since the network overhead 1939 would be prohibitively high in many cases for a mobile node to 1940 continually probe its default router with Neighbor Solicitation 1941 messages even when it is not otherwise actively sending packets to 1942 it. Instead, a mobile node SHOULD consider receipt of any IPv6 1943 packets from its current default router as an indication that it is 1944 still reachable from the router. Both packets from the router's IP 1945 address and (IPv6) packets from its link-layer address (e.g., those 1946 forwarded but not originated by the router) SHOULD be considered. 1948 Since the router SHOULD be sending periodic multicast Router 1949 Advertisement messages, the mobile node will have frequent 1950 opportunity to check if it is still reachable from its default 1951 router, even in the absence of other packets to it from the router. 1952 On some types of network interfaces, the mobile node MAY also 1953 supplement this by setting its network interface into "promiscuous" 1954 receive mode, so that it is able to receive all packets on the link, 1955 including those not link-level addressed to it. The mobile node will 1956 then be able to detect any packets sent by the router, in order to to 1957 detect reachability from the router. This may be useful on very low 1958 bandwidth (e.g., wireless) links, but its use MUST be configurable on 1959 the mobile node. 1961 If the above means do not provide indication that the mobile node 1962 is still reachable from its current default router (i.e., the 1963 mobile node receives no packets from the router for a period of 1964 time), then the mobile node SHOULD actively probe the router with 1965 Neighbor Solicitation messages, even if it is not otherwise actively 1966 sending packets to the router. If it receives a solicited Neighbor 1967 Advertisement message in response from the router, then the mobile 1968 node can deduce that it is still reachable. It is expected that the 1969 mobile node will in most cases be able to determine its reachability 1970 from the router by listening for packets from the router as described 1971 above, and thus, such extra Neighbor Solicitation probes should 1972 rarely be necessary. 1974 With some types of networks, it is possible that additional 1975 indications about link-layer mobility can be obtained from 1976 lower-layer protocol or device driver software within the mobile 1977 node. However, a mobile node MUST NOT assume that all link-layer 1978 mobility indications from lower layers indicate a movement of the 1979 mobile node to a new link, such that the mobile node would need to 1980 switch to a new default router and primary care-of address. For 1981 example, movement of a mobile node from one cell to another in many 1982 wireless LANs can be made transparent to the IP level through use of 1983 a link-layer "roaming" protocol, as long as the different wireless 1984 LAN cells all operate as part of the same IP link with the same 1985 subnet prefix. Upon lower-layer indication of link-layer mobility, 1986 the mobile node SHOULD send Router Solicitation messages to determine 1987 if new routers (and new on-link subnet prefixes) are present on its 1988 new link. 1990 Such lower-layer information might also be useful to a mobile node in 1991 deciding to switch its primary care-of address to one of the other 1992 care-of addresses it has formed from the on-link subnet prefixes 1993 currently available through different routers from which the mobile 1994 node is reachable. For example, a mobile node MAY use signal 1995 strength or signal quality information (with suitable hysteresis) for 1996 its link with the available routers to decide when to switch to a new 1997 primary care-of address using that router rather than its current 1998 default router (and current primary care-of address). Even though 1999 the mobile node's current default router may still be reachable in 2000 terms of Neighbor Unreachability Detection, the mobile node MAY use 2001 such lower-layer information to determine that switching to a new 2002 default router would provide a better connection. 2004 9.3. Forming New Care-of Addresses 2006 After detecting that it has moved from one link to another (i.e., its 2007 current default router has become unreachable and it has discovered a 2008 new default router), a mobile node SHOULD form a new primary care-of 2009 address using one of the on-link subnet prefixes advertised by the 2010 new router. A mobile node MAY form a new primary care-of address 2011 at any time, except that it MUST NOT do so too frequently (not more 2012 often than once per MAX_UPDATE_RATE seconds). 2014 In addition, after discovering a new on-link subnet prefix, a mobile 2015 node MAY form a new (non-primary) care-of address using that subnet 2016 prefix, even when it has not switched to a new default router. A 2017 mobile node can have only one primary care-of address at a time 2018 (which is registered with its home agent), but it MAY have an 2019 additional care-of address for any or all of the subnet prefixes on 2020 its current link. Furthermore, since a wireless network interface 2021 may actually allow a mobile node to be reachable on more than one 2022 link at a time (i.e., within wireless transmitter range of routers 2023 on more than one separate link), a mobile node MAY have care-of 2024 addresses on more than one link at a time. The use of more than one 2025 care-of address at a time is described in Section 9.12. 2027 As described in Section 4, in order to form a new care-of address, 2028 a mobile node MAY use either stateless [18] or stateful (e.g., 2029 DHCPv6 [2]) address autoconfiguration. If a mobile node needs to 2030 send packets as part of the method of address autoconfiguration, 2031 it MUST use an IPv6 link-local address rather than its own IPv6 2032 home address as the Source Address in the IPv6 header of each such 2033 autoconfiguration packet. 2035 In some cases, a mobile node may already know a (constant) IPv6 2036 address that has been assigned to it for its use only while 2037 visiting a specific foreign link. For example, a mobile node may be 2038 statically configured with an IPv6 address assigned by the system 2039 administrator of some foreign link, for its use while visiting that 2040 link. If so, rather than using address autoconfiguration to form a 2041 new care-of address using this subnet prefix, the mobile node MAY use 2042 its own pre-assigned address as its care-of address on this link. 2044 9.4. Sending Binding Updates to the Home Agent 2046 After deciding to change its primary care-of address as described 2047 in Sections 9.2 and 9.3, a mobile node MUST register this care-of 2048 address with its home agent in order to make this its primary care-of 2049 address. To do so, the mobile node sends a packet to its home agent 2050 containing a Binding Update option, with the packet constructed as 2051 follows: 2053 - The Home Registration (H) bit MUST be set in the Binding Update. 2055 - The Acknowledge (A) bit MUST be set in the Binding Update. 2057 - The packet MUST contain a Home Address option, giving the mobile 2058 node's home address for the binding. 2060 - The care-of address for the binding MUST be used as the Source 2061 Address in the packet's IPv6 header, or the Care-of Address 2062 Present (C) bit MUST be set in the Binding Update and the care-of 2063 address for binding MUST be specified in the Care-of Address 2064 field in the Binding Update. 2066 - The ID Length field SHOULD be set to the length of the mobile 2067 node's interface identifier in its home address, to request 2068 the mobile node's home agent to serve as a home agent for all 2069 home addresses for the mobile node based on all on-link subnet 2070 prefixes on the home link. Otherwise, this field MUST be set to 2071 zero. 2073 The Acknowledge (A) bit in the Binding Update requests the home 2074 agent to return a Binding Acknowledgement in response to this 2075 Binding Update. As described in Section 5.2, the mobile node SHOULD 2076 retransmit this Binding Update to its home agent until it receives 2077 a matching Binding Acknowledgement. Once reaching a retransmission 2078 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 2079 continue to periodically retransmit the Binding Update at this rate 2080 until acknowledged (or until it begins attempting to register a 2081 different primary care-of address). 2083 The ID Length field in the Binding Update allows the mobile node to 2084 request its home agent to serve all home addresses for the mobile 2085 node defined by the mobile node's interface identifier, based on all 2086 on-link subnet prefixes on the home link. If the mobile node has 2087 additional home addresses using a different interface identifier, 2088 then the mobile node SHOULD send an additional Binding Update to its 2089 home agent to register the care-of address for each such other home 2090 address (or set of home addresses sharing an interface identifier). 2092 It is possible that when the mobile node needs to send such a Binding 2093 Update to its home agent, that the mobile node does not know the 2094 address of any router on its home link that can serve as a home agent 2095 for it. In this case, the mobile node SHOULD use the dynamic home 2096 agent address discovery procedure to find the address of a suitable 2097 home agent on its home link. To do so, the mobile node sends the 2098 packet, as described above, with the Destination Address in the 2099 packet's IPv6 header set to the Home-Agents anycast address for its 2100 home subnet prefix. The home agent on its home link that receives 2101 this Binding Update will reject the Update, returning to the mobile 2102 node the home agent's unicast IP address. The mobile node SHOULD 2103 then retransmit its Binding Update to this home agent using the 2104 provided unicast address. 2106 If the mobile node has a current registration with some home agent 2107 on its home link (the Lifetime for that registration has not yet 2108 expired), then the mobile node MUST attempt any new registration 2109 first with that home agent. If that registration attempt fails 2110 (e.g., times out or is rejected), the mobile node SHOULD then 2111 reattempt this registration with another home agent on its home link. 2112 If the mobile node knows of no other suitable home agent, then it MAY 2113 attempt the dynamic home agent address discovery procedure described 2114 above. 2116 9.5. Sending Binding Updates to Correspondent Nodes 2118 A mobile node MAY send a Binding Update to any correspondent node at 2119 any time to allow it to cache its current care-of address (subject 2120 to the rate limiting defined in Section 9.8). In any Binding Update 2121 sent by a mobile node, the care-of address (either the Source Address 2122 in the packet's IPv6 header or the Care-of Address field in the 2123 Binding Update) MUST be set to one of the care-of addresses currently 2124 in use by the mobile node or to the mobile node's home address. 2125 If set to one of the mobile node's current care-of addresses (the 2126 care-of address given MAY differ from the mobile node's primary 2127 care-of address), the Binding Update requests the correspondent node 2128 to create or update an entry for the mobile node in the correspondent 2129 node's Binding Cache to record this care-of address for use in 2130 sending future packets to the mobile node. If, instead, the care-of 2131 address is set to the mobile node's home address, the Binding Update 2132 requests the correspondent node to delete any existing Binding Cache 2133 entry that it has for the mobile node. A mobile node MAY set the 2134 care-of address differently for sending Binding Updates to different 2135 correspondent nodes. 2137 When sending any Binding Update, the mobile node MUST record in its 2138 Binding Update List the following fields from the Binding Update: 2140 - The IP address of the node to which the Binding Update was sent. 2142 - The home address for which the Binding Update was sent, 2143 - The remaining lifetime of the binding, initialized from the 2144 Lifetime field sent in the Binding Update. 2146 The mobile node MUST retain in its Binding Update List information 2147 about all Binding Updates sent, for which the lifetime of the 2148 binding has not yet expired. When sending a Binding Update, if an 2149 entry already exists in the mobile node's Binding Update List for 2150 an earlier Binding Update sent to that same destination node, the 2151 existing Binding Update List entry is updated to reflect the new 2152 Binding Update rather than creating a new Binding Update List entry. 2154 In general, when a mobile node sends a Binding Update to its home 2155 agent to register a new primary care-of address (as described in 2156 Section 9.4), the mobile node will also send a Binding Update to each 2157 correspondent node for which an entry exists in the mobile node's 2158 Binding Update List. Thus, correspondent nodes are generally kept 2159 updated about the mobile node's binding and can send packets directly 2160 to the mobile node using the mobile node's current care-of address. 2162 The mobile node, however, need not send these Binding Updates 2163 immediately after configuring a new care-of address. For example, 2164 since the Binding Update is a destination option and can be included 2165 in any packet sent by a mobile node, the mobile node MAY delay 2166 sending a new Binding Update to any correspondent node for a 2167 short period of time, in hopes that the needed Binding Update 2168 can be included in some packet that the mobile node sends to that 2169 correspondent node for some other reason (for example, as part of 2170 some TCP connection in use). In this case, when sending a packet 2171 to some correspondent node, the mobile node SHOULD check in its 2172 Binding Update List to determine if a new Binding Update to this 2173 correspondent node is needed, and SHOULD include the new Binding 2174 Update in this packet as necessary. 2176 In addition, when a mobile node receives a packet for which the 2177 mobile node can deduce that the original sender of the packet has no 2178 Binding Cache entry for the mobile node, or for which the mobile node 2179 can deduce that the original sender of the packet has an out-of-date 2180 care-of address for the mobile node in its Binding Cache, the mobile 2181 node SHOULD return a Binding Update to the sender giving its current 2182 care-of address. In particular, the mobile node SHOULD return a 2183 Binding Update in response to receiving a packet that meets all of 2184 the following tests: 2186 - The packet was tunneled using IPv6 encapsulation. 2188 - The Destination Address in the tunnel (outer) IPv6 header is 2189 equal to any of the mobile node's care-of addresses. 2191 - The Destination Address in the original (inner) IPv6 header is 2192 equal to the mobile node's home address. If the original packet 2193 contains a Routing header, the final Address indicated in the 2194 Routing header should be used in this comparison rather than the 2195 Destination Address in the original IPv6 header. 2197 - The Source Address in the tunnel (outer) IPv6 header differs from 2198 the Source Address in the original (inner) IPv6 header. 2200 The destination address to which the Binding Update should be sent in 2201 response to receiving a packet meeting all of the tests above, is the 2202 Source Address in the original (inner) IPv6 header of the packet. 2204 Binding Updates sent to correspondent nodes are not generally 2205 required to be acknowledged. However, if the mobile node wants to be 2206 sure that its new care-of address has been added to a correspondent 2207 node's Binding Cache, the mobile node MAY request an acknowledgement 2208 by setting the Acknowledge (A) bit in the Binding Update. In this 2209 case, however, the mobile node SHOULD NOT continue to retransmit the 2210 Binding Update once the retransmission timeout period has reached 2211 MAX_BINDACK_TIMEOUT. 2213 A mobile node MAY choose to keep its location private from certain 2214 correspondent nodes, and thus need not send new Binding Updates to 2215 those correspondents. A mobile node MAY also send a Binding Update 2216 to such a correspondent node to instruct it to delete any existing 2217 binding for the mobile node from its Binding Cache, as described in 2218 Section 5.1. No other IPv6 nodes are authorized to send Binding 2219 Updates on behalf of a mobile node. 2221 9.6. Sending Binding Updates to the Previous Default Router 2223 After switching to a new default router (and thus also changing its 2224 primary care-of address), a mobile node MAY send a Binding Update 2225 to its previous default router, giving its new care-of address. 2226 If the mobile node sends such a Binding Update, the home address 2227 for the binding, specified in the Home Address option included in 2228 the packet carrying this Binding Update, MUST be set the mobile 2229 node's old primary care-of address (that it used while using this 2230 default router), and the care-of address for the binding (either the 2231 Source Address in the packet's IPv6 header or the Care-of Address 2232 field in the Binding Update) MUST be set to the mobile node's new 2233 primary care-of address. In addition, the Home Registration (H) 2234 bit MUST also be set in this Binding Update, to request the mobile 2235 node's previous default router to temporarily act as a home agent 2236 for the mobile node's old primary care-of address. The previous 2237 default router will thus tunnel packets for the mobile node to its 2238 new care-of address. All of the procedures defined for home agent 2239 operation must be followed by this previous default router for this 2240 registration. Note that the previous router does not necessarily 2241 know the mobile node's (permanent) home address as part of this 2242 registration. 2244 9.7. Retransmitting Binding Updates 2246 If, after sending a Binding Update in which the Acknowledge (A) bit 2247 is set, a mobile node fails to receive a Binding Acknowledgement 2248 within INITIAL_BINDACK_TIMEOUT seconds, the mobile node SHOULD 2249 retransmit the Binding Update until a Binding Acknowledgement 2250 is received. Such a retransmitted Binding Update MUST use he 2251 same Sequence Number value as the original transmission. The 2252 retransmissions by the mobile node MUST use an exponential 2253 back-off process, in which the timeout period is doubled 2254 upon each retransmission until either the node receives a 2255 Binding Acknowledgement or the timeout period reaches the value 2256 MAX_BINDACK_TIMEOUT. 2258 9.8. Rate Limiting for Sending Binding Updates 2260 A mobile node MUST NOT send Binding Updates more often than once per 2261 MAX_UPDATE_RATE seconds to any node. After sending MAX_FAST_UPDATES 2262 consecutive Binding Updates to a particular node with the same 2263 care-of address, the mobile node SHOULD reduce its rate of sending 2264 Binding Updates to that node, to the rate of SLOW_UPDATE_RATE per 2265 second. The mobile node MAY continue to send Binding Updates at the 2266 slower rate indefinitely, in hopes that the node will eventually 2267 be able to process a Binding Update and begin to route its packets 2268 directly to the mobile node at its new care-of address. 2270 9.9. Receiving ICMP Errors in Response to Binding Updates 2272 The Option Type value for a Binding Update option specifies that 2273 any node receiving this option that does not recognize the Option 2274 Type SHOULD return an ICMP Parameter Problem, Code 2, message to the 2275 sender of the Binding Update. If a node sending a Binding Update 2276 receives such an ICMP error message in response, it should record in 2277 its Binding Update List that future Binding Updates should not be 2278 sent to this destination. 2280 9.10. Receiving Binding Acknowledgements 2282 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 2283 node MUST validate the packet according to the following tests: 2285 - The packet contains either an AH [7] or ESP [8] header providing 2286 sender authentication, data integrity protection, and replay 2287 protection. 2289 - The Option Length field in the option is greater than or equal to 2290 12 octets. 2292 - The Sequence Number field matches the Sequence Number sent by the 2293 mobile node to this destination address in an outstanding Binding 2294 Update. 2296 Any Binding Acknowledgement not satisfying all of these tests MUST be 2297 silently ignored, although the remainder of the packet (i.e., other 2298 options, extension headers, or payload) SHOULD be processed normally 2299 according to any procedure defined for that part of the packet. 2301 When a mobile node receives a packet carrying a valid Binding 2302 Acknowledgement, the mobile node MUST examine the Status field as 2303 follows: 2305 - If the Status field indicates that the Binding Update was 2306 accepted (the Status field is less than 128), then the mobile 2307 node MUST update the corresponding entry in its Binding Update 2308 List to indicate that the Binding Update has been acknowledged. 2309 The mobile node MUST thus stop retransmitting the Binding Update. 2311 - If the Status field indicates that the Binding Update was 2312 rejected (the Status field is greater than or equal to 128), then 2313 the mobile node MUST delete the corresponding Binding Update List 2314 entry (and MUST also stop retransmitting the Binding Update). 2315 Optionally, the mobile node MAY then take steps to correct the 2316 cause of the error and retransmit the Binding Update (with a new 2317 Sequence Number value), subject to the rate limiting restriction 2318 specified in Section 9.8. 2320 9.11. Receiving Binding Requests 2322 When a mobile node receives a packet containing a Binding Request, 2323 it SHOULD return to the sender a packet containing a Binding Update. 2324 The Lifetime field in this Binding Update SHOULD be set to a new 2325 lifetime, extending any current lifetime remaining from a previous 2326 Binding Update sent to this node (as indicated in any existing 2327 Binding Update List entry for this node). When sending this Binding 2328 Update, the mobile node MUST update its Binding Update List in the 2329 same way as for any other Binding Update sent by the mobile node. 2331 Note, however, that the mobile node MAY choose to keep its current 2332 binding private from the sender of the Binding Request. In this 2333 case, the mobile node instead SHOULD returns a Binding Update to the 2334 sender, in which the Lifetime field is set to zero. 2336 9.12. Using Multiple Care-of Addresses 2338 As described in Section 9.3, a mobile node MAY use more than one 2339 care-of address at a time. Particularly in the case of many wireless 2340 networks, a mobile node effectively might be reachable through 2341 multiple links at the same time (e.g., with overlapping wireless 2342 cells), on which different on-link subnet prefixes may exist. A 2343 mobile node SHOULD select a primary care-of address from among those 2344 care-of addresses it has formed using any of these subnet prefixes, 2345 based on the movement detection mechanism in use, as described in 2346 Section 9.2. When the mobile node selects a new primary care-of 2347 address, it MUST register it with its home agent through a Binding 2348 Update with the Home Registration (H) and Acknowledge (A) bits set, 2349 as described in Section 9.4. 2351 To assist with smooth handoffs, a mobile node SHOULD retain 2352 its previous primary care-of address as a (non-primary) care-of 2353 address, and SHOULD still accept packets at this address, even after 2354 registering its new primary care-of address with its home agent. 2355 This is reasonable, since the mobile node could only receive packets 2356 at its previous primary care-of address if it were indeed still 2357 connected to that link. If the previous primary care-of address 2358 was allocated using stateful address autoconfiguration [2], the 2359 mobile node may not wish to release the address immediately upon 2360 switching to a new primary care-of address. The stateful address 2361 autoconfiguration server will allow mobile nodes to acquire new 2362 addresses while still using previously allocated addresses. 2364 9.13. Returning Home 2366 A mobile node detects that it has returned to its home link through 2367 the movement detection algorithm in use (Section 9.2), when the 2368 mobile node detects that its home subnet prefix is again on-link. 2369 The mobile node SHOULD then send a Binding Update to its home agent, 2370 to instruct its home agent to no longer intercept or tunnel packets 2371 for it. In this Binding Update, the mobile node MUST set the care-of 2372 address for the binding (the Source Address field in the packet's 2373 IPv6 header) to the mobile node's own home address. As with other 2374 Binding Updates sent to register with its home agent, the mobile 2375 node MUST set the Acknowledge (A) and Home Registration (H) bits, 2376 and SHOULD retransmit the Binding Update until a matching Binding 2377 Acknowledgement is received. 2379 In addition, the mobile node MUST multicast onto the home link 2380 (to the all-nodes multicast address) a Neighbor Advertisement 2381 message [11], to advertise the mobile node's own link-layer address 2382 for its own home address. The Target Address in this Neighbor 2383 Advertisement message MUST be set to the mobile node's home address, 2384 and the Advertisement MUST include a Target Link-layer Address option 2385 specifying the mobile node's link-layer address. The mobile node 2386 MUST multicast such a Neighbor Advertisement message for each of its 2387 home addresses, as defined by the current on-link prefixes, including 2388 its link-local address and site-local address. The Solicited 2389 Flag (S) in these Advertisements MUST NOT be set, since they were 2390 not solicited by any Neighbor Solicitation message. The Override 2391 Flag (O) in these Advertisements MUST be set, indicating that the 2392 Advertisements SHOULD override any existing Neighbor Cache entries at 2393 any node receiving them. 2395 Since multicasts on the local link (such as Ethernet) are typically 2396 not guaranteed to be reliable, the mobile node MAY retransmit these 2397 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 2398 increase their reliability. It is still possible that some nodes on 2399 the home link will not receive any of these Neighbor Advertisements, 2400 but these nodes will eventually be able to recover through use of 2401 Neighbor Unreachability Detection [11]. 2403 10. Routing Multicast Packets 2405 A mobile node that is connected to its home link functions in the 2406 same way as any other (stationary) node. Thus, when it is at home, 2407 a mobile node functions identically to other multicast senders and 2408 receivers. This section therefore describes the behavior of a mobile 2409 node that is not on its home link. 2411 In order receive packets sent to some multicast group, a mobile 2412 node must join the that multicast group. One method by which a 2413 mobile node MAY join the group is via a (local) multicast router 2414 on the foreign link being visited. The mobile node SHOULD use its 2415 care-of address sharing a subnet prefix with the multicast router, 2416 as the source IPv6 address of its multicast group membership control 2417 messages. 2419 Alternatively, a mobile node MAY join multicast groups via a 2420 bi-directional tunnel to its home agent. The mobile node tunnels the 2421 appropriate multicast group membership control packets to its home 2422 agent, and the home agent forwards multicast packets down the tunnel 2423 to the mobile node. 2425 A mobile node that wishes to send packets to a multicast group 2426 also has two options: (1) send directly on the foreign link being 2427 visited; or (2) send via a tunnel to its home agent. Because 2428 multicast routing in general depends upon the Source Address used in 2429 the IPv6 header of the multicast packet, a mobile node that tunnels a 2430 multicast packet to its home agent MUST use its home address as the 2431 IPv6 Source Address of the inner multicast packet. 2433 11. Constants 2435 INITIAL_BINDACK_TIMEOUT 1 second 2437 MAX_BINDACK_TIMEOUT 256 seconds 2439 MAX_UPDATE_RATE once per second 2441 SLOW_UPDATE_RATE once per 10 seconds 2443 MAX_FAST_UPDATES 5 2445 MAX_ADVERT_REXMIT 3 2447 12. IANA Considerations 2449 This document defines four new types of IPv6 destination option, each 2450 of which must be assigned an Option Type value: 2452 - The Binding Update option, described in Section 5.1 2454 - The Binding Acknowledgement option, described in Section 5.2 2456 - The binding Request option, described in Section 5.3 2458 - The Home Address option, described in Section 5.4 2460 In addition, this document defines a new type of anycast address, the 2461 Home-Agents anycast address, used in the dynamic home agent address 2462 discovery procedure described in Sections 8.1 and 9.4. This anycast 2463 address must be assigned. 2465 13. Security Considerations 2467 13.1. Binding Updates, Acknowledgements, and Requests 2469 The Binding Update option described in this document will result 2470 in packets addressed to a mobile node being delivered instead to 2471 its care-of address. This ability to change the routing of these 2472 packets could be a significant vulnerability if any packet containing 2473 a Binding Update option was not authenticated. Such use of "remote 2474 redirection", for instance as performed by the Binding Update option, 2475 is widely understood to be a security problem in the current Internet 2476 if not authenticated [1]. 2478 The Binding Acknowledgement option also requires authentication, 2479 since, for example, an attacker could otherwise trick a mobile node 2480 into believing a different outcome from a registration attempt with 2481 its home agent. 2483 No authentication is required for the Binding Request option, since 2484 the use of this option does not modify or create any state in either 2485 the sender or the receiver. The Binding Request option does open 2486 some issues with binding privacy, but those issues can be dealt with 2487 either through existing IPsec encryption mechanisms or through use of 2488 firewalls. 2490 The existing IPsec replay protection mechanisms allow a "replay 2491 protection window" to support receiving packets out of order. 2492 Although appropriate for many forms of communication, Binding Updates 2493 MUST be applied only in the order sent. The Binding Update option 2494 thus includes a Sequence Number field to provide this necessary 2495 sequencing. The use of this Sequence Number together with IPsec 2496 replay protection is similar in many ways, for example, to the the 2497 sequence number in TCP. IPsec provides strong replay protection but 2498 no ordering, and the sequence number provides ordering but need not 2499 worry about replay protection such as through the sequence number 2500 wrapping around. 2502 13.2. Home Address Options 2504 No special authentication of the Home Address option is required, 2505 except that if the IPv6 header of a packet is covered by 2506 authentication, then that authentication MUST also cover the Home 2507 Address option; this coverage is achieved automatically by the 2508 definition of the Option Type code for the Home Address option 2509 (Section 5.4), since it indicates that the option is included in the 2510 authentication computation. Thus, even when authentication is used 2511 in the IPv6 header, the security of the Source Address field in the 2512 IPv6 header is not compromised by the presence of a Home Address 2513 option. Without authentication of the packet, then any field in the 2514 IPv6 header, including the Source Address field, and any other parts 2515 of the packet, including the Home Address option, can be forged or 2516 modified in transit. In this case, the contents of the Home Address 2517 option is no more suspect than any other part of the packet. 2519 The use of the Home Address option allows packets sent by a 2520 mobile node to pass normally through routers implementing ingress 2521 filtering [6]. Since the care-of address used in Source Address 2522 field of the packet's IPv6 header is topologically correct for the 2523 sending location of the mobile node, ingress filtering can trace the 2524 location of the mobile node in the same way as can be done with any 2525 sender when ingress filtering is in use. 2527 However, if a node receiving a packet that includes a Home Address 2528 option implements the processing of this option by physically 2529 copying the Home Address field from the option into the IPv6 header, 2530 replacing the Source Address field there, then the ability to 2531 trace the true location of the sender is removed once this step 2532 in the processing is performed. This diminishing of the power of 2533 ingress filtering only occurs once the packet has been received at 2534 its ultimate destination, and does not affect the capability of 2535 ingress filtering while the packet is in transit. Furthermore, this 2536 diminishing can be entirely eliminated by appropriate implementation 2537 techniques in the receiving node. For example, the original contents 2538 of the Source Address field (the sending care-of address) could be 2539 saved elsewhere in memory with the packet, until all processing of 2540 the packet is completed. 2542 13.3. General Mobile Computing Issues 2544 The mobile computing environment is potentially very different from 2545 the ordinary computing environment. In many cases, mobile computers 2546 will be connected to the network via wireless links. Such links 2547 are particularly vulnerable to passive eavesdropping, active replay 2548 attacks, and other active attacks. Furthermore, mobile computers 2549 are more susceptible to loss or theft than stationary computers. 2550 Any secrets such as authentication or encryption keys stored on the 2551 mobile computer are thus subject to compromise in ways generally not 2552 common in the non-mobile environment. 2554 Users who have sensitive data that they do not wish others to have 2555 access to should use additional mechanisms (such as encryption) to 2556 provide privacy protection, but such mechanisms are beyond the scope 2557 of this document. Users concerned about traffic analysis should 2558 consider appropriate use of link encryption. If stronger location 2559 privacy is desired, the mobile node can create a tunnel to its home 2560 agent. Then, packets destined for correspondent nodes will appear 2561 to emanate from the home subnet, and it may be more difficult to 2562 pinpoint the location of the mobile node. Such mechanisms are all 2563 beyond the scope of this document. 2565 Appendix A. Changes from Previous Draft 2567 This appendix briefly lists some of the major changes in this 2568 draft relative to the previous version of this same draft, 2569 draft-ietf-mobileip-ipv6-03.txt: 2571 - Added a statement of some non-goals of the protocol in Section 1. 2573 - Added definition for "home link" and "home subnet prefix", 2574 replacing the old term "home subnet". The new terms "foreign 2575 link" and "foreign subnet prefix" likewise replace the old term 2576 "foreign subnet". This change is more in line with current IPv6 2577 terminology. 2579 - Moved the "Comparison with Mobile IP for IPv4" section (now 2580 Section 2) to earlier in the document to allow those familiar 2581 with Mobile IPv4 to quickly see the major differences. 2583 - Added specific language in Section overview listing the fields 2584 conceptually present in each Binding Cache entry and in each 2585 Binding Update List entry. 2587 - Changed the Option Type values for the Binding Acknowledgement 2588 and Binding Request options such that they now indicate that the 2589 option should be ignored if not recognized, rather than returning 2590 an ICMP error message as they were previously defined. 2592 - Increased the Lifetime field in a Binding Update from 16 bits 2593 to 32 bits, to allow consistency with other lifetime values 2594 used in IPv6 (e.g., the lifetime of a subnet prefix in Neighbor 2595 Discovery [11]). Similarly increased the Lifetime and Refresh 2596 fields in the Binding Acknowledgement from 16 bits to 32 bits. 2598 - Replaced the Home Link-Local Address Present (L) bit and the 2599 Home Link-Local Address field in the Binding Update with a new 2600 mechanism implemented by the ID Length field in the Binding 2601 Update. By specifying the length of the interface identifier in 2602 its home address in this field, the mobile node can request its 2603 home agent to essentially fully participate in Neighbor Discovery 2604 on the home link as a proxy for the mobile node, while the mobile 2605 node is away from home. 2607 - Clarified that packets addressed to a mobile node's link-local 2608 address or site-local address are not forwarded to the mobile 2609 node while away from home. When intercepted by the mobile node's 2610 home agent, such packets now cause the home agent to return an 2611 ICMP Destination Unreachable, Code 3, message to the packet's 2612 Source Address (unless this Source Address is a multicast 2613 address). As the use of link-local addresses or site-local 2614 addresses evolves over time in IPv6, this disposition of such 2615 packets may need to change, however. 2617 - Added a discussion of sending Binding Requests in Section 7.6, 2618 and added a discussion of receiving Binding Requests in 2619 Section 9.11. 2621 - Change the requirement for sending a Binding Update to a mobile 2622 node's previous default router in Section 9.6 from "SHOULD" to 2623 "MAY". 2625 - Added Section 12 on "IANA Considerations". 2627 - Replaced the description of specification language keywords, 2628 "MUST", "MAY", "SHOULD", etc., in Section 3.3 with the new 2629 standard reference to RFC 2119. 2631 - Updated the References to point to the most recent version of 2632 each cited RFC or Internet-Draft. 2634 Acknowledgements 2636 We would like to thank the members of the Mobile IP and IPng Working 2637 Groups for their comments and suggestions on this work. We would 2638 particularly like to thank Thomas Narten, Erik Nordmark, and Jim 2639 Solomon for their detailed reviews of earlier versions of this 2640 draft. Their suggestions have helped to improve both the design and 2641 presentation of the protocol. 2643 References 2645 [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 2646 ACM Computer Communications Review, 19(2), March 1989. 2648 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 2649 Protocol for IPv6 (DHCPv6). Internet-Draft, 2650 draft-ietf-dhc-dhcpv6-10.txt, May 1997. Work in progress. 2652 [3] Scott Bradner. Key words for use in RFCs to indicate 2653 requirement levels. RFC 2119, March 1997. 2655 [4] Alex Conta and Stephen Deering. Generic packet 2656 tunneling in IPv6 specification. Internet-Draft, 2657 draft-ietf-ipngwg-ipv6-tunnel-07.txt, December 1996. 2658 Work in progress. 2660 [5] Stephen E. Deering and Robert M. Hinden. Internet 2661 Protocol version 6 (IPv6) specification. Internet-Draft, 2662 draft-ietf-ipngwg-ipv6-spec-v2-00.txt, July 1997. Work in 2663 progress. 2665 [6] Paul Ferguson and Daniel Senie. Network ingress 2666 filtering: Defeating denial of service attacks which 2667 employ IP source address spoofing. Internet-Draft, 2668 draft-ferguson-ingress-filtering-03.txt, October 1997. Work in 2669 progress. 2671 [7] Stephen Kent and Randall Atkinson. IP Authentication header. 2672 Internet-Draft, draft-ietf-ipsec-auth-header-02.txt, October 2673 1997. Work in progress. 2675 [8] Stephen Kent and Randall Atkinson. IP Encapsulating Security 2676 Payload (ESP). Internet-Draft, draft-ietf-ipsec-esp-v2-01.txt, 2677 October 1997. Work in progress. 2679 [9] P. Mockapetris. Domain Names---concepts and facilities. 2680 RFC 1034, November 1987. 2682 [10] P. Mockapetris. Domain Names---implementation and 2683 specification. RFC 1035, November 1987. 2685 [11] Thomas Narten, Erik Nordmark, and William Allen Simpson. 2686 Neighbor Discovery for IP version 6 (IPv6). Internet-Draft, 2687 draft-ietf-ipngwg-discovery-v2-00.txt, July 1997. Work in 2688 progress. 2690 [12] Charles Perkins. IP encapsulation within IP. RFC 2003, October 2691 1996. 2693 [13] Charles Perkins, editor. IP mobility support. RFC 2002, 2694 October 1996. 2696 [14] Charles Perkins. Minimal encapsulation within IP. RFC 2004, 2697 October 1996. 2699 [15] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 2701 [16] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 2702 September 1981. 2704 [17] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 2705 October 1994. 2707 [18] Susan Thomson and Thomas Narten. IPv6 stateless address 2708 autoconfiguration. Internet-Draft, 2709 draft-ietf-ipngwg-addrconf-v2-00.txt, July 1997. 2711 Chair's Address 2713 The Working Group can be contacted via its current chairs: 2715 Jim Solomon 2716 Motorola, Inc. 2717 1301 E. Algonquin Rd. 2718 Schaumburg, IL 60196 2719 USA 2721 Phone: +1 847 576-2753 2722 E-mail: solomon@comm.mot.com 2724 Erik Nordmark 2725 Sun Microsystems, Inc. 2726 2550 Garcia Avenue 2727 Mt. View, CA 94041 2728 USA 2730 Phone: +1 415 786-5166 2731 Fax: +1 415 786-5896 2732 E-mail: nordmark@sun.com 2734 Authors' Addresses 2736 Questions about this document can also be directed to the authors: 2738 David B. Johnson 2739 Carnegie Mellon University 2740 Computer Science Department 2741 5000 Forbes Avenue 2742 Pittsburgh, PA 15213-3891 2743 USA 2745 Phone: +1 412 268-7399 2746 Fax: +1 412 268-5576 2747 E-mail: dbj@cs.cmu.edu 2749 Charles Perkins 2750 Sun Microsystems, Inc. 2751 Technology Development Group 2752 Mail Stop MPK15-214 2753 Room 2682 2754 901 San Antonio Road 2755 Palo Alto, CA 94303 2756 USA 2758 Phone: +1 415 786-6464 2759 Fax: +1 415 786-6445 2760 E-mail: cperkins@eng.sun.com