idnits 2.17.1 draft-ietf-mobileip-ipv6-05.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-23) 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (13 March 1998) is 9538 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 ** Obsolete normative reference: RFC 2267 (ref. '6') (Obsoleted by RFC 2827) == 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: 10 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group David B. Johnson 3 INTERNET-DRAFT Carnegie Mellon University 4 Charles Perkins 5 Sun Microsystems 6 13 March 1998 8 Mobility Support in IPv6 10 12 Status of This Memo 14 This document is a submission by the Mobile IP Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 This document specifies the operation of mobile computers using IPv6. 38 Each mobile node is always identified by its home address, regardless 39 of its current point of attachment to the Internet. While situated 40 away from its home, a mobile node is also associated with a care-of 41 address, which provides information about the mobile node's current 42 location. IPv6 packets addressed to a mobile node's home address are 43 transparently routed to its care-of address. The protocol enables 44 IPv6 nodes to cache the binding of a mobile node's home address with 45 its care-of address, and to then send any packets destined for the 46 mobile node directly to it at this care-of address. 48 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 1 56 2. Comparison with Mobile IP for IPv4 3 58 3. Terminology 4 59 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Specification Language . . . . . . . . . . . . . . . . . 6 63 4. Overview of Mobile IPv6 7 64 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 9 66 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 11 67 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 14 69 5. New IPv6 Destination Options 16 70 5.1. Binding Update Option Format . . . . . . . . . . . . . . 16 71 5.2. Binding Acknowledgement Option Format . . . . . . . . . . 20 72 5.3. Binding Request Option Format . . . . . . . . . . . . . . 24 73 5.4. Home Address Option Format . . . . . . . . . . . . . . . 25 75 6. Modifications to IPv6 Neighbor Discovery 27 76 6.1. Router Advertisement Message Format . . . . . . . . . . . 27 77 6.2. Advertisement Interval Option Format . . . . . . . . . . 28 78 6.3. Changes to MinRtrAdvInterval Limits . . . . . . . . . . . 29 80 7. Requirements for IPv6 Nodes 30 81 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 30 82 7.2. Requirements for IPv6 Home Agents . . . . . . . . . . . . 30 83 7.3. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 31 85 8. Correspondent Node Operation 32 86 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 32 87 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 32 88 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 33 89 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 34 90 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 34 91 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 34 92 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 35 93 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 36 94 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 37 96 9. Home Agent Operation 39 97 9.1. Receiving Router Advertisement Messages . . . . . . . . . 39 98 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 39 99 9.3. Primary Care-of Address Registration . . . . . . . . . . 40 100 9.4. Primary Care-of Address De-registration . . . . . . . . . 43 101 9.5. Tunneling Intercepted Packets to a Mobile Node . . . . . 44 102 9.6. Renumbering the Home Subnet . . . . . . . . . . . . . . . 44 104 10. Mobile Node Operation 46 105 10.1. Sending Packets While Away from Home . . . . . . . . . . 46 106 10.2. Movement Detection . . . . . . . . . . . . . . . . . . . 48 107 10.3. Forming New Care-of Addresses . . . . . . . . . . . . . . 50 108 10.4. Sending Binding Updates to the Home Agent . . . . . . . . 51 109 10.5. Sending Binding Updates to Correspondent Nodes . . . . . 53 110 10.6. Sending Binding Updates to the Previous Default Router . 55 111 10.7. Retransmitting Binding Updates . . . . . . . . . . . . . 55 112 10.8. Rate Limiting for Sending Binding Updates . . . . . . . . 56 113 10.9. Receiving ICMP Error Messages . . . . . . . . . . . . . . 56 114 10.10. Receiving Binding Acknowledgements . . . . . . . . . . . 57 115 10.11. Receiving Binding Requests . . . . . . . . . . . . . . . 58 116 10.12. Using Multiple Care-of Addresses . . . . . . . . . . . . 58 117 10.13. Routing Multicast Packets . . . . . . . . . . . . . . . . 58 118 10.14. Returning Home . . . . . . . . . . . . . . . . . . . . . 59 120 11. Constants 61 122 12. IANA Considerations 62 124 13. Security Considerations 63 125 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 63 126 13.2. Home Address Options . . . . . . . . . . . . . . . . . . 63 127 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 64 129 Changes from Previous Draft 66 131 Acknowledgements 68 133 References 69 135 Chair's Address 71 137 Authors' Addresses 72 138 1. Introduction 140 This document specifies the operation of mobile computers using 141 Internet Protocol Version 6 (IPv6) [5]. Without specific support 142 for mobility in IPv6, packets destined to a mobile node (host or 143 router) would not be able to reach it while the mobile node is away 144 from its home link (the link on which its home IPv6 subnet prefix is 145 in use), since routing is based on the subnet prefix in a packet's 146 destination IP address. In order to continue communication in spite 147 of its movement, a mobile node could change its IP address each time 148 it moves to a new link, but the mobile node would then not be able 149 to maintain transport and higher-layer connections when it changes 150 location. Mobility support in IPv6 is particularly important, as 151 mobile computers are likely to account for a majority or at least a 152 substantial fraction of the population of the Internet during the 153 lifetime of IPv6. 155 The protocol operation defined here, known as Mobile IPv6, allows a 156 mobile node to move from one link to another without changing the 157 mobile node's IP address. A mobile node is always addressable by 158 its "home address", an IP address assigned to the mobile node within 159 its home subnet prefix on its home link. Packets may be routed to 160 the mobile node using this address regardless of the mobile node's 161 current point of attachment to the Internet, and the mobile node may 162 continue to communicate with other nodes (stationary or mobile) after 163 moving to a new link. The movement of a mobile node away from its 164 home link is thus transparent to transport and higher-layer protocols 165 and applications. 167 The Mobile IPv6 protocol is just as suitable for mobility across 168 homogeneous media as for mobility across heterogeneous media. For 169 example, Mobile IPv6 facilitates node movement from one Ethernet 170 segment to another as well as it facilitates node movement from an 171 Ethernet segment to a wireless LAN cell, with the mobile node's IP 172 address remaining unchanged in spite of such movement. 174 One can think of the Mobile IPv6 protocol as solving the "macro" 175 mobility management problem. More "micro" mobility management 176 applications -- for example, handoff among wireless transceivers, 177 each of which covers only a very small geographic area -- are 178 possibly more suited to other solutions. For example, in many 179 current wireless LAN products, link-layer mobility mechanisms allow a 180 "handoff" of a mobile node from one cell to another, reestablishing 181 link-layer connectivity to the node in each new location. As long 182 as such handoff occurs only within cells of the mobile node's home 183 link, such link-layer mobility mechanisms are likely to offer faster 184 convergence and lower overhead than Mobile IPv6. Extensions to the 185 Mobile IPv6 protocol are also possible to support a more local, 186 hierarchical form of mobility management, but such extensions are 187 beyond the scope of this document. 189 The protocol specified in this document solves the problem of 190 transparently routing packets to and from mobile nodes while away 191 from home. However, it does not attempt to solve all general 192 problems related to the use of mobile computers or wireless networks. 193 In particular, this protocol does not attempt to solve: 195 - Handling links with partial reachability, such as typical 196 wireless networks. Some aspects of this problem are addressed 197 by the movement detection procedure described in Section 10.2, 198 but no attempt has been made to fully solve this problem in its 199 general form. Most aspects of this problem can be solved by the 200 workaround of restricting such networks to only one router per 201 link, although there are still possible hidden terminal problems 202 when two nodes on the same link (on opposite sides of the router) 203 attempt to communicate directly. 205 - Access control on a link being visited by a mobile node. This 206 is a general problem any time an untrusted node is allowed 207 to connect to any link layer. It is independent whether the 208 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 209 address on the link. 211 2. Comparison with Mobile IP for IPv4 213 [This section will include a comparison between the Mobile IPv6 214 protocol and the Mobile IPv4 protocol [13, 12, 14]. However, this 215 comparison has not yet been written. It will be filled in with the 216 next revision to this draft.] 218 3. Terminology 220 3.1. General Terms 222 IP 224 Internet Protocol Version 6 (IPv6). 226 node 228 A device that implements IP. 230 router 232 A node that forwards IP packets not explicitly addressed to 233 itself. 235 host 237 Any node that is not a router. 239 link 241 A communication facility or medium over which nodes can 242 communicate at the link layer, such as an Ethernet (simple or 243 bridged). A link is the layer immediately below IP. 245 interface 247 A node's attachment to a link. 249 subnet prefix 251 A bit string that consists of some number of initial bits of an 252 IP address. 254 interface identifier 256 A number used to identify a node's interface on a link. The 257 interface identifier is the remaining low-order bits in the 258 node's IP address after the subnet prefix. 260 link-layer address 262 A link-layer identifier for an interface, such as IEEE 802 263 addresses on Ethernet links. 265 packet 267 An IP header plus payload. 269 3.2. Mobile IPv6 Terms 271 home address 273 An IP address assigned to a mobile node within its home link. 275 home subnet prefix 277 The IP subnet prefix corresponding to a mobile node's home 278 address. 280 home link 282 The link on which a mobile node's home subnet prefix is 283 defined. Standard IP routing mechanisms will deliver packets 284 destined for a mobile node's home address to its home link. 286 mobile node 288 A node that can change its point of attachment from one link to 289 another, while still being reachable via its home address. 291 movement 293 A change in a mobile node's point of attachment to the Internet 294 such that it is no longer connected to the same link as it was 295 previously. If a mobile node is not currently attached to its 296 home link, the mobile node is said to be "away from home". 298 correspondent node 300 A peer node with which a mobile node is communicating. The 301 correspondent node may be either mobile or stationary. 303 foreign subnet prefix 305 Any IP subnet prefix other than the mobile node's home subnet 306 prefix. 308 foreign link 310 Any link other than the mobile node's home link. 312 home agent 314 A router on a mobile node's home link with which the mobile 315 node has registered its current care-of address. While the 316 mobile node is away from home, the home agent intercepts 317 packets on the home link destined to the mobile node's home 318 address, encapsulates them, and tunnels them to the mobile 319 node's registered care-of address. 321 care-of address 323 An IP address associated with a mobile node while visiting a 324 foreign link; the subnet prefix of this IP address is a foreign 325 subnet prefix. Among the multiple care-of addresses that a 326 mobile node may have at a time (e.g., with different subnet 327 prefixes), the one registered with the mobile node's home agent 328 is called its "primary" care-of address. 330 binding 332 The association of the home address of a mobile node with a 333 care-of address for that mobile node, along with the remaining 334 lifetime of that association. 336 3.3. Specification Language 338 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 339 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 340 document are to be interpreted as described in RFC 2119 [3]. 342 4. Overview of Mobile IPv6 344 4.1. Basic Operation 346 A mobile node is always addressable by its home address, whether it 347 is currently attached to its home link or is away from home. While 348 a mobile node is at home, packets addressed to its home address are 349 routed to it using conventional Internet routing mechanisms in the 350 same way as if the node were never mobile. Since the subnet prefix 351 of a mobile node's home address is the subnet prefix (or one of the 352 subnet prefixes) on the mobile node's home link (it is the mobile 353 node's home subnet prefix), packets addressed to it will be routed to 354 its home link. 356 While a mobile node is attached to some foreign link away from 357 home, it is also addressable by one or more care-of addresses, in 358 addition to its home address. A care-of address is an IP address 359 associated with a mobile node while visiting a particular foreign 360 link. The subnet prefix of a mobile node's care-of address is the 361 subnet prefix (or one of the subnet prefixes) on the foreign link 362 being visited by the mobile node; if the mobile node is connected 363 to this foreign link while using that care-of address, packets 364 addressed to this care-of address will be routed to the mobile node 365 in its location away from home. The association between a mobile 366 node's home address and care-of address is known as a "binding" 367 for the mobile node. A mobile node typically acquires its care-of 368 address through stateless [18] or stateful (e.g., DHCPv6 [2]) 369 address autoconfiguration, according to the methods of IPv6 Neighbor 370 Discovery [11]. Other methods of acquiring a care-of address 371 are also possible, but such methods are beyond the scope of this 372 document. 374 While away from home, the mobile node registers one of its bindings 375 with a router on its home link, requesting this router to function 376 as the "home agent" for the mobile node. This binding registration 377 is done by the mobile node sending a packet with a "Binding Update" 378 destination option to the home agent; the home agent then replies by 379 returning a packet containing a "Binding Acknowledgement" destination 380 option to the mobile node. The care-of address in this binding 381 registered with its home agent is known as the mobile node's "primary 382 care-of address". The mobile node's home agent thereafter uses proxy 383 Neighbor Discovery to intercept any IPv6 packets addressed to the 384 mobile node's home address (or home addresses) on the home link, 385 and tunnels each intercepted packet to the mobile node's primary 386 care-of address. To tunnel each intercepted packet, the home agent 387 encapsulates the packet using IPv6 encapsulation [4], with the outer 388 IPv6 header addressed to the mobile node's primary care-of address. 390 Section 10.12 discusses the reasons why it may be desirable for 391 a mobile node to use more than one care-of address at the same 392 time. However, a mobile node's primary care-of address is distinct 393 among these in that the home agent maintains only a single care-of 394 address registered for each mobile node, and always tunnels a mobile 395 node's packets intercepted from its home link to this mobile node's 396 registered primary care-of address. The home agent thus need not 397 implement any policy to determine which of possibly many care-of 398 addresses to which to tunnel each intercepted packet, leaving the 399 mobile node entirely in control of this policy by which of its 400 care-of addresses it registers with its home agent. 402 It is possible that while a mobile node is away from home, some nodes 403 on its home link may be reconfigured, such that the router that was 404 operating as the mobile node's home agent is replaced by a different 405 router serving this role. In this case, the mobile node may not 406 know the IP address of its own home agent. Mobile IPv6 provides a 407 mechanism, known as "dynamic home agent address discovery", that 408 allows a mobile node to dynamically discover the IP address of a home 409 agent on its home link with which it may register its care-of address 410 while away from home. The mobile node sends a Binding Update to the 411 "Home-Agents anycast address" for its home subnet prefix and thus 412 reaches one of the (possibly many) routers on its home link currently 413 operating as a home agent. This home agent rejects the mobile 414 node's Binding Update, but returns in the Binding Acknowledgement 415 in response a list of all home agents on the home link. This list 416 of home agents is maintained by each home agent on the home link 417 through use of the Home Agent (H) bit in each home agent's periodic 418 unsolicited multicast Router Advertisements. 420 The Binding Update and Binding Acknowledgement destination options, 421 together with a "Binding Request" destination option, are also used 422 to allow IPv6 nodes communicating with a mobile node, to dynamically 423 learn and cache the mobile node's binding. When sending a packet 424 to any IPv6 destination, a node checks its cached bindings for an 425 entry for the packet's destination address. If a cached binding for 426 this destination address is found, the node uses an IPv6 Routing 427 header [5] (instead of IPv6 encapsulation) to route the packet to 428 the mobile node by way of the care-of address indicated in this 429 binding. If, instead, the sending node has no cached binding for 430 this destination address, the node sends the packet normally (with 431 no Routing header), and the packet is subsequently intercepted and 432 tunneled by the mobile node's home agent as described above. A node 433 communicating with a mobile node is referred to in this document as a 434 "correspondent node" of the mobile node. 436 Since a Binding Update, Binding Acknowledgement, and Binding Request 437 are each represented in a packet as an IPv6 destination option [5], 438 they may be included in any IPv6 packet. Any of these options can be 439 sent in either of two ways: 441 - A Binding Update, Binding Acknowledgement, or Binding Request can 442 be included within any IPv6 packet carrying any payload such as 443 TCP [16] or UDP [15]. 445 - A Binding Update, Binding Acknowledgement, or Binding Request can 446 be sent as a separate IPv6 packet containing no payload. In this 447 case, the Next Header field in the last extension header in the 448 packet is set to the value 59, to indicate "No Next Header" [5]. 450 Mobile IPv6 also defines one additional IPv6 destination option. 451 When a mobile node sends a packet while away from home, it will 452 generally set the Source Address in the packet's IPv6 header to one 453 of its current care-of addresses, and will also include a "Home 454 Address" destination option in the packet, giving the mobile node's 455 home address. Many routers implement security policies such as 456 "ingress filtering" [6] that do not allow forwarding of packets 457 that appear to have a Source Address that is not topologically 458 correct. By using the care-of address as the IPv6 header Source 459 Address, the packet will be able to pass normally through such 460 routers, yet ingress filtering rules will still be able to locate 461 the true physical source of the packet in the same way as packets 462 from non-mobile nodes. By also including the Home Address option, 463 the sending mobile node can communicate its home address to the 464 correspondent node receiving this packet, allowing the use of the 465 care-of address to be transparent above the Mobile IPv6 support 466 level (e.g., at the transport layer). The inclusion of a Home 467 Address option in a packet affects only the correspondent node's 468 receipt of this single packet; no state is created or modified in the 469 correspondent node as a result of receiving a Home Address option in 470 a packet. 472 4.2. New IPv6 Destination Options 474 As discussed in general in Section 4.1, the following four new IPv6 475 destination options are defined for Mobile IPv6: 477 Binding Update 479 A Binding Update option is used by a mobile node to notify 480 a correspondent node or the mobile node's home agent of 481 its current binding. The Binding Update sent to the mobile 482 node's home agent to register its primary care-of address is 483 marked as a "home registration". Any packet that includes a 484 Binding Update option MUST also include either an AH [7] or 485 ESP [8] header providing sender authentication, data integrity 486 protection, and replay protection. The Binding Update option 487 is described in detail in Section 5.1. 489 Binding Acknowledgement 491 A Binding Acknowledgement option is used to acknowledge receipt 492 of a Binding Update, if an acknowledgement was requested 493 in the Binding Update. Any packet that includes a Binding 494 Acknowledgement option MUST also include either an AH [7] or 495 ESP [8] header providing sender authentication, data integrity 496 protection, and replay protection. The Binding Acknowledgement 497 option is described in detail in Section 5.2. 499 Binding Request 501 A Binding Request option is used to request a mobile node 502 to send a Binding Update to the requesting node, containing 503 the mobile node's current binding. This option is typically 504 used by a correspondent node to refresh a cached binding for 505 a mobile node, when the cached binding is in active use but 506 the binding's lifetime is close to expiration. No special 507 authentication is required for the Binding Request option. The 508 Binding Request option is described in detail in Section 5.3. 510 Home Address 512 A Home Address option is used in a packet sent by a mobile 513 node to inform the recipient of that packet of the mobile 514 node's home address. For packets sent by a mobile node while 515 away from home, the mobile node generally uses one of its 516 care-of addresses as the Source Address in the packet's IPv6 517 header. By including a Home Address option in the packet, the 518 correspondent node receiving the packet is able to substitute 519 the mobile node's home address for this care-of address when 520 processing the packet, thus making the use of the care-of 521 address transparent to the correspondent node. If the IP 522 header of a packet carrying a Home Address option is covered 523 by authentication, then the Home Address option MUST also 524 be covered by this authentication, but no other special 525 authentication is required for the Home Address option. The 526 Home Address option is described in detail in Section 5.4. 528 Extensions to the format of these options MAY be included after the 529 fixed portion of the option data specified in this document. The 530 presence of such extensions will be indicated by the Option Length 531 field within the option. When the Option Length is greater than the 532 length required for the option specified here, the remaining octets 533 are interpreted as extensions. Currently, no extensions have been 534 defined. 536 4.3. Conceptual Data Structures 538 This document describes the Mobile IPv6 protocol in terms of the 539 following three conceptual data structures used in the maintenance of 540 cached bindings: 542 Binding Cache 544 A cache, maintained by each IPv6 node, of bindings for 545 other nodes. The Binding Cache MAY be implemented in any 546 manner consistent with the external behavior described 547 in this document, for example by being combined with the 548 node's Destination Cache as maintained through Neighbor 549 Discovery [11]. When sending a packet, the Binding Cache 550 MUST be searched before the Neighbor Discovery conceptual 551 Destination Cache [11]. Each Binding Cache entry conceptually 552 contains the following fields: 554 - The home address of the mobile node for which this is the 555 Binding Cache entry. This field is used as the key for 556 searching the Binding Cache for the destination address of 557 a packet being routed. If the destination address of the 558 packet matches the home address in the Binding Cache entry, 559 this entry SHOULD be used in routing that packet. 561 - The care-of address for the mobile node indicated by 562 the home address field in this Binding Cache entry. If 563 the destination address of a packet being routed by a 564 node matches the home address in this entry, the packet 565 SHOULD be routed to this care-of address, as described in 566 Section 8.9, for packets originated by this node, or in 567 Section 9.5, if this node is the mobile node's home agent 568 and the packet was intercepted by it on the home link. 570 - A lifetime value, indicating the remaining lifetime 571 for this Binding Cache entry. The lifetime value is 572 initialized from the Lifetime field in the Binding Update 573 that created or last modified this Binding Cache entry. 574 Once the lifetime on this entry expires, the entry MUST be 575 deleted from the Binding Cache. 577 - A flag indicating whether or not this Binding Cache entry 578 is a "home registration" entry. 580 - The value of the Prefix Length field received in the 581 Binding Update that created or last modified this Binding 582 Cache entry. 584 - The maximum value of the Sequence Number field received in 585 previous Binding Updates for this mobile node home address. 587 All comparisons between Sequence Number values MUST be 588 performed modulo 2**16. 590 - Recent usage information for this Binding Cache entry, 591 as needed for the cache replacement policy in use in the 592 Binding Cache and to assist in determining whether a 593 Binding Request should be sent when the lifetime on this 594 entry nears expiration. 596 - The time at which a Binding Request was last sent for this 597 entry, as needed to implement the rate limiting restriction 598 for sending Binding Requests. 600 An entry in a node's Binding Cache for which the node is 601 serving as a home agent is marked as a "home registration" 602 entry and SHOULD NOT be deleted by the home agent until the 603 expiration of its binding lifetime. Other Binding Cache 604 entries MAY be replaced at any time by any reasonable local 605 cache replacement policy but SHOULD NOT be unnecessarily 606 deleted. Any node's Binding Cache may contain at most one 607 entry for each mobile node home address. The contents of a 608 node's Binding Cache MUST NOT be changed in response to a Home 609 Address option in a received packet. 611 Binding Update List 613 A list, maintained by each mobile node, recording information 614 for each Binding Update sent by this mobile node, for which 615 the Lifetime sent in that Binding Update has not yet expired. 616 The Binding Update List includes all bindings sent by the 617 mobile node: those to correspondent nodes, to the mobile 618 node's home agent, and to a previous default router of the 619 mobile node. The Binding Update List MAY be implemented in any 620 manner consistent with the external behavior described in this 621 document. Each Binding Update List entry conceptually contains 622 the following fields: 624 - The IP address of the node to which a Binding Update was 625 sent. This node might still have a Binding Cache entry 626 derived from this Binding Update, if the Binding Update was 627 successfully received by that node (e.g., not lost by the 628 network) and if that node has not deleted the entry before 629 its expiration (e.g., to reclaim space in its Binding Cache 630 for other entries). 632 - The home address for which that Binding Update was sent. 633 This will be the mobile node's home address for most 634 Binding Updates (Sections 10.4 and 10.5), but will be 635 the mobile node's previous care-of address for Binding 636 Updates sent to the mobile node's previous default router 637 (Section 10.6). 639 - The care-of address sent in that Binding Update. This 640 value is necessary for determining if the mobile node has 641 sent a Binding Update giving its new care-of address to 642 this destination after changing its care-of address. 644 - The remaining lifetime of that binding. This lifetime is 645 initialized from the Lifetime value sent in the Binding 646 Update and is decremented until it reaches zero, at which 647 time this entry MUST be deleted from the Binding Update 648 List. 650 - The maximum value of the Sequence Number field sent 651 in previous Binding Updates to this destination. All 652 comparisons between Sequence Number values MUST be 653 performed modulo 2**16. 655 - The state of any retransmissions needed for this Binding 656 Update, if the Acknowledge (A) bit was set in this Binding 657 Update. This state includes the time remaining until the 658 next retransmission attempt for the Binding Update, and 659 the current state of the exponential back-off process for 660 retransmissions. 662 - The time at which a Binding Update was last sent to this 663 destination, as needed to implement the rate limiting 664 restriction for sending Binding Updates. 666 - A flag that, when set, indicates that future Binding 667 Updates should not be sent to this destination. The 668 mobile node sets this flag in the Binding Update List 669 entry when it receives an ICMP Parameter Problem, Code 2, 670 error message in response to a Binding Update sent to that 671 destination, as described in Section 10.9. 673 Home Agents List 675 A list, maintained by each home agent, recording the IP address 676 of each other home agent on a link on which this node is 677 serving as a home agent; the home agent maintains a separate 678 Home Agents List for each such link on which it is serving. 679 This list is used in the dynamic home agent address discovery 680 mechanism. The information for the list is learned through 681 receipt of periodic unsolicited multicast Router Advertisements 682 from each other home agent on the link, in which the Home 683 Agent (H) bit is set, in a manner similar to the Default 684 Router List conceptual data structure maintained by each host 685 for Neighbor Discovery [11]. The Home Agents List MAY be 686 implemented in any manner consistent with the external behavior 687 described in this document. Each Home Agents List entry 688 conceptually contains the following fields: 690 - The IP address of another router on the home link that this 691 node currently believes is operating as a home agent for 692 this link. A new entry is created or an existing entry is 693 updated in the Home Agents List in response to receipt of a 694 valid Router Advertisement in which the Home Agent (H) bit 695 is set. 697 - The remaining lifetime of this Home Agents List entry. The 698 lifetime is initialized from the Router Lifetime field in 699 the received Router Advertisement and is decremented until 700 it reaches zero, at which time this entry MUST be deleted 701 from the Home Agents List. 703 4.4. Binding Management 705 When a mobile node configures a new care-of address and decides to 706 use this new address as its primary care-of address, the mobile 707 node registers this new binding with its home agent by sending 708 the home agent a Binding Update. The mobile node indicates 709 that an acknowledgement is needed for this Binding Update and 710 continues to periodically retransmit it until acknowledged. The 711 home agent acknowledges the Binding Update by returning a Binding 712 Acknowledgement to the mobile node. 714 When a mobile node receives a packet tunneled to it from its 715 home agent, the mobile node assumes that the original sending 716 correspondent node has no Binding Cache entry for the mobile node, 717 since the correspondent node would otherwise have sent the packet 718 directly to the mobile node using a Routing header. The mobile node 719 thus returns a Binding Update to the correspondent node, allowing 720 it to cache the mobile node's binding for routing future packets. 721 Although the mobile node may request an acknowledgement for this 722 Binding Update, it need not, since subsequent packets from the 723 correspondent node will continue to be intercepted and tunneled by 724 the mobile node's home agent, effectively causing any needed Binding 725 Update retransmission. 727 A correspondent node with a Binding Cache entry for a mobile node 728 may refresh this binding, for example if the binding's lifetime 729 is near expiration, by sending a Binding Request to the mobile 730 node. Normally, a correspondent node will only refresh a Binding 731 Cache entry in this way if it is actively communicating with the 732 mobile node and has indications, such as an open TCP connection to 733 the mobile node, that it will continue this communication in the 734 future. When a mobile node receives a Binding Request, it replies by 735 returning a Binding Update to the node sending the Binding Request. 737 A mobile node may use more than one care-of address at the same 738 time, although only one care-of address may be registered for it at 739 its home agent as its primary care-of address. The mobile node's 740 home agent will tunnel all intercepted packets for the mobile node 741 to its (single) registered primary care-of address, but the mobile 742 node will accept packets that it receives at any of its current 743 care-of addresses. Use of more than one care-of address by a mobile 744 node may be useful, for example, to improve smooth handoff when the 745 mobile node moves from one wireless link to another. If each of 746 these wireless links is connected to the Internet through a separate 747 base station, such that the wireless transmission range from the 748 two base stations overlap, the mobile node may be able to remain 749 connected to both links while in the area of overlap. In this case, 750 the mobile node could acquire a new care-of address on the new link 751 before moving out of transmission range and disconnecting from the 752 old link. The mobile node may thus still accept packets at its 753 old care-of address while it works to update its home agent and 754 correspondent nodes, notifying them of its new care-of address on the 755 new link. 757 Since correspondent nodes cache bindings, it is expected that 758 correspondent nodes usually will route packets directly to the mobile 759 node's care-of address, so that the home agent is rarely involved 760 with packet transmission to the mobile node. This is essential for 761 scalability and reliability, and for minimizing overall network load. 762 By caching the care-of address of a mobile node, optimal routing of 763 packets can be achieved from the correspondent node to the mobile 764 node. Routing packets directly to the mobile node's care-of address 765 also eliminates congestion at the mobile node's home agent and home 766 link. In addition, the impact of any possible failure of the home 767 agent, the home link, or intervening networks leading to or from the 768 home link is reduced, since these nodes and links are not involved in 769 the delivery of most packets to the mobile node. 771 5. New IPv6 Destination Options 773 5.1. Binding Update Option Format 775 The Binding Update destination option is used by a mobile node to 776 notify other nodes of a new care-of address. 778 The Binding Update option is encoded in type-length-value (TLV) 779 format as follows: 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Option Type | Option Length | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 |A|H|C| Reserved| Prefix Length | Sequence Number | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Lifetime | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | | 791 + + 792 | | 793 + Care-of Address + 794 | (only present if C bit set) | 795 + + 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Option Type 801 195 ??? 803 Option Length 805 8-bit unsigned integer. Length of the option, in octets, 806 excluding the Option Type and Option Length fields. For the 807 current definition of the Binding Update option, the minimum 808 value for this field is 8; the length is 24 if the Care-of 809 Address Present (C) bit is set. 811 Acknowledge (A) 813 The Acknowledge (A) bit is set by the sending node to request a 814 Binding Acknowledgement (Section 5.2) be returned upon receipt 815 of the Binding Update option. 817 Home Registration (H) 819 The Home Registration (H) bit is set by the sending mobile node 820 to request the receiving node to act as this node's home agent. 822 The Destination Address in the IP header of the packet carrying 823 this option MUST be that of a router sharing the same subnet 824 prefix as the home address of the mobile node in the binding 825 (given by the Home Address field in the Home Address option in 826 the packet). 828 Care-of Address Present (C) 830 The Care-of Address Present (C) bit indicates the presence of 831 the Care-of Address field in the Binding Update. The care-of 832 address for this binding is either the address in the Care-of 833 Address field in the Binding Update, if this bit is set, or the 834 Source Address in the packet's IPv6 header, if this bit is not 835 set. 837 Reserved 839 Sent as 0; ignored on reception. 841 Prefix Length 843 The Prefix Length field is valid only for a "home registration" 844 Binding Update. This field MUST be zero if the Home 845 Registration (H) bit is not set in the Binding Update. The 846 Prefix Length field is set by the sending mobile node to the 847 (nonzero) length of its subnet prefix in its home address 848 (given in the Home Address option in the packet) to request 849 its home agent to use the interface identifier in the mobile 850 node's home address (the remaining low-order bits after the 851 indicated subnet prefix) to form all other appropriate home 852 addresses for the mobile node. The home agent becomes the 853 home agent not only for the individual home address given in 854 this binding, but also for all other home addresses for this 855 mobile node formed from this interface identifier. That is, 856 for each on-link prefix on the home link, the home agent uses 857 the interface identifier to form other valid addresses for the 858 mobile node on the home link, and acts as a home agent also 859 for those addresses. In addition, the home agent forms the 860 link-local address and site-local address corresponding to 861 this interface identifier, and defends each for purposes of 862 Duplicate Address Detection. Details of this operation are 863 described in Section 9.3. 865 Sequence Number 867 Used by the receiving node to sequence Binding Updates and by 868 the sending node to match a returned Binding Acknowledgement 869 with this Binding Update. Each Binding Update sent by a mobile 870 node MUST use a Sequence Number greater than the Sequence 871 Number value sent in the previous Binding Update (if any) to 872 the same destination address (modulo 2**16). There is no 873 requirement, however, that the Sequence Number value strictly 874 increase by 1 with each new Binding Update sent or received. 876 Lifetime 878 32-bit unsigned integer. The number of seconds remaining 879 before the binding must be considered expired. A value of all 880 one bits (0xffffffff) indicates infinity. A value of zero 881 indicates that the Binding Cache entry for the mobile node 882 should be deleted. 884 Care-of Address 886 This field in the Binding Update is optional and is only 887 present when the Care-of Address Present (C) bit is set. If 888 present, it gives the care-of address of the mobile node for 889 this binding. For most Binding Updates sent, it is expected 890 that this field will not be present, and instead that the 891 care-of address for the binding will be given by the Source 892 Address field in the packet's IPv6 header. 894 Any packet including a Binding Update option MUST also include a Home 895 Address option. The home address of the mobile node in the binding 896 given in the Binding Update option is indicated by the Home Address 897 field in the Home Address option in the packet. 899 Any packet that includes a Binding Update option MUST also include 900 either an AH [7] or ESP [8] header providing sender authentication, 901 data integrity protection, and replay protection. 903 If the care-of address in the binding (either the Care-of Address 904 field in the Binding Update option or the Source Address field in 905 the packet's IPv6 header) is equal to the home address of the mobile 906 node, the Binding Update option indicates that any existing binding 907 for the mobile node should be deleted. Likewise, if the Lifetime 908 field in the Binding Update option is equal to 0, the Binding Update 909 option indicates that any existing binding for the mobile node should 910 be deleted. In each of these cases, no Binding Cache entry for the 911 mobile node should be created in response to receiving the Binding 912 Update. 914 The last Sequence Number value sent to a destination is stored by the 915 mobile node in the Binding Update List entry for that destination; 916 the last Sequence Number value received from a mobile node is stored 917 by a correspondent node in the Binding Cache entry for that mobile 918 node. Thus, the mobile node's and the correspondent node's knowledge 919 of the last sequence number expire at the same time. If the sending 920 mobile node has no Binding Update List entry, the Sequence Number 921 may start at any value; if the receiving correspondent node has no 922 Binding Cache entry, it should accept a Binding Update with any 923 Sequence Number value. 925 The three highest-order bits of the Option Type are encoded to 926 indicate specific processing of the option [5]. For the Binding 927 Update option, these three bits are set to 110, indicating that any 928 IPv6 node processing this option that does not recognize the Option 929 Type must discard the packet and, only if the packet's Destination 930 Address was not a multicast address, return an ICMP Parameter 931 Problem, Code 2, message to the packet's Source Address; and that the 932 data within the option cannot change en-route to the packet's final 933 destination. 935 Extensions to the Binding Update option format may be included after 936 the fixed portion of the Binding Update option specified above. 937 The presence of such extensions will be indicated by the Option 938 Length field. When the Option Length is greater than the length 939 defined above, the remaining octets are interpreted as extensions. 940 Currently, no extensions have been defined. 942 5.2. Binding Acknowledgement Option Format 944 The Binding Acknowledgement destination option is used to acknowledge 945 receipt of a Binding Update option (Section 5.1). When a node 946 receives a packet containing a Binding Update option, with this node 947 being the destination node of the packet (only the destination node 948 processes the option since it is a destination option), this node 949 MUST return a Binding Acknowledgement to the source of the packet, if 950 the Acknowledge (A) bit is set in the Binding Update. 952 The Binding Acknowledgement option is encoded in type-length-value 953 (TLV) format as follows: 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+ 958 | Option Type | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Option Length | Status | Sequence Number | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Lifetime | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Refresh | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | | 967 + + 968 . . 969 . Other Home Agents . 970 . . 971 + + 972 | | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Option Type 977 2 ??? 979 Option Length 981 8-bit unsigned integer. Length of the option, in octets, 982 excluding the Option Type and Option Length fields. This field 983 MUST be set to 11 + 16 * (the number of IP addresses included 984 in the Other Home Agents field). The number of addresses 985 included in the Other Home Agents field MUST be zero (Option 986 Length then MUST be set to 11), unless the Status field is set 987 to 135 (dynamic home agent address discovery response). 989 Status 991 8-bit unsigned integer indicating the disposition of the 992 Binding Update. Values of the Status field less than 128 993 indicate that the Binding Update was accepted by the receiving 994 node. The following such Status values are currently defined: 996 0 Binding Update accepted 998 Values of the Status field greater than or equal to 128 999 indicate that the Binding Update was rejected by the receiving 1000 node. The following such Status values are currently defined: 1002 128 Reason unspecified 1003 129 Poorly formed Binding Update 1004 130 Administratively prohibited 1005 131 Insufficient resources 1006 132 Home registration not supported 1007 133 Not home subnet 1008 134 Sequence Number field value too small 1009 135 Dynamic home agent address discovery response 1010 136 Incorrect interface identifier length 1012 Up-to-date values of the Status field are to be specified in 1013 the most recent "Assigned Numbers" [17]. 1015 Sequence Number 1017 The Sequence Number in the Binding Acknowledgement is copied 1018 from the Sequence Number field in the Binding Update option, 1019 for use by the mobile node in matching this Acknowledgement 1020 with an outstanding Binding Update. 1022 Lifetime 1024 The granted lifetime for which this node will attempt to retain 1025 the entry for this mobile node in its Binding Cache. If the 1026 node sending the Binding Acknowledgement is serving as the 1027 mobile node's home agent, the Lifetime period also indicates 1028 the period for which this node will continue this service; if 1029 the mobile node requires home agent service from this node 1030 beyond this period, the mobile node MUST send a new Binding 1031 Update to it before the expiration of this period, in order 1032 to extend the lifetime. The value of this field is undefined 1033 if the Status field indicates that the Binding Update was 1034 rejected. 1036 Refresh 1038 The recommended period at which the mobile node SHOULD send 1039 a new Binding Update to this node in order to "refresh" the 1040 mobile node's binding in this node's Binding Cache. This 1041 refreshing of the binding is useful in case the node fails and 1042 loses its cache state. The Refresh period is determined by 1043 the node sending the Binding Acknowledgement (the node caching 1044 the binding). If this node is serving as the mobile node's 1045 home agent, the Refresh value may be set, for example, based on 1046 whether the node stores the mobile node's binding in volatile 1047 storage or in nonvolatile storage. If the node sending the 1048 Binding Acknowledgement is not serving as the mobile node's 1049 home agent, the Refresh period SHOULD be set equal to the 1050 Lifetime period in the Binding Acknowledgement; even if this 1051 node loses this cache entry due to a failure of the node, 1052 packets from it can still reach the mobile node through the 1053 mobile node's home agent, causing a new Binding Update to this 1054 node to allow it to recreate this cache entry. The value of 1055 this field is undefined if the Status field indicates that the 1056 Binding Update was rejected. 1058 Other Home Agents 1060 A list of other home agents on the home link for the mobile 1061 node to which this Binding Acknowledgement is sent. This field 1062 MUST NOT be present (zero addresses listed) unless the Binding 1063 Acknowledgement is sent in response to an anycast Binding 1064 Update sent by this mobile node attempting dynamic home agent 1065 address discovery. In this case, the Status field MUST be 1066 set to 135 (dynamic home agent address discovery response). 1067 The list of home agents in the Other Home Agents field MUST 1068 NOT include this home agent's own unicast IP address, which 1069 is returned instead to the mobile node in the Source Address 1070 field in the IPv6 header of the packet in which this Binding 1071 Acknowledgement is sent. 1073 Any packet that includes a Binding Acknowledgement option MUST 1074 also include either an AH [7] or ESP [8] header providing sender 1075 authentication, data integrity protection, and replay protection. 1077 If the node returning the Binding Acknowledgement accepted the 1078 Binding Update for which the Acknowledgement is being returned (the 1079 value of the Status field in the Acknowledgement is less than 128), 1080 this node will have an entry for the mobile node in its Binding Cache 1081 and MUST use this entry (which includes the care-of address received 1082 in the Binding Update) in sending the packet containing the Binding 1083 Acknowledgement to the mobile node. The details of sending this 1084 packet to the mobile node are the same as for sending any packet to a 1085 mobile node using a binding, and are described in Section 8.9. The 1086 packet is sent using a Routing header, routing the packet to the 1087 mobile node by way of its care-of address recorded in the Binding 1088 Cache entry. 1090 If the node returning the Binding Acknowledgement instead 1091 rejected the Binding Update (the value of the Status field in the 1092 Acknowledgement is greater than or equal to 128), this node MUST 1093 similarly use a Routing header in sending the packet containing the 1094 Binding Acknowledgement, as described in Section 8.9, but MUST NOT 1095 use its Binding Cache in forming the IP header or Routing header 1096 in this packet. Rather, the care-of address used by this node in 1097 sending the packet containing the Binding Acknowledgement MUST be 1098 copied from the care-of address received in the rejected Binding 1099 Update; this node MUST NOT modify its Binding Cache in response 1100 to receiving this rejected Binding Update and MUST ignore its 1101 Binding Cache in sending the packet in which it returns this Binding 1102 Acknowledgement. The packet is sent using a Routing header, routing 1103 the packet to the home address of the rejected Binding Update by 1104 way of the care-of address indicated in the packet containing the 1105 Binding Update. When sending a Binding Acknowledgement to reject a 1106 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 1107 packet containing no payload (with the Next Header field in the last 1108 extension header in the packet set to indicate "No Next Header" [5]). 1110 The three highest-order bits of the Option Type are encoded to 1111 indicate specific processing of the option [5]. For the Binding 1112 Acknowledgement option, these three bits are set to 000, indicating 1113 that any IPv6 node processing this option that does not recognize the 1114 Option Type must skip over this option and continue processing the 1115 header, and that the data within the option cannot change en-route to 1116 the packet's final destination. 1118 5.3. Binding Request Option Format 1120 The Binding Request destination option is used to request a mobile 1121 node's binding from the mobile node. When a mobile node receives 1122 a packet containing a Binding Request option, it SHOULD return a 1123 Binding Update (Section 5.1) to the source of the Binding Request. 1125 The Binding Request option is encoded in type-length-value (TLV) 1126 format as follows: 1128 0 1 1129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Option Type | Option Length | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 Option Type 1136 3 ??? 1138 Option Length 1140 8-bit unsigned integer. Length of the option, in octets, 1141 excluding the Option Type and Option Length fields. For the 1142 current definition of the Binding Request option, this field 1143 MUST be set to 0. 1145 The three highest-order bits of the Option Type are encoded to 1146 indicate specific processing of the option [5]. For the Binding 1147 Request option, these three bits are set to 000, indicating that any 1148 IPv6 node processing this option that does not recognize the Option 1149 Type must skip over this option and continue processing the header, 1150 and that the data within the option cannot change en-route to the 1151 packet's final destination. 1153 Extensions to the Binding Request option format may be included after 1154 the fixed portion of the Binding Request option specified above. 1155 The presence of such extensions will be indicated by the Option 1156 Length field. When the Option Length is greater than 0 octets, 1157 the remaining octets are interpreted as extensions. Currently, no 1158 extensions have been defined. 1160 5.4. Home Address Option Format 1162 The Home Address destination option is used in a packet sent by a 1163 mobile node to inform the recipient of that packet of the mobile 1164 node's home address. For packets sent by a mobile node while 1165 away from home, the mobile node generally uses one of its care-of 1166 addresses as the Source Address in the packet's IPv6 header. By 1167 including a Home Address option in the packet, the correspondent 1168 node receiving the packet is able to substitute the mobile node's 1169 home address for this care-of address when processing the packet, 1170 thus making the use of the care-of address transparent to the 1171 correspondent node. 1173 The Home Address option is encoded in type-length-value (TLV) format 1174 as follows: 1176 0 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Option Type | Option Length | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | | 1182 + + 1183 | | 1184 + Home Address + 1185 | | 1186 + + 1187 | | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 Option Type 1192 196 ??? 1194 Option Length 1196 8-bit unsigned integer. Length of the option, in octets, 1197 excluding the Option Type and Option Length fields. For the 1198 current definition of the Home Address option, this field MUST 1199 be set to 16. 1201 Home Address 1203 The home address of the mobile node sending the packet. 1205 The inclusion of a Home Address option in a packet affects only 1206 the correspondent node's receipt of this single packet; no state 1207 is created or modified in the correspondent node as a result of 1208 receiving a Home Address option in a packet. In particular, the 1209 receipt of a packet containing a Home Address option MUST NOT alter 1210 the contents of the receiver's Binding Cache due to the presence of 1211 the Home Address option, and the mapping between the home address 1212 and care-of address indicated by the Home Address option MUST NOT be 1213 used as a basis for routing subsequent packets sent by this receiving 1214 node. 1216 No special authentication of the Home Address option is required, 1217 except that if the IPv6 header of a packet is covered by 1218 authentication, then that authentication MUST also cover the Home 1219 Address option; this coverage is achieved automatically by the 1220 definition of the Option Type code for the Home Address option, 1221 since it indicates that the option is included in the authentication 1222 computation. If the packet carries no IP authentication, then the 1223 contents of the Home Address option, as well as the Source Address 1224 field or any other field in the IPv6 header, may have been forged or 1225 altered during transit. Upon receipt of a packet containing a Home 1226 Address option, the receiving node replaces the Source Address in 1227 the IPv6 header with the Home Address in the Home Address option. 1228 By requiring that any authentication of the IPv6 header also cover 1229 the Home Address option, the security of the Source Address field in 1230 the IPv6 header is not compromised by the presence of a Home Address 1231 option. Security issues related to the Home Address option are 1232 discussed further in Section 13. 1234 The three highest-order bits of the Option Type are encoded to 1235 indicate specific processing of the option [5]. For the Home Address 1236 option, these three bits are set to 110, indicating that any IPv6 1237 node processing this option that does not recognize the Option Type 1238 must discard the packet and, only if the packet's Destination Address 1239 was not a multicast address, return an ICMP Parameter Problem, 1240 Code 2, message to the packet's Source Address; and that the data 1241 within the option cannot change en-route to the packet's final 1242 destination. 1244 Extensions to the Home Address option format may be included after 1245 the fixed portion of the Home Address option specified above. 1246 The presence of such extensions will be indicated by the Option 1247 Length field. When the Option Length is greater than 8 octets, 1248 the remaining octets are interpreted as extensions. Currently, no 1249 extensions have been defined. 1251 6. Modifications to IPv6 Neighbor Discovery 1253 6.1. Router Advertisement Message Format 1255 Mobile IPv6 requires the addition of a single flag bit to the format 1256 of a Router Advertisement message [11], for use in the dynamic home 1257 agent address discovery mechanism (Sections 9.2 and 10.4). The 1258 Router Advertisement message format is thus modified as follows: 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Type | Code | Checksum | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Reachable Time | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Retrans Timer | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Options ... 1272 +-+-+-+-+-+-+-+-+-+-+-+- 1274 This format represents the following changes over that specified for 1275 Neighbor Discovery [11]: 1277 Home Agent (H) 1279 The Home Agent (H) bit is set in a Router Advertisement to 1280 indicate that the router sending this Router Advertisement is 1281 also functioning as a Mobile IP home agent. 1283 Reserved 1285 Reduced from a 6-bit field to a 5-bit field to account for the 1286 addition of the Home Agent (H) bit. 1288 6.2. Advertisement Interval Option Format 1290 The Advertisement Interval option is used in Router Advertisement 1291 messages to advertise the interval at which this router sends 1292 unsolicited multicast Router Advertisements. Routers operating 1293 as Mobile IP home agents MAY include this option in their Router 1294 Advertisements. A mobile node receiving a Router Advertisement 1295 containing this option SHOULD utilize the specified Advertisement 1296 Interval for that home agent in its movement detection algorithm, as 1297 described in Section 10.2. 1299 This option MUST be silently ignored for other Neighbor Discovery 1300 messages. 1302 0 1 2 3 1303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Type | Length | Reserved | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Advertisement Interval | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 Type 1312 6 ??? 1314 Length 1316 1 1318 Reserved 1320 This field is unused. It MUST be initialized to zero by the 1321 sender and MUST be ignored by the receiver. 1323 Advertisement Interval 1325 32-bit unsigned integer. The maximum time, in milliseconds, 1326 between successive unsolicited router Router Advertisement 1327 messages sent by this router on this network interface. Using 1328 the conceptual router configuration variables defined by 1329 Neighbor Discovery [11], this field MUST be equal to the value 1330 MaxRtrAdvInterval, expressed in milliseconds. 1332 6.3. Changes to MinRtrAdvInterval Limits 1334 The Neighbor Discovery protocol specification [11] limits routers to 1335 a minimum interval of 3 seconds between sending unsolicited multicast 1336 Router Advertisement messages from any given network interface 1337 (MinRtrAdvInterval), stating that: 1339 "Routers generate Router Advertisements frequently enough 1340 that hosts will learn of their presence within a few 1341 minutes, but not frequently enough to rely on an absence 1342 of advertisements to detect router failure; a separate 1343 Neighbor Unreachability Detection algorithm provides failure 1344 detection." 1346 This limitation, however, is not suitable to providing timely 1347 movement detection for mobile nodes. Mobile nodes detect their 1348 own movement by learning the presence of new routers as the mobile 1349 node moves into wireless transmission range of them (or physically 1350 connects to a new wired network), and by learning that previous 1351 routers are no longer reachable. Mobile nodes MUST be able to 1352 quickly detect when they move to a link served by a new router, so 1353 that they can acquire a new care-of address and send Binding Updates 1354 to register this care-of address with their home agent and to notify 1355 correspondent nodes as needed. 1357 Thus, routers serving as Mobile IP home agents MAY send unsolicited 1358 multicast Router Advertisements more frequently than this limit. In 1359 particular, on network interfaces where the home agent is expecting 1360 to provide service to visiting mobile nodes (e.g., wireless network 1361 interfaces), the home agent SHOULD be configured with a smaller 1362 MinRtrAdvInterval value to allow sending of unsolicited multicast 1363 Router Advertisements more often. A recommended maximum rate is 1364 once per second, although specific knowledge of the type of network 1365 interface in use SHOULD be taken into account in configuring this 1366 limit for each network interface. 1368 7. Requirements for IPv6 Nodes 1370 Mobile IPv6 places some special requirements on the functions 1371 provided by different IPv6 nodes. This section summarizes those 1372 requirements, identifying the functionality each requirement is 1373 intended to support. Further details on this functionality is 1374 provided in the following sections. 1376 7.1. Requirements for All IPv6 Hosts and Routers 1378 Since any IPv6 node may at any time be a correspondent node of a 1379 mobile node, either sending a packet to a mobile node or receiving a 1380 packet from a mobile node, the following requirements pertain to ALL 1381 IPv6 nodes (whether host or router, whether mobile or stationary): 1383 - Every IPv6 node MUST be able to process a Home Address option 1384 received in a packet. 1386 - Every IPv6 node SHOULD be able to process a Binding Update option 1387 received in a packet, and to return a Binding Acknowledgement 1388 option if requested. 1390 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 1391 bindings received in accepted Binding Updates. 1393 7.2. Requirements for IPv6 Home Agents 1395 In order for a mobile node to operate correctly while away from 1396 home, at least one IPv6 router in the mobile node's home link must 1397 function as a home agent for the mobile node. The following special 1398 requirements pertain to all IPv6 routers capable of serving as a home 1399 agent: 1401 - Every home agent MUST be able to maintain an entry in its Binding 1402 Cache for each mobile node for which it is serving as the home 1403 agent. Each such Binding Cache entry records the mobile node's 1404 binding with its primary care-of address and is marked as a "home 1405 registration". 1407 - Every home agent MUST be able to intercept packets (using proxy 1408 Neighbor Discovery) on the local subnet addressed to a mobile 1409 node for which it is currently serving as the home agent while 1410 that mobile node is away from home. 1412 - Every home agent MUST be able to encapsulate such intercepted 1413 packets in order to tunnel them to the primary care-of address 1414 for the mobile node indicated in its binding. 1416 - Every home agent MUST be able to return a Binding Acknowledgement 1417 in response to a Binding Update received with the Acknowledge (A) 1418 bit set. 1420 - Every home agent MUST be able to accept packets addressed to the 1421 Home-Agents anycast address for the subnet on which it is serving 1422 as a home agent, and MUST be able to participate in dynamic home 1423 agent address discovery (Section 9.2). 1425 7.3. Requirements for IPv6 Mobile Nodes 1427 Finally, the following requirements pertain all IPv6 nodes capable of 1428 functioning as mobile nodes: 1430 - Every IPv6 mobile node MUST be able to perform IPv6 1431 decapsulation [4]. 1433 - Every IPv6 mobile node MUST support sending Binding Updates, as 1434 specified in Sections 10.4, 10.5, and 10.6; and MUST be able to 1435 receive and process Binding Acknowledgements, as specified in 1436 Section 10.10. 1438 - Every IPv6 mobile node MUST maintain a Binding Update List in 1439 which it records the IP address of each other node to which it 1440 has sent a Binding Update, for which the Lifetime sent in that 1441 binding has not yet expired. 1443 - Every IPv6 mobile node MUST support receiving a Binding Request 1444 by responding with a Binding Update. 1446 - Every IPv6 mobile node MUST support sending packets containing a 1447 Home Address option; this option MUST be included in all packets 1448 sent while away from home, if the packet would otherwise have 1449 been sent with the mobile node's home address as the IP Source 1450 Address. 1452 8. Correspondent Node Operation 1454 A correspondent node is any node communicating with a mobile node. 1455 The correspondent node, itself, may be stationary or mobile, and may 1456 possibly also be functioning as a home agent for Mobile IPv6. The 1457 procedures in this section thus apply to all IPv6 nodes. 1459 8.1. Receiving Packets from a Mobile Node 1461 Packets sent by a mobile node while away from home generally include 1462 a Home Address option. When any node receives a packet containing 1463 a Home Address option, it MUST process the option in a manner 1464 consistent with copying the Home Address field from the Home Address 1465 option into the IPv6 header, replacing the original value of the 1466 Source Address field there. Further processing of the packet (e.g., 1467 at the transport layer) thus need not know that the original Source 1468 Address was a care-of address, or that the Home Address option was 1469 used in the packet. Since the sending mobile node uses its home 1470 address at the transport layer when sending such a packet, the use of 1471 the care-of address and Home Address option is thus transparent to 1472 both the mobile node and the correspondent node above the level of 1473 the Home Address option generation and processing. 1475 8.2. Receiving Binding Updates 1477 Upon receiving a Binding Update option in some packet, the receiving 1478 node MUST validate the Binding Update according to the following 1479 tests: 1481 - The packet MUST contain a valid Home Address option. The home 1482 address for the binding is specified by the Home Address field of 1483 the Home Address option. 1485 - The Option Length field in the Binding Update option is greater 1486 than or equal to the length specified in Section 5.1. 1488 - The packet contains a valid AH [7] or ESP [8] header that 1489 provides sender authentication, integrity protection, and replay 1490 protection. 1492 - The Sequence Number field in the Binding Update option is greater 1493 than the Sequence Number received in the previous Binding Update 1494 for this home address, if any. The Sequence Number comparison is 1495 performed modulo 2**16. 1497 Any Binding Update not satisfying all of these tests MUST be 1498 silently ignored, and the packet carrying the Binding Update MUST be 1499 discarded. 1501 If the Binding Update is valid according to the tests above, then the 1502 Binding Update is processed further as follows: 1504 - If the Destination Address in the packet's IPv6 header is the 1505 Home-Agents anycast address for a local subnet and this address 1506 is assigned to one of this node's network interfaces, then the 1507 mobile node sending this Binding Update is attempting dynamic 1508 home agent address discovery. Processing for this type of 1509 received Binding Update is described in Section 9.2. (If the 1510 Destination Address is not assigned to one of this node's network 1511 interfaces, then the packet would have been forwarded as a normal 1512 packet and the Binding Update, as a destination option, would not 1513 be processed in any way by this node.) 1515 - If the Lifetime specified in the Binding Update is nonzero and 1516 the specified Care-of Address is not equal to the home address 1517 for the binding (as given in the Home Address option in the 1518 packet), then this is a request to cache a binding for the mobile 1519 node. Processing for this type of received Binding Update is 1520 described in Section 8.3. 1522 - If the Lifetime specified in the Binding Update is zero or the 1523 specified Care-of Address matches the home address for the 1524 binding, then this is a request to delete the mobile node's 1525 cached binding. Processing for this type of received Binding 1526 Update is described in Section 8.4. 1528 8.3. Requests to Cache a Binding 1530 If a node receives a valid Binding Update requesting it to cache a 1531 binding for a mobile node, as specified in Section 8.2, then the node 1532 MUST examine the Home Registration (H) bit in the Binding Update 1533 to determine how to further process the Binding Update. If the 1534 Home Registration (H) bit is set, the Binding Update is processed 1535 according to the procedure specified in Section 9.3. 1537 If the Home Registration (H) bit is not set, then the receiving 1538 node SHOULD create a new entry in its Binding Cache for this mobile 1539 node (or update its existing Binding Cache entry for this mobile 1540 node, if such an entry already exists). The home address of the 1541 mobile node is taken from the Home Address field in the packet's Home 1542 Address option. The new Binding Cache entry records the association 1543 between this home address and the care-of address for the binding, as 1544 specified in either the Care-of Address field of the Binding Update 1545 or in the Source Address field in the packet's IPv6 header. Any 1546 Binding Cache entry created or updated in response to processing this 1547 Binding Update MUST be deleted after the expiration of the Lifetime 1548 period specified in the Binding Update. 1550 8.4. Requests to Delete a Binding 1552 If a node receives a valid Binding Update requesting it to delete a 1553 cached binding for a mobile node, as specified in Section 8.2, then 1554 the node MUST examine the Home Registration (H) bit in the Binding 1555 Update to determine how to further process the Binding Update. If 1556 the Home Registration (H) bit is set, the Binding Update is processed 1557 according to the procedure specified in Section 9.4. 1559 If the Home Registration (H) bit is not set, then the receiving node 1560 MUST delete any existing entry in its Binding Cache for this mobile 1561 node. The home address of the mobile node is taken from the Home 1562 Address field in the packet's Home Address option. 1564 8.5. Sending Binding Acknowledgements 1566 When any node receives a packet containing a Binding Update option 1567 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 1568 Acknowledgement option acknowledging receipt of the Binding Update. 1569 If the node accepts the Binding Update and creates or updates an 1570 entry in its Binding Cache for this binding, the Status field in 1571 the Binding Acknowledgement MUST be set to a value less than 128; 1572 if the node rejects the Binding Update and does not create or 1573 update an entry for this binding, the Status field in the Binding 1574 Acknowledgement MUST be set to a value greater than or equal to 128. 1575 Specific values for the Status field are described in Section 5.2 and 1576 in the most recent "Assigned Numbers" [17]. 1578 As described in Section 5.2, the packet in which the Binding 1579 Acknowledgement is returned MUST include either an AH [7] or ESP [8] 1580 header providing sender authentication, data integrity protection, 1581 and replay protection; and the packet MUST be sent using a Routing 1582 header in the same way as any other packet sent to a mobile node 1583 using a care-of address (even if the binding was rejected), as 1584 described in Section 8.9. The packet is routed first to the care-of 1585 address contained in the Binding Update being acknowledged, and 1586 then to the mobile node's home address. This use of the Routing 1587 header ensures that the Binding Acknowledgement will be routed to the 1588 current location of the node sending the Binding Update, whether the 1589 Binding Update was accepted or rejected. 1591 8.6. Sending Binding Requests 1593 Entries in a node's Binding Cache MUST be deleted when their lifetime 1594 expires. If such an entry is still in active use in sending packets 1595 to a mobile node, the next packet sent to the mobile node will be 1596 routed normally, to the mobile node's home link, where it will be 1597 intercepted and tunneled to the mobile node. The mobile node will 1598 then return a Binding Update to the sender, allowing it to create 1599 a new Binding Cache entry for sending future packets to the mobile 1600 node. Communication with the mobile node continues uninterrupted, 1601 but the forwarding of this packet through the mobile node's home 1602 agent creates additional overhead and latency in delivering packets 1603 to the mobile node. 1605 If the sender knows that the Binding Cache entry is still in active 1606 use, it MAY send a Binding Request to the mobile node in an attempt 1607 to avoid this overhead and latency due to deleting and recreating 1608 the Binding Cache entry. Since a Binding Request is a destination 1609 option, it may, for example, be included in any packet already being 1610 sent to the mobile node, such as a packet that is part of ongoing TCP 1611 communication with the mobile node. When the mobile node receives a 1612 packet from some sender containing a Binding Request, it returns a 1613 Binding Update to that sender, giving its current binding and a new 1614 lifetime. 1616 8.7. Cache Replacement Policy 1618 Any entry in a node's Binding Cache MUST be deleted after the 1619 expiration of the Lifetime specified in the Binding Update from which 1620 the entry was created or was last updated. Conceptually, a node 1621 maintains a separate timer for each entry in its Binding Cache. When 1622 creating or updating a Binding Cache entry in response to a received 1623 and accepted Binding Update, the node sets the timer for this entry 1624 to the specified Lifetime period. When a Binding Cache entry's timer 1625 expires, the node deletes the entry. 1627 Each node's Binding Cache will, by necessity, have a finite size. 1628 A node MAY use any reasonable local policy for managing the space 1629 within its Binding Cache, except that any entry marked as a "home 1630 registration" (Section 9.3) MUST NOT be deleted from the cache until 1631 the expiration of its lifetime period. When attempting to add a 1632 new "home registration" entry in response to a Binding Update with 1633 the Home Registration (H) bit set, if insufficient space exists (or 1634 can be reclaimed) in the node's Binding Cache, the node MUST reject 1635 the Binding Update and SHOULD return a Binding Acknowledgement to 1636 the sending mobile node, in which the Status field is set to 131 1637 (insufficient resources). When otherwise attempting to add a new 1638 entry to its Binding Cache, a node MAY, if needed, choose to drop any 1639 entry already in its Binding Cache, other than a "home registration" 1640 entry, in order to make space for the new entry. For example, a 1641 "least-recently used" (LRU) strategy for cache entry replacement 1642 among entries not marked as a "home registration" is likely to work 1643 well. 1645 Any binding dropped from a node's Binding Cache due to lack of cache 1646 space will be rediscovered and a new cache entry created, if the 1647 binding is still in active use by the node for sending packets. If 1648 the node sends a packet to a destination for which it has dropped the 1649 entry from its Binding Cache, the packet will be routed normally, 1650 leading to the mobile node's home link. There, the packet will be 1651 intercepted by the mobile node's home agent and tunneled to the 1652 mobile node's current primary care-of address. As when a Binding 1653 Cache entry is initially created, this indirect routing to the mobile 1654 node through its home agent will result in the mobile node sending 1655 a Binding Update to this sending node when it receives the tunneled 1656 packet, allowing it to add an entry again for this destination to its 1657 Binding Cache. 1659 8.8. Receiving ICMP Error Messages 1661 When a correspondent node sends a packet to a mobile node, if the 1662 correspondent node has a Binding Cache entry for the destination 1663 address of the packet, then the correspondent node uses a Routing 1664 header to deliver the packet to the mobile node through the care-of 1665 address in the binding recorded in the Binding Cache entry. Any ICMP 1666 error message caused by the packet on its way to the mobile node will 1667 be returned normally to the correspondent node. 1669 On the other hand, if the correspondent node has no Binding Cache 1670 entry for the mobile node, the packet will be routed to the mobile 1671 node's home link, where it will be intercepted by the mobile node's 1672 home agent, encapsulated, and tunneled to the mobile node's primary 1673 care-of address. Any ICMP error message caused by the packet on 1674 its way to the mobile node while in the tunnel, will be returned to 1675 the mobile node's home agent (the source of the tunnel). By the 1676 definition of IPv6 encapsulation [4], this encapsulating node MUST 1677 relay certain ICMP error messages back to the original sender of the 1678 packet, which in this case is the correspondent node. 1680 Likewise, if a packet for a mobile node arrives at the mobile node's 1681 previous default router (e.g., the mobile node moved after the packet 1682 was sent), the router will encapsulate and tunnel the packet to the 1683 mobile node's new care-of address (if it has a Binding Cache entry 1684 for the mobile node). As above, any ICMP error message caused by the 1685 packet while in this tunnel will be returned to the previous default 1686 router (the source of the tunnel), which MUST relay certain ICMP 1687 error messages back to the correspondent node [4]. 1689 Thus, in all cases, any meaningful ICMP error messages caused 1690 by packets from a correspondent node to a mobile node will be 1691 returned to the correspondent node. If the correspondent node 1692 receives persistent ICMP Destination Unreachable messages after 1693 sending packets to a mobile node based on an entry in its Binding 1694 Cache, the correspondent node SHOULD delete this Binding Cache 1695 entry. If the correspondent node subsequently transmits another 1696 packet to the mobile node, the packet will be routed to the mobile 1697 node's home link, intercepted by the mobile node's home agent, and 1698 tunneled to the mobile node's primary care-of address using IPv6 1699 encapsulation. The mobile node will then return a Binding Update to 1700 the correspondent node, allowing it to recreate a (correct) Binding 1701 Cache entry for the mobile node. 1703 8.9. Sending Packets to a Mobile Node 1705 Before sending any packet, the sending node SHOULD examine its 1706 Binding Cache for an entry for the destination address to which the 1707 packet is being sent. If the sending node has a Binding Cache entry 1708 for this address, the sending node SHOULD use a Routing header to 1709 route the packet to this mobile node (the destination node) by way 1710 of the care-of address in the binding recorded in that Binding Cache 1711 entry. For example, assuming use of a Type 0 Routing header [5], if 1712 no other use of a Routing header is involved in the routing of this 1713 packet, the mobile node sets the fields in the packet's IPv6 header 1714 and Routing header as follows: 1716 - The Destination Address in the packet's IPv6 header is set to 1717 the mobile node's care-of address copied from the Binding Cache 1718 entry. 1720 - The Routing header is initialized to contain a single route 1721 segment, with an Address of the mobile node's home address (the 1722 original destination address to which the packet was being sent). 1724 Following the definition of a Type 0 Routing header [5], this packet 1725 will be routed to the mobile node's care-of address, where it will 1726 be delivered to the mobile node (the mobile node has associated the 1727 care-of address with its network interface). Normal processing of 1728 the Routing header by the mobile node will then proceed as follows: 1730 - The mobile node swaps the Destination Address in the packet's 1731 IPv6 header and the Address specified in the Routing header. 1732 This results in the packet's IP Destination Address being set to 1733 the mobile node's home address. 1735 - The mobile node then resubmits the packet to its IPv6 module for 1736 further processing. Since the mobile node recognizes its own 1737 home address as one if its current IP addresses, the packet is 1738 processed further within the mobile node, in the same way then as 1739 if the mobile node was at home. 1741 If, instead, the sending node has no Binding Cache entry for the 1742 destination address to which the packet is being sent, the sending 1743 node simply sends the packet normally, with no Routing header. If 1744 the destination node is not a mobile node (or is a mobile node that 1745 is currently at home), the packet will be delivered directly to this 1746 node and processed normally by it. If, however, the destination node 1747 is a mobile node that is currently away from home, the packet will 1748 be intercepted by the mobile node's home agent and tunneled (using 1749 IPv6 encapsulation [4]) to the mobile node's current primary care-of 1750 address, as described in Section 9.5. The mobile node will then send 1751 a Binding Update to the sending node, as described in Section 10.5, 1752 allowing the sending node to create a Binding Cache entry for its use 1753 in sending subsequent packets to this mobile node. 1755 9. Home Agent Operation 1757 9.1. Receiving Router Advertisement Messages 1759 For each link on which a router provides service as a home agent, 1760 the router maintains a Home Agents List recording the IP address of 1761 all other home agents that link. This list is used in the dynamic 1762 home agent address discovery mechanism, described in Section 9.2. 1763 The information for the list is learned through receipt of periodic 1764 unsolicited multicast Router Advertisements from each other home 1765 agent on the link, in which the Home Agent (H) bit is set, in a 1766 manner similar to the Default Router List conceptual data structure 1767 maintained by each host for Neighbor Discovery [11]. 1769 On receipt of a valid Router Advertisement, as defined in the 1770 processing algorithm specified for Neighbor Discovery [11], the home 1771 agent extracts the Source Address of the packet and performs the 1772 following steps, in addition to any steps already required of it by 1773 Neighbor Discovery: 1775 - If the address is not already present in the home agent's Home 1776 Agents List, and the advertisement's Router Lifetime is non-zero, 1777 create a new entry in the list, and initialize its lifetime from 1778 the advertisement's Router Lifetime field. 1780 - If the address is already present in the home agent's Home Agents 1781 List as a result of a previously-received advertisement, reset 1782 its lifetime to the Router Lifetime value in the newly-received 1783 advertisement. 1785 - If the address is already present in the home agent's Home Agents 1786 List and the received Router Lifetime value is zero, immediately 1787 delete this entry in the Home Agents List 1789 A home agent SHOULD maintain an entry in its Home Agents List for 1790 each such valid home agent address until that entry's lifetime 1791 expires, after which time the entry MUST be deleted. 1793 9.2. Dynamic Home Agent Address Discovery 1795 If a received Binding Update indicates that the mobile node sending 1796 it is attempting dynamic home agent address discovery, as described 1797 in Section 8.2, then the receiving node MUST process the Binding 1798 Update as specified in this section. 1800 A mobile node attempts dynamic home agent address discovery by 1801 sending its "home registration" Binding Update to the Home-Agents 1802 anycast address for its home IP subnet prefix (the packet MUST also 1803 include a Home Address option, as described in Section 10.4). A home 1804 agent receiving such a Binding Update that is serving this subnet 1805 (the home agent is configured with this anycast address on one of its 1806 network interfaces) MUST reject the Binding Update and SHOULD return 1807 a Binding Acknowledgement indicating this rejection, with the Source 1808 Address of the packet carrying the Binding Acknowledgement set to 1809 one of the unicast addresses of the home agent. The Status field in 1810 the Binding Acknowledgement MUST be set to 135 (dynamic home agent 1811 address discovery response). 1813 In this Binding Acknowledgement rejecting the dynamic home agent 1814 address discovery Binding Update, this home agent SHOULD include the 1815 IP address of all other home agents currently listed in its Home 1816 Agents List. To include this list in the Binding Acknowledgement, 1817 the Option Length field MUST be set to 11 + 16 * (the number 1818 of IP addresses included in the Other Home Agents field in the 1819 Binding Acknowledgement). The mobile node, upon receiving this 1820 Binding Acknowledgement, MAY then resend its Binding Update to 1821 the unicast home agent address given as the IP Source Address of 1822 the packet carrying the Binding Acknowledgement or to any of the 1823 unicast IP addresses listed in the Other Home Agents field in 1824 the Acknowledgement. For example, the mobile node may re-attempt 1825 its home registration with each of these home agents in turn, by 1826 sending each a Binding Update and waiting for the matching Binding 1827 Acknowledgement, until its registration is accepted by one of these 1828 home agents. 1830 9.3. Primary Care-of Address Registration 1832 General processing of a received Binding Update that requests a 1833 binding to be cached, is described in Section 8.3. However, if 1834 the Home Registration (H) bit is set in the Binding Update, then 1835 after following the step outlined for all Binding Update options in 1836 Section 8.2, the receiving node MUST process the Binding Update as 1837 specified in this section rather than following the general procedure 1838 for requests to cache a binding specified in Section 8.3. 1840 To begin processing the Binding Update, the home agent MUST perform 1841 the following sequence of tests: 1843 - If the node is not a router that implements home agent 1844 functionality, then the node MUST reject the Binding Update and 1845 SHOULD return a Binding Acknowledgement to the mobile node, in 1846 which the Status field is set to 132 (home registration not 1847 supported). 1849 - Else, if the home address for the binding (the Home Address field 1850 in the packet's Home Address option) is not an on-link IPv6 1851 address with respect to the home agent's current Prefix List, 1852 then the home agent MUST reject the Binding Update and SHOULD 1853 return a Binding Acknowledgement to the mobile node, in which the 1854 Status field is set to 133 (not home subnet). 1856 - Else, if the Prefix Length field is nonzero in the Binding Update 1857 and this length differs from the length of the home agent's own 1858 knowledge of the corresponding subnet prefix on the home link, 1859 then the home agent MUST reject the Binding Update and SHOULD 1860 return a Binding Acknowledgement to the mobile node, in which the 1861 Status field is set to 136 (incorrect subnet prefix length). 1863 - Else, if the home agent chooses to reject the Binding Update for 1864 any other reason (e.g., insufficient resources to serve another 1865 mobile node as a home agent), then the home agent SHOULD return a 1866 Binding Acknowledgement to the mobile node, in which the Status 1867 field is set to an appropriate value to indicate the reason for 1868 the rejection. 1870 If the home agent does not reject the Binding Update as described 1871 above, then it becomes the home agent for the mobile node. The new 1872 home agent (the receiving node) MUST then create a new entry or 1873 update the existing entry in its Binding Cache for this mobile node's 1874 home address (given in the Home Address option in the packet), as 1875 described in Section 8.3. In addition, the home agent MUST mark 1876 this Binding Cache entry as a "home registration" to indicate that 1877 the node is serving as a home agent for this binding. Binding 1878 Cache entries marked as a "home registration" MUST be excluded from 1879 the normal cache replacement policy used for the Binding Cache 1880 (Section 8.7) and MUST NOT be removed from the Binding Cache until 1881 the expiration of the Lifetime period. 1883 If the home agent was not already serving as a home agent for this 1884 mobile node (the home agent did not already have a Binding Cache 1885 entry for this home address marked as a "home registration"), then 1886 the home agent MUST multicast onto the home link a "gratuitous" 1887 Neighbor Advertisement message [11] on behalf of the mobile node, in 1888 order to begin intercepting packets addressed to it while it is away 1889 from home. Specifically, the home agent follows the following steps: 1891 - The home agent examines the value of the Prefix Length field in 1892 the Binding Update. If this value is zero, the following step 1893 is carried out only for the individual home address specified 1894 (in the Home Address option in the packet) for this binding. 1895 If, instead, this field is nonzero, then the following step is 1896 carried out for each address for the mobile node formed from 1897 the interface identifier in the mobile node's home address in 1898 this Binding Update (the remaining low-order bits in the address 1899 after the indicated subnet prefix), together with each one of 1900 the subnet prefixes currently considered by the home agent to be 1901 on-link (including both the link-local and site-local prefix). 1903 - For each specific IP address for the mobile node determined in 1904 the first step above, the home agent multicast onto the home link 1905 (to the all-nodes multicast address) a Neighbor Advertisement 1906 message [11] on behalf of the mobile node, to advertise the 1907 home agent's own link-layer address for this IP address. The 1908 Target Address in the Neighbor Advertisement message MUST be set 1909 to this IP address for the mobile node, and the Advertisement 1910 MUST include a Target Link-layer Address option specifying the 1911 home agent's link-layer address. The Solicited Flag (S) in the 1912 Advertisement MUST NOT be set, since it was not solicited by any 1913 Neighbor Solicitation message. The Override Flag (O) in the 1914 Advertisement MUST be set, indicating that the Advertisement 1915 SHOULD override any existing Neighbor Cache entry at any node 1916 receiving it. 1918 Any node on the home link receiving one of the Neighbor Advertisement 1919 messages described above will thus update its Neighbor Cache to 1920 associate the mobile node's address with the home agent's link 1921 layer address, causing it to transmit any future packets for the 1922 mobile node normally destined to this address instead to the mobile 1923 node's home agent. Since multicasts on the local link (such as 1924 Ethernet) are typically not guaranteed to be reliable, the home 1925 agent MAY retransmit this Neighbor Advertisement message up to 1926 MAX_ADVERT_REXMIT times to increase its reliability. It is still 1927 possible that some nodes on the home link will not receive any of 1928 these Neighbor Advertisements, but these nodes will eventually be 1929 able to detect the link-layer address change for the mobile node's 1930 home address, through use of Neighbor Unreachability Detection [11]. 1932 In addition, while this node is serving as a home agent for this 1933 mobile node (it still has a "home registration" entry for this mobile 1934 node in its Binding Cache), it MUST act as a proxy for this mobile 1935 node to reply to any received Neighbor Solicitation messages for 1936 it. When a home agent receives a Neighbor Solicitation message, it 1937 MUST check if the Target Address specified in the message matches 1938 the home address of any mobile node for which it has a Binding 1939 Cache entry marked as a "home registration". This check MUST 1940 include all possible home addresses for the mobile node, based on 1941 the subnet prefixes currently considered to be on-link by the home 1942 agent (including the corresponding link-local address and site-local 1943 address), if the Prefix Length field was nonzero in the Binding 1944 Update that created this "home registration" binding at the home 1945 agent. If such an entry exists in the home agent's Binding Cache, 1946 the home agent MUST reply to the Neighbor Solicitation message 1947 with a Neighbor Advertisement message, giving the home agent's own 1948 link-layer address as the link-layer address for the specified 1949 Target Address. Acting as a proxy in this way allows other nodes on 1950 the mobile node's home link to resolve the mobile node's IPv6 home 1951 address, and allows the home agent to to defend these addresses on 1952 the home link for Duplicate Address Detection [11]. 1954 Any packet addressed to the mobile node's home address (including 1955 addresses formed from other on-link prefixes, if the Prefix Length 1956 field was nonzero in the Binding Update) will thus be received by the 1957 mobile node's home agent while the mobile node is registered away 1958 from home. For any such packet received by the home agent for the 1959 mobile node, the home agent SHOULD tunnel the packet to the mobile 1960 node at its primary care-of address, as described in Section 9.5. 1962 However, packets addressed to the mobile node's link-local address 1963 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 1964 be discarded, and the home agent SHOULD return an ICMP Destination 1965 Unreachable, Code 3, message to the packet's Source Address (unless 1966 this Source Address is a multicast address). 1968 Similarly, packets addressed to the mobile node's site-local address 1969 MUST NOT be tunneled to the mobile node, unless the mobile node's 1970 registered primary care-of address is within the same site as the 1971 mobile node's home address. For any such packet not forwarded to the 1972 mobile node for this reason, the packet MUST be discarded, and the 1973 home agent SHOULD return an ICMP Destination Unreachable, Code 3, 1974 message to the packet's Source Address (unless this Source Address is 1975 a multicast address). Currently, however, the exact definition and 1976 semantics of a "site" are undefined in IPv6, and the mechanism for 1977 a home agent to determine if the care-of address is within the same 1978 site as the home address is outside the scope of this document. 1980 9.4. Primary Care-of Address De-registration 1982 General processing of a received Binding Update that requests a 1983 binding to be deleted, is described in Section 8.4. However, if 1984 the Home Registration (H) bit is set in the Binding Update, then 1985 after following the step outlined for all Binding Update options in 1986 Section 8.2, the receiving node MUST process the Binding Update as 1987 specified in this section rather than following the general procedure 1988 for requests to delete a cache binding specified in Section 8.4. 1990 To begin processing the Binding Update, the home agent MUST perform 1991 the following sequence of tests: 1993 - If the node is not a router that implements home agent 1994 functionality, then the node MUST reject the Binding Update and 1995 SHOULD return a Binding Acknowledgement to the mobile node, in 1996 which the Status field is set to 132 (home registration not 1997 supported). 1999 - Else, if the home address for the binding (the Home Address 2000 field in the packet's Home Address option) is not an on-link 2001 IPv6 address with respect to the home agent's current Prefix 2002 List, then it MUST reject the Binding Update and SHOULD return a 2003 Binding Acknowledgement to the mobile node, in which the Status 2004 field is set to 133 (not home subnet). 2006 If the home agent does not reject the Binding Update as described 2007 above, then it MUST delete any existing entry in its Binding Cache 2008 for this mobile node. 2010 9.5. Tunneling Intercepted Packets to a Mobile Node 2012 For any packet sent to a mobile node from the mobile node's home 2013 agent (for which the home agent is the original sender of the 2014 packet), the home agent is operating as a correspondent node of 2015 the mobile node for this packet and the procedures described in 2016 Section 8.9 apply. The home agent (as a correspondent node) uses a 2017 Routing header to route the packet to the mobile node by way of the 2018 care-of address in the home agent's Binding Cache (the mobile node's 2019 primary care-of address, in this case). 2021 In addition, while the mobile node is away from home and this node is 2022 acting as the mobile node's home agent, the home agent intercepts any 2023 packets on the home link addressed to the mobile node's home address, 2024 as described in Section 9.3. The home agent cannot use a Routing 2025 header to forward these intercepted packets to the mobile node, 2026 since it cannot modify the packet in flight without invalidating any 2027 existing IPv6 Authentication header present in the packet [7]. 2029 For forwarding each intercepted packet to the mobile node, the 2030 home agent MUST tunnel the packet to the mobile node using IPv6 2031 encapsulation [4]; the tunnel entry point node is the home agent, 2032 and the tunnel exit point node is the mobile node itself (using its 2033 primary care-of address as registered with the home agent). When a 2034 home agent encapsulates an intercepted packet for forwarding to the 2035 mobile node, the home agent sets the Source Address in the prepended 2036 tunnel IP header to the home agent's own IP address, and sets the 2037 Destination Address in the tunnel IP header to the mobile node's 2038 primary care-of address. When received by the mobile node (using its 2039 primary care-of address), normal processing of the tunnel header [4] 2040 will result in decapsulation and processing of the original packet by 2041 the mobile node. 2043 9.6. Renumbering the Home Subnet 2045 Neighbor Discovery [11] specifies a mechanism by which all nodes on a 2046 subnet can gracefully autoconfigure new addresses, say by each node 2047 combining a new subnet prefix with its existing link-layer address. 2048 As currently specified, this mechanism works when the nodes are on 2049 the same link as the router issuing the necessary multicast packets 2050 to advertise the new subnet prefix(es) appropriate for the link. 2052 However, for mobile nodes away from home, special care must be taken 2053 to allow the mobile nodes to renumber gracefully. The most direct 2054 method of ensuring this is for the home agent to encapsulate and 2055 tunnel the multicast packets to the primary care-of address of each 2056 mobile node for which it is serving as the home agent. The rules for 2057 this are as follows: 2059 - A mobile node assumes that its subnet prefix has not changed 2060 unless it receives an authenticated Router Advertisement message 2061 from its home agent that the prefix has changed. 2063 - When the mobile node is at home, the home agent does not tunnel 2064 Router Advertisements to it. 2066 - The mobile node's home agent serves as a proxy for the mobile 2067 node's home address and link-local address, including defending 2068 these addresses for Duplicate Address Detection, while the mobile 2069 node is registered with the home agent away from home. 2071 - When a home subnet prefix changes, the home agent tunnels Router 2072 Advertisement packets to each mobile node registered with it that 2073 is currently away from home and using a home address with the 2074 affected subnet prefix. Such tunneled Router Advertisements MUST 2075 be authenticated [7]. 2077 - When a mobile node receives a tunneled Router Advertisement 2078 containing a new subnet prefix, it MUST perform the standard 2079 autoconfiguration operation to create its new address. 2081 - When a mobile node returns to its home link, it must again 2082 perform Duplicate Address Detection at the earliest possible 2083 moment after it has deleted its "home registration" binding with 2084 its home agent. 2086 - A mobile node MAY send a Router Solicitation to its home agent at 2087 any time, within the constraints imposed by rate control defined 2088 by Neighbor Discovery [11]. 2090 10. Mobile Node Operation 2092 10.1. Sending Packets While Away from Home 2094 While a mobile node is away from home, it continues to use its home 2095 address as well as also using one or more care-of addresses. When 2096 sending a packet while away from home, a mobile node MAY choose among 2097 these in selecting the address that it will use as the source of the 2098 packet, as follows: 2100 - From the point of view of protocol layers and applications 2101 above Mobile IP (e.g., transport protocols), the mobile node 2102 will generally use its home address as the source of the packet 2103 for most packets, even while away from home, since Mobile IP 2104 is designed to make mobility transparent to such software. 2105 Doing so also makes the node's mobility and the fact that it is 2106 currently away from home transparent to the correspondent nodes 2107 with which it communicates. For packets sent that are part of 2108 transport-level connections established while the mobile node 2109 was at home, the mobile node MUST use its home address in this 2110 way. Likewise, for packets sent that are part of transport-level 2111 connections that the mobile node may still be using after moving 2112 to a new location, the mobile node SHOULD use its home address 2113 in this way. When sending such packets, Mobile IP will modify 2114 the packet to move the home address into a Home Address option 2115 and will set the IPv6 header's Source Address field to one of the 2116 mobile node's care-of address; these modifications to the packet 2117 are then reversed in the node receiving the packet, restoring 2118 the mobile node's home address to be the packet's Source Address 2119 before processing by higher protocols layers and applications. 2121 - For short-term communication, particularly for communication that 2122 may easily be retried if it fails, the mobile node MAY choose to 2123 directly use one of its care-of addresses as the source of the 2124 packet, thus not requiring the use of a Home Address option in 2125 the packet. An example of this type of communication might be 2126 DNS queries sent by the mobile node [9, 10]. Using the mobile 2127 node's care-of address as the source for such queries will 2128 generally have a lower overhead than using the mobile node's 2129 home address, since no extra options need be used in either the 2130 query or its reply, and all packets can be routed normally, 2131 directly between their source and destination without relying 2132 on Mobile IP. If the mobile node has no particular knowledge 2133 that the communication being sent fits within this type of 2134 communication, however, the mobile node SHOULD NOT use its 2135 care-of address as the source of the packet in this way. 2137 If the mobile node uses one of its care-of addresses as the source 2138 of some packet while away from home, no special Mobile IP processing 2139 is required for sending this packet. The packet is simply addressed 2140 and transmitted in the same way as any normal IPv6 packet, setting 2141 the Source Address field in the packet's IPv6 header to this care-of 2142 address. 2144 On the other hand, if while away from home, the mobile node uses its 2145 home address as the source of a packet from the point of view of 2146 higher protocol layers or applications as described above, special 2147 Mobile IP processing of this packet is required for the insertion of 2148 the Home Address option. Specifically: 2150 - Since Mobile IP is transparent to higher protocol layers (e.g., 2151 to TCP), the packet is initially constructed using the mobile 2152 node's home address as the packet's Source Address, in the same 2153 way as if the mobile node were at home. 2155 - If the mobile node is at home, no special Mobile IP processing 2156 for this packet is required. The packet is sent normally and the 2157 following additional steps are not performed. 2159 - Likewise, if the Source Address field in the packet's IPv6 header 2160 is not the mobile node's home address, no special Mobile IP 2161 processing for this packet is required. The packet is sent 2162 normally and the following additional steps are not performed. 2164 - Otherwise, insert a Home Address option into the packet, with the 2165 Home Address field copied from the original value of the Source 2166 Address field in the packet. 2168 - Change the Source Address field in the packet's IPv6 header to 2169 one of the mobile node's care-of addresses. This will typically 2170 be the mobile node's current primary care-of address, but MUST 2171 be a care-of address with a subnet prefix that is on-link on the 2172 network interface on which the mobile node will transmit the 2173 packet. 2175 This addition of the Home Address option to a packet MUST be 2176 performed before outgoing IPsec processing, such as the addition of 2177 an AH [7] or ESP [8] header to the packet, is performed. Likewise, 2178 IPsec processing for a received packet containing a Home Address 2179 option MUST be performed before the packet is possibly modified as 2180 part of processing the Home Address option. By using the care-of 2181 address as the Source Address in the IPv6 header, with the mobile 2182 node's home address instead in the Home Address option, the packet 2183 will be able to safely pass through any router implementing ingress 2184 filtering [6]. 2186 10.2. Movement Detection 2188 A mobile node MAY use any combination of mechanisms available to it 2189 to detect when it has moved from one link to another. The primary 2190 movement detection mechanism for Mobile IPv6 defined here uses the 2191 facilities of IPv6 Neighbor Discovery, including Router Discovery and 2192 Neighbor Unreachability Detection. The description here is based on 2193 the conceptual model of the organization and data structures defined 2194 by Neighbor Discovery [11]. 2196 Mobile nodes SHOULD use Router Discovery to discover new routers and 2197 on-link subnet prefixes; a mobile node MAY send Router Solicitation 2198 messages, or MAY wait for unsolicited (periodic) Router Advertisement 2199 messages, as specified for Router Discovery [11]. Based on received 2200 Router Advertisement messages, a mobile node (in the same way as any 2201 other node) maintains an entry in its Default Router List for each 2202 router, and an entry in its Prefix List for each subnet prefix, that 2203 it currently considers to be on-link. Each entry in these lists has 2204 an associated invalidation timer value (extracted from the Router 2205 Advertisement) used to expire the entry when it becomes invalid. 2207 While away from home, a mobile node SHOULD select one router from 2208 its Default Router List to use as its default router, and one subnet 2209 prefix advertised by that router from its Prefix List to use as 2210 the subnet prefix in its primary care-of address. A mobile node 2211 MAY also have associated additional care-of addresses, using other 2212 subnet prefixes from its Prefix List. The method by which a mobile 2213 node selects and forms a care-of address from the available subnet 2214 prefixes is described in Section 10.3. The mobile node registers 2215 its primary care-of address with its home agent, as described in 2216 Section 10.4. 2218 While a mobile node is away from home and using some router as its 2219 default router, it is important for the mobile node to be able to 2220 quickly detect when that router becomes unreachable, so that it can 2221 switch to a new default router and to a new primary care-of address. 2222 Since some links (notably wireless) do not necessarily work equally 2223 well in both directions, it is likewise important for the mobile 2224 node to detect when it becomes unreachable to packets sent from its 2225 default router, so that the mobile node can take steps to ensure that 2226 any correspondent nodes attempting to communicate with it can still 2227 reach it through some other route. 2229 To detect when its default router becomes unreachable, a mobile 2230 node SHOULD use Neighbor Unreachability Detection. As specified in 2231 Neighbor Discovery [11], while the mobile node is actively sending 2232 packets to (or through) its default router, the mobile node can 2233 detect that the router (as its neighbor) is still reachable either 2234 through indications from upper layer protocols on the mobile node 2235 that a connection is making "forward progress" (e.g., receipt of TCP 2236 acknowledgements for new data transmitted), or through receipt of a 2237 Neighbor Advertisement message from its default router in response 2238 to an explicit Neighbor Solicitation messages to it. Note that 2239 although this mechanism only detects that the mobile node's default 2240 router has become unreachable to the mobile node while the mobile 2241 node is actively sending packets to it, this is the only time that 2242 this direction of reachability confirmation is needed. Confirmation 2243 that the mobile node is still reachable from the router is handled 2244 separately, as described below. 2246 For a mobile node to detect when it has become unreachable to its 2247 default router, however, the mobile node cannot efficiently rely on 2248 Neighbor Unreachability Detection alone, since the network overhead 2249 would be prohibitively high in many cases for a mobile node to 2250 continually probe its default router with Neighbor Solicitation 2251 messages even when it is not otherwise actively sending packets to 2252 it. Instead, a mobile node SHOULD consider receipt of any IPv6 2253 packets from its current default router as an indication that it is 2254 still reachable from the router. Both packets from the router's IP 2255 address and (IPv6) packets from its link-layer address (e.g., those 2256 forwarded but not originated by the router) SHOULD be considered. 2258 Since the router SHOULD be sending periodic multicast Router 2259 Advertisement messages, the mobile node will have frequent 2260 opportunity to check if it is still reachable from its default 2261 router, even in the absence of other packets to it from the router. 2262 If Router Advertisements that the mobile node receives include 2263 an Advertisement Interval option, the mobile node MAY use its 2264 Advertisement Interval field as an indication of the frequency with 2265 which it should expect to continue to receive future Advertisements 2266 from that router. This field specifies the minimum rate (the maximum 2267 amount of time between successive Advertisements) that the mobile 2268 node should expect. If this amount of time elapses without the 2269 mobile node receiving any Advertisement from this router, the mobile 2270 node can be sure that at least one Advertisement sent by the router 2271 has been lost. It is thus possible for the mobile node to implement 2272 its own policy for determining the number of Advertisements from 2273 its current default router it is willing to tolerate losing before 2274 deciding to switch to a different router from which it may currently 2275 be correctly receiving Advertisements. 2277 On some types of network interfaces, the mobile node MAY also 2278 supplement this monitoring of Router Advertisements, by setting its 2279 network interface into "promiscuous" receive mode, so that it is able 2280 to receive all packets on the link, including those not link-level 2281 addressed to it. The mobile node will then be able to detect any 2282 packets sent by the router, in order to to detect reachability from 2283 the router. This use of promiscuous mode may be useful on very low 2284 bandwidth (e.g., wireless) links, but its use MUST be configurable on 2285 the mobile node. 2287 If the above means do not provide indication that the mobile node 2288 is still reachable from its current default router (i.e., the 2289 mobile node receives no packets from the router for a period of 2290 time), then the mobile node SHOULD actively probe the router with 2291 Neighbor Solicitation messages, even if it is not otherwise actively 2292 sending packets to the router. If it receives a solicited Neighbor 2293 Advertisement message in response from the router, then the mobile 2294 node can deduce that it is still reachable. It is expected that the 2295 mobile node will in most cases be able to determine its reachability 2296 from the router by listening for packets from the router as described 2297 above, and thus, such extra Neighbor Solicitation probes should 2298 rarely be necessary. 2300 With some types of networks, it is possible that additional 2301 indications about link-layer mobility can be obtained from 2302 lower-layer protocol or device driver software within the mobile 2303 node. However, a mobile node MUST NOT assume that all link-layer 2304 mobility indications from lower layers indicate a movement of the 2305 mobile node to a new link, such that the mobile node would need to 2306 switch to a new default router and primary care-of address. For 2307 example, movement of a mobile node from one cell to another in many 2308 wireless LANs can be made transparent to the IP level through use of 2309 a link-layer "roaming" protocol, as long as the different wireless 2310 LAN cells all operate as part of the same IP link with the same 2311 subnet prefix. Upon lower-layer indication of link-layer mobility, 2312 the mobile node MAY send Router Solicitation messages to determine if 2313 new routers (and new on-link subnet prefixes) are present on its new 2314 link. 2316 Such lower-layer information might also be useful to a mobile node in 2317 deciding to switch its primary care-of address to one of the other 2318 care-of addresses it has formed from the on-link subnet prefixes 2319 currently available through different routers from which the mobile 2320 node is reachable. For example, a mobile node MAY use signal 2321 strength or signal quality information (with suitable hysteresis) for 2322 its link with the available routers to decide when to switch to a new 2323 primary care-of address using that router rather than its current 2324 default router (and current primary care-of address). Even though 2325 the mobile node's current default router may still be reachable in 2326 terms of Neighbor Unreachability Detection, the mobile node MAY use 2327 such lower-layer information to determine that switching to a new 2328 default router would provide a better connection. 2330 10.3. Forming New Care-of Addresses 2332 After detecting that it has moved from one link to another (i.e., its 2333 current default router has become unreachable and it has discovered a 2334 new default router), a mobile node SHOULD form a new primary care-of 2335 address using one of the on-link subnet prefixes advertised by the 2336 new router. A mobile node MAY form a new primary care-of address 2337 at any time, except that it MUST NOT do so too frequently (not more 2338 often than once per MAX_UPDATE_RATE seconds). 2340 In addition, after discovering a new on-link subnet prefix, a mobile 2341 node MAY form a new (non-primary) care-of address using that subnet 2342 prefix, even when it has not switched to a new default router. A 2343 mobile node can have only one primary care-of address at a time 2344 (which is registered with its home agent), but it MAY have an 2345 additional care-of address for any or all of the subnet prefixes on 2346 its current link. Furthermore, since a wireless network interface 2347 may actually allow a mobile node to be reachable on more than one 2348 link at a time (i.e., within wireless transmitter range of routers 2349 on more than one separate link), a mobile node MAY have care-of 2350 addresses on more than one link at a time. The use of more than one 2351 care-of address at a time is described in Section 10.12. 2353 As described in Section 4, in order to form a new care-of address, 2354 a mobile node MAY use either stateless [18] or stateful (e.g., 2355 DHCPv6 [2]) address autoconfiguration. If a mobile node needs to 2356 send packets as part of the method of address autoconfiguration, 2357 it MUST use an IPv6 link-local address rather than its own IPv6 2358 home address as the Source Address in the IPv6 header of each such 2359 autoconfiguration packet. 2361 In some cases, a mobile node may already know a (constant) IPv6 2362 address that has been assigned to it for its use only while 2363 visiting a specific foreign link. For example, a mobile node may be 2364 statically configured with an IPv6 address assigned by the system 2365 administrator of some foreign link, for its use while visiting that 2366 link. If so, rather than using address autoconfiguration to form a 2367 new care-of address using this subnet prefix, the mobile node MAY use 2368 its own pre-assigned address as its care-of address on this link. 2370 10.4. Sending Binding Updates to the Home Agent 2372 After deciding to change its primary care-of address as described 2373 in Sections 10.2 and 10.3, a mobile node MUST register this care-of 2374 address with its home agent in order to make this its primary care-of 2375 address. To do so, the mobile node sends a packet to its home agent 2376 containing a Binding Update option, with the packet constructed as 2377 follows: 2379 - The Home Registration (H) bit MUST be set in the Binding Update. 2381 - The Acknowledge (A) bit MUST be set in the Binding Update. 2383 - The packet MUST contain a Home Address option, giving the mobile 2384 node's home address for the binding. 2386 - The care-of address for the binding MUST be used as the Source 2387 Address in the packet's IPv6 header, or the Care-of Address 2388 Present (C) bit MUST be set in the Binding Update and the care-of 2389 address for the binding MUST be specified in the Care-of Address 2390 field in the Binding Update. 2392 - The Prefix Length field SHOULD be set to the length of the mobile 2393 node's subnet prefix in its home address, to request the mobile 2394 node's home agent to serve as a home agent for all home addresses 2395 for the mobile node based on all on-link subnet prefixes on the 2396 home link. Otherwise, this field MUST be set to zero. 2398 The Acknowledge (A) bit in the Binding Update requests the home 2399 agent to return a Binding Acknowledgement in response to this 2400 Binding Update. As described in Section 5.2, the mobile node SHOULD 2401 retransmit this Binding Update to its home agent until it receives 2402 a matching Binding Acknowledgement. Once reaching a retransmission 2403 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 2404 continue to periodically retransmit the Binding Update at this rate 2405 until acknowledged (or until it begins attempting to register a 2406 different primary care-of address). 2408 The Prefix Length field in the Binding Update allows the mobile node 2409 to request its home agent to serve all home addresses for the mobile 2410 node, as indicated by the interface identifier in the mobile node's 2411 home address (the remaining low-order bits after the indicated subnet 2412 prefix), together with each on-link subnet prefix on the home link. 2413 If the mobile node has additional home addresses using a different 2414 interface identifier, then the mobile node SHOULD send an additional 2415 Binding Update to its home agent to register the care-of address for 2416 each such other home address (or set of home addresses sharing an 2417 interface identifier). 2419 It is possible that when the mobile node needs to send such a Binding 2420 Update to its home agent, that the mobile node does not know the 2421 address of any router on its home link that can serve as a home agent 2422 for it. In this case, the mobile node SHOULD use the dynamic home 2423 agent address discovery procedure to find the address of a suitable 2424 home agent on its home link. To do so, the mobile node sends the 2425 packet, as described above, with the Destination Address in the 2426 packet's IPv6 header set to the Home-Agents anycast address for its 2427 home subnet prefix. As described in Section 9.2, the home agent 2428 on its home link that receives this Binding Update will reject the 2429 Update, returning to the mobile node the home agent's own unicast 2430 IP address along with a list of the unicast IP addresses of each 2431 other home agent operating on the home link. The mobile node SHOULD 2432 then retransmit its Binding Update to one of these homes agent 2433 using the provided unicast address; the mobile node MAY re-attempt 2434 this home registration with each of these home agents in turn, by 2435 sending each a Binding Update and waiting for the matching Binding 2436 Acknowledgement, until its registration is accepted by one of these 2437 home agents. 2439 If the mobile node has a current registration with some home agent 2440 on its home link (the Lifetime for that registration has not yet 2441 expired), then the mobile node MUST attempt any new registration 2442 first with that home agent. If that registration attempt fails 2443 (e.g., times out or is rejected), the mobile node SHOULD then 2444 reattempt this registration with another home agent on its home link. 2445 If the mobile node knows of no other suitable home agent, then it MAY 2446 attempt the dynamic home agent address discovery procedure described 2447 above. 2449 10.5. Sending Binding Updates to Correspondent Nodes 2451 A mobile node MAY send a Binding Update to any correspondent node at 2452 any time to allow it to cache its current care-of address (subject to 2453 the rate limiting defined in Section 10.8). In any Binding Update 2454 sent by a mobile node, the care-of address (either the Source Address 2455 in the packet's IPv6 header or the Care-of Address field in the 2456 Binding Update) MUST be set to one of the care-of addresses currently 2457 in use by the mobile node or to the mobile node's home address. 2458 If set to one of the mobile node's current care-of addresses (the 2459 care-of address given MAY differ from the mobile node's primary 2460 care-of address), the Binding Update requests the correspondent node 2461 to create or update an entry for the mobile node in the correspondent 2462 node's Binding Cache to record this care-of address for use in 2463 sending future packets to the mobile node. If, instead, the care-of 2464 address is set to the mobile node's home address, the Binding Update 2465 requests the correspondent node to delete any existing Binding Cache 2466 entry that it has for the mobile node. A mobile node MAY set the 2467 care-of address differently for sending Binding Updates to different 2468 correspondent nodes. 2470 When sending any Binding Update, the mobile node MUST record in its 2471 Binding Update List the following fields from the Binding Update: 2473 - The IP address of the node to which the Binding Update was sent. 2475 - The home address for which the Binding Update was sent, 2477 - The remaining lifetime of the binding, initialized from the 2478 Lifetime field sent in the Binding Update. 2480 The mobile node MUST retain in its Binding Update List information 2481 about all Binding Updates sent, for which the lifetime of the 2482 binding has not yet expired. When sending a Binding Update, if an 2483 entry already exists in the mobile node's Binding Update List for 2484 an earlier Binding Update sent to that same destination node, the 2485 existing Binding Update List entry is updated to reflect the new 2486 Binding Update rather than creating a new Binding Update List entry. 2488 In general, when a mobile node sends a Binding Update to its home 2489 agent to register a new primary care-of address (as described in 2490 Section 10.4), the mobile node will also send a Binding Update to 2491 each correspondent node for which an entry exists in the mobile 2492 node's Binding Update List. Thus, correspondent nodes are generally 2493 kept updated about the mobile node's binding and can send packets 2494 directly to the mobile node using the mobile node's current care-of 2495 address. 2497 The mobile node, however, need not send these Binding Updates 2498 immediately after configuring a new care-of address. For example, 2499 since the Binding Update is a destination option and can be included 2500 in any packet sent by a mobile node, the mobile node MAY delay 2501 sending a new Binding Update to any correspondent node for a 2502 short period of time, in hopes that the needed Binding Update 2503 can be included in some packet that the mobile node sends to that 2504 correspondent node for some other reason (for example, as part of 2505 some TCP connection in use). In this case, when sending a packet 2506 to some correspondent node, the mobile node SHOULD check in its 2507 Binding Update List to determine if a new Binding Update to this 2508 correspondent node is needed, and SHOULD include the new Binding 2509 Update in this packet as necessary. 2511 In addition, when a mobile node receives a packet for which the 2512 mobile node can deduce that the original sender of the packet has no 2513 Binding Cache entry for the mobile node, or for which the mobile node 2514 can deduce that the original sender of the packet has an out-of-date 2515 care-of address for the mobile node in its Binding Cache, the mobile 2516 node SHOULD return a Binding Update to the sender giving its current 2517 care-of address. In particular, the mobile node SHOULD return a 2518 Binding Update in response to receiving a packet that meets all of 2519 the following tests: 2521 - The packet was tunneled using IPv6 encapsulation. 2523 - The Destination Address in the tunnel (outer) IPv6 header is 2524 equal to any of the mobile node's care-of addresses. 2526 - The Destination Address in the original (inner) IPv6 header is 2527 equal to the mobile node's home address. If the original packet 2528 contains a Routing header, the final Address indicated in the 2529 Routing header should be used in this comparison rather than the 2530 Destination Address in the original IPv6 header. 2532 - The Source Address in the tunnel (outer) IPv6 header differs from 2533 the Source Address in the original (inner) IPv6 header. 2535 The destination address to which the Binding Update should be sent in 2536 response to receiving a packet meeting all of the tests above, is the 2537 Source Address in the original (inner) IPv6 header of the packet. 2539 Binding Updates sent to correspondent nodes are not generally 2540 required to be acknowledged. However, if the mobile node wants to be 2541 sure that its new care-of address has been added to a correspondent 2542 node's Binding Cache, the mobile node MAY request an acknowledgement 2543 by setting the Acknowledge (A) bit in the Binding Update. In this 2544 case, however, the mobile node SHOULD NOT continue to retransmit the 2545 Binding Update once the retransmission timeout period has reached 2546 MAX_BINDACK_TIMEOUT. 2548 A mobile node MAY choose to keep its location private from certain 2549 correspondent nodes, and thus need not send new Binding Updates to 2550 those correspondents. A mobile node MAY also send a Binding Update 2551 to such a correspondent node to instruct it to delete any existing 2552 binding for the mobile node from its Binding Cache, as described in 2553 Section 5.1. No other IPv6 nodes are authorized to send Binding 2554 Updates on behalf of a mobile node. 2556 10.6. Sending Binding Updates to the Previous Default Router 2558 After switching to a new default router (and thus also changing its 2559 primary care-of address), a mobile node MAY send a Binding Update 2560 to its previous default router, giving its new care-of address. 2561 If the mobile node sends such a Binding Update, the home address 2562 for the binding, specified in the Home Address option included in 2563 the packet carrying this Binding Update, MUST be set the mobile 2564 node's old primary care-of address (that it used while using this 2565 default router), and the care-of address for the binding (either the 2566 Source Address in the packet's IPv6 header or the Care-of Address 2567 field in the Binding Update) MUST be set to the mobile node's new 2568 primary care-of address. In addition, the Home Registration (H) 2569 bit MUST also be set in this Binding Update, to request the mobile 2570 node's previous default router to temporarily act as a home agent 2571 for the mobile node's old primary care-of address. The previous 2572 default router will thus tunnel packets for the mobile node to its 2573 new care-of address. All of the procedures defined for home agent 2574 operation must be followed by this previous default router for this 2575 registration. Note that the previous router does not necessarily 2576 know the mobile node's (permanent) home address as part of this 2577 registration. 2579 10.7. Retransmitting Binding Updates 2581 If, after sending a Binding Update in which the Acknowledge (A) bit 2582 is set, a mobile node fails to receive a Binding Acknowledgement 2583 within INITIAL_BINDACK_TIMEOUT seconds, the mobile node SHOULD 2584 retransmit the Binding Update until a Binding Acknowledgement 2585 is received. Such a retransmitted Binding Update MUST use he 2586 same Sequence Number value as the original transmission. The 2587 retransmissions by the mobile node MUST use an exponential 2588 back-off process, in which the timeout period is doubled 2589 upon each retransmission until either the node receives a 2590 Binding Acknowledgement or the timeout period reaches the value 2591 MAX_BINDACK_TIMEOUT. 2593 10.8. Rate Limiting for Sending Binding Updates 2595 A mobile node MUST NOT send Binding Updates more often than once per 2596 MAX_UPDATE_RATE seconds to any node. After sending MAX_FAST_UPDATES 2597 consecutive Binding Updates to a particular node with the same 2598 care-of address, the mobile node SHOULD reduce its rate of sending 2599 Binding Updates to that node, to the rate of SLOW_UPDATE_RATE per 2600 second. The mobile node MAY continue to send Binding Updates at the 2601 slower rate indefinitely, in hopes that the node will eventually 2602 be able to process a Binding Update and begin to route its packets 2603 directly to the mobile node at its new care-of address. 2605 10.9. Receiving ICMP Error Messages 2607 The Option Type value for a Binding Update option specifies that 2608 any node receiving this option that does not recognize the Option 2609 Type SHOULD return an ICMP Parameter Problem, Code 2, message to 2610 the sender of the packet containing the Binding Update option. If 2611 a node sending a Binding Update receives such an ICMP error message 2612 in response, it should record in its Binding Update List that future 2613 Binding Updates should not be sent to this destination. 2615 Likewise, although ALL IPv6 nodes (whether host or router, whether 2616 mobile or stationary) MUST implement the ability to receive packets 2617 containing a Home Address option, all Option Type values in IPv6 2618 include a specification of the behavior that a node receiving a 2619 packet containing this option performs if it does not implement 2620 receipt of that type of option. For the Home Address option, the 2621 Option Type value specifies that any node receiving this option that 2622 does not recognize the Option Type SHOULD return an ICMP Parameter 2623 Problem, Code 2, message to the sender of the packet containing the 2624 Home Address option. If a mobile node receives such an ICMP error 2625 message from some node indicating that it does not recognize the 2626 mobile node's Home Address option, the mobile node SHOULD log the 2627 error and then discard the ICMP message; this error message indicates 2628 that the node to which the original packet was addressed (the node 2629 returning the ICMP error message) does not correctly implement this 2630 required part of the IPv6 protocol. 2632 10.10. Receiving Binding Acknowledgements 2634 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 2635 node MUST validate the packet according to the following tests: 2637 - The packet contains either an AH [7] or ESP [8] header providing 2638 sender authentication, data integrity protection, and replay 2639 protection. 2641 - The Option Length field in the option is greater than or equal to 2642 11 octets. 2644 - The Sequence Number field matches the Sequence Number sent by the 2645 mobile node to this destination address in an outstanding Binding 2646 Update. 2648 Any Binding Acknowledgement not satisfying all of these tests MUST be 2649 silently ignored, although the remainder of the packet (i.e., other 2650 options, extension headers, or payload) SHOULD be processed normally 2651 according to any procedure defined for that part of the packet. 2653 When a mobile node receives a packet carrying a valid Binding 2654 Acknowledgement, the mobile node MUST examine the Status field as 2655 follows: 2657 - If the Status field indicates that the Binding Update was 2658 accepted (the Status field is less than 128), then the mobile 2659 node MUST update the corresponding entry in its Binding Update 2660 List to indicate that the Binding Update has been acknowledged. 2661 The mobile node MUST thus stop retransmitting the Binding Update. 2663 - If the Status field indicates that the Binding Update was 2664 rejected (the Status field is greater than or equal to 128), then 2665 the mobile node MUST delete the corresponding Binding Update List 2666 entry (and MUST also stop retransmitting the Binding Update). 2667 Optionally, the mobile node MAY then take steps to correct the 2668 cause of the error and retransmit the Binding Update (with a new 2669 Sequence Number value), subject to the rate limiting restriction 2670 specified in Section 10.8. In particular, if the Status field 2671 is equal to 135 (dynamic home agent address discovery response), 2672 then the mobile node MAY reattempt its home registration with any 2673 of the home agent IP addresses listed in the Other Home Agents 2674 field in the Binding Acknowledgement or with the home agent 2675 address given in the Source Address field of the packet carrying 2676 the Binding Acknowledgement. If any of these addresses is not 2677 unicast a address or does not have a subnet prefix equal to the 2678 mobile node's own subnet prefix, then that particular address 2679 MUST be ignored and the mobile node MUST NOT reattempt its home 2680 registration with that home agent. 2682 10.11. Receiving Binding Requests 2684 When a mobile node receives a packet containing a Binding Request, 2685 it SHOULD return to the sender a packet containing a Binding Update. 2686 The Lifetime field in this Binding Update SHOULD be set to a new 2687 lifetime, extending any current lifetime remaining from a previous 2688 Binding Update sent to this node (as indicated in any existing 2689 Binding Update List entry for this node). When sending this Binding 2690 Update, the mobile node MUST update its Binding Update List in the 2691 same way as for any other Binding Update sent by the mobile node. 2693 Note, however, that the mobile node MAY choose to keep its current 2694 binding private from the sender of the Binding Request. In this 2695 case, the mobile node instead SHOULD returns a Binding Update to the 2696 sender, in which the Lifetime field is set to zero. 2698 10.12. Using Multiple Care-of Addresses 2700 As described in Section 10.3, a mobile node MAY use more than one 2701 care-of address at a time. Particularly in the case of many wireless 2702 networks, a mobile node effectively might be reachable through 2703 multiple links at the same time (e.g., with overlapping wireless 2704 cells), on which different on-link subnet prefixes may exist. A 2705 mobile node SHOULD select a primary care-of address from among those 2706 care-of addresses it has formed using any of these subnet prefixes, 2707 based on the movement detection mechanism in use, as described in 2708 Section 10.2. When the mobile node selects a new primary care-of 2709 address, it MUST register it with its home agent through a Binding 2710 Update with the Home Registration (H) and Acknowledge (A) bits set, 2711 as described in Section 10.4. 2713 To assist with smooth handoffs, a mobile node SHOULD retain 2714 its previous primary care-of address as a (non-primary) care-of 2715 address, and SHOULD still accept packets at this address, even after 2716 registering its new primary care-of address with its home agent. 2717 This is reasonable, since the mobile node could only receive packets 2718 at its previous primary care-of address if it were indeed still 2719 connected to that link. If the previous primary care-of address was 2720 allocated using stateful address autoconfiguration [2], the mobile 2721 node may not wish to release the address immediately upon switching 2722 to a new primary care-of address. 2724 10.13. Routing Multicast Packets 2726 A mobile node that is connected to its home link functions in the 2727 same way as any other (stationary) node. Thus, when it is at home, 2728 a mobile node functions identically to other multicast senders and 2729 receivers. This section therefore describes the behavior of a mobile 2730 node that is not on its home link. 2732 In order to receive packets sent to some multicast group, a mobile 2733 node must join that multicast group. One method by which a mobile 2734 node MAY join the group is via a (local) multicast router on the 2735 foreign link being visited. The mobile node SHOULD use its care-of 2736 address sharing a subnet prefix with the multicast router, as 2737 the source IPv6 address of its multicast group membership control 2738 messages. 2740 Alternatively, a mobile node MAY join multicast groups via a 2741 bi-directional tunnel to its home agent. The mobile node tunnels the 2742 appropriate multicast group membership control packets to its home 2743 agent, and the home agent forwards multicast packets down the tunnel 2744 to the mobile node. 2746 A mobile node that wishes to send packets to a multicast group 2747 also has two options: (1) send directly on the foreign link being 2748 visited; or (2) send via a tunnel to its home agent. Because 2749 multicast routing in general depends upon the Source Address used in 2750 the IPv6 header of the multicast packet, a mobile node that tunnels a 2751 multicast packet to its home agent MUST use its home address as the 2752 IPv6 Source Address of the inner multicast packet. 2754 10.14. Returning Home 2756 A mobile node detects that it has returned to its home link through 2757 the movement detection algorithm in use (Section 10.2), when the 2758 mobile node detects that its home subnet prefix is again on-link. 2759 The mobile node SHOULD then send a Binding Update to its home agent, 2760 to instruct its home agent to no longer intercept or tunnel packets 2761 for it. In this Binding Update, the mobile node MUST set the care-of 2762 address for the binding (the Source Address field in the packet's 2763 IPv6 header) to the mobile node's own home address. As with other 2764 Binding Updates sent to register with its home agent, the mobile 2765 node MUST set the Acknowledge (A) and Home Registration (H) bits, 2766 and SHOULD retransmit the Binding Update until a matching Binding 2767 Acknowledgement is received. 2769 In addition, the mobile node MUST multicast onto the home link 2770 (to the all-nodes multicast address) a Neighbor Advertisement 2771 message [11], to advertise the mobile node's own link-layer address 2772 for its own home address. The Target Address in this Neighbor 2773 Advertisement message MUST be set to the mobile node's home address, 2774 and the Advertisement MUST include a Target Link-layer Address option 2775 specifying the mobile node's link-layer address. The mobile node 2776 MUST multicast such a Neighbor Advertisement message for each of its 2777 home addresses, as defined by the current on-link prefixes, including 2778 its link-local address and site-local address. The Solicited 2779 Flag (S) in these Advertisements MUST NOT be set, since they were 2780 not solicited by any Neighbor Solicitation message. The Override 2781 Flag (O) in these Advertisements MUST be set, indicating that the 2782 Advertisements SHOULD override any existing Neighbor Cache entries at 2783 any node receiving them. 2785 Since multicasts on the local link (such as Ethernet) are typically 2786 not guaranteed to be reliable, the mobile node MAY retransmit these 2787 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 2788 increase their reliability. It is still possible that some nodes on 2789 the home link will not receive any of these Neighbor Advertisements, 2790 but these nodes will eventually be able to recover through use of 2791 Neighbor Unreachability Detection [11]. 2793 11. Constants 2795 INITIAL_BINDACK_TIMEOUT 1 second 2797 MAX_BINDACK_TIMEOUT 256 seconds 2799 MAX_UPDATE_RATE once per second 2801 SLOW_UPDATE_RATE once per 10 seconds 2803 MAX_FAST_UPDATES 5 2805 MAX_ADVERT_REXMIT 3 2807 12. IANA Considerations 2809 This document defines four new types of IPv6 destination options, 2810 each of which must be assigned an Option Type value: 2812 - The Binding Update option, described in Section 5.1 2814 - The Binding Acknowledgement option, described in Section 5.2 2816 - The binding Request option, described in Section 5.3 2818 - The Home Address option, described in Section 5.4 2820 In addition, this document defines a new Neighbor Discovery [11] 2821 option, which must be assigned an Option Type value within the option 2822 numbering space for Neighbor Discovery messages: 2824 - The Advertisement Interval option, described in Section 6.2. 2826 Finally, this document defines a new type of anycast address, which 2827 must be assigned a reserved interface identifier value for use with 2828 any subnet prefix to define this anycast address on each subnet: 2830 - The Home-Agents anycast address, used in the dynamic home agent 2831 address discovery procedure described in Sections 9.2 and 10.4. 2833 13. Security Considerations 2835 13.1. Binding Updates, Acknowledgements, and Requests 2837 The Binding Update option described in this document will result 2838 in packets addressed to a mobile node being delivered instead to 2839 its care-of address. This ability to change the routing of these 2840 packets could be a significant vulnerability if any packet containing 2841 a Binding Update option was not authenticated. Such use of "remote 2842 redirection", for instance as performed by the Binding Update option, 2843 is widely understood to be a security problem in the current Internet 2844 if not authenticated [1]. 2846 The Binding Acknowledgement option also requires authentication, 2847 since, for example, an attacker could otherwise trick a mobile node 2848 into believing a different outcome from a registration attempt with 2849 its home agent. 2851 No authentication is required for the Binding Request option, since 2852 the use of this option does not modify or create any state in either 2853 the sender or the receiver. The Binding Request option does open 2854 some issues with binding privacy, but those issues can be dealt with 2855 either through existing IPsec encryption mechanisms or through use of 2856 firewalls. 2858 The existing IPsec replay protection mechanisms allow a "replay 2859 protection window" to support receiving packets out of order. 2860 Although appropriate for many forms of communication, Binding Updates 2861 MUST be applied only in the order sent. The Binding Update option 2862 thus includes a Sequence Number field to provide this necessary 2863 sequencing. The use of this Sequence Number together with IPsec 2864 replay protection is similar in many ways, for example, to the the 2865 sequence number in TCP. IPsec provides strong replay protection but 2866 no ordering, and the sequence number provides ordering but need not 2867 worry about replay protection such as through the sequence number 2868 wrapping around. 2870 13.2. Home Address Options 2872 No special authentication of the Home Address option is required, 2873 except that if the IPv6 header of a packet is covered by 2874 authentication, then that authentication MUST also cover the Home 2875 Address option; this coverage is achieved automatically by the 2876 definition of the Option Type code for the Home Address option 2877 (Section 5.4), since it indicates that the option is included in the 2878 authentication computation. Thus, even when authentication is used 2879 in the IPv6 header, the security of the Source Address field in the 2880 IPv6 header is not compromised by the presence of a Home Address 2881 option. Without authentication of the packet, then any field in the 2882 IPv6 header, including the Source Address field, and any other parts 2883 of the packet, including the Home Address option, can be forged or 2884 modified in transit. In this case, the contents of the Home Address 2885 option is no more suspect than any other part of the packet. 2887 The use of the Home Address option allows packets sent by a 2888 mobile node to pass normally through routers implementing ingress 2889 filtering [6]. Since the care-of address used in the Source Address 2890 field of the packet's IPv6 header is topologically correct for the 2891 sending location of the mobile node, ingress filtering can trace the 2892 location of the mobile node in the same way as can be done with any 2893 sender when ingress filtering is in use. 2895 However, if a node receiving a packet that includes a Home Address 2896 option implements the processing of this option by physically 2897 copying the Home Address field from the option into the IPv6 header, 2898 replacing the Source Address field there, then the ability to 2899 trace the true location of the sender is removed once this step 2900 in the processing is performed. This diminishing of the power of 2901 ingress filtering only occurs once the packet has been received at 2902 its ultimate destination, and does not affect the capability of 2903 ingress filtering while the packet is in transit. Furthermore, this 2904 diminishing can be entirely eliminated by appropriate implementation 2905 techniques in the receiving node. For example, the original contents 2906 of the Source Address field (the sending care-of address) could be 2907 saved elsewhere in memory with the packet, until all processing of 2908 the packet is completed. 2910 13.3. General Mobile Computing Issues 2912 The mobile computing environment is potentially very different from 2913 the ordinary computing environment. In many cases, mobile computers 2914 will be connected to the network via wireless links. Such links 2915 are particularly vulnerable to passive eavesdropping, active replay 2916 attacks, and other active attacks. Furthermore, mobile computers 2917 are more susceptible to loss or theft than stationary computers. 2918 Any secrets such as authentication or encryption keys stored on the 2919 mobile computer are thus subject to compromise in ways generally not 2920 common in the non-mobile environment. 2922 Users who have sensitive data that they do not wish others to have 2923 access to should use additional mechanisms (such as encryption) to 2924 provide privacy protection, but such mechanisms are beyond the scope 2925 of this document. Users concerned about traffic analysis should 2926 consider appropriate use of link encryption. If stronger location 2927 privacy is desired, the mobile node can create a tunnel to its home 2928 agent. Then, packets destined for correspondent nodes will appear 2929 to emanate from the home subnet, and it may be more difficult to 2930 pinpoint the location of the mobile node. Such mechanisms are all 2931 beyond the scope of this document. 2933 Changes from Previous Draft 2935 This appendix briefly lists some of the major changes in this 2936 draft relative to the previous version of this same draft, 2937 draft-ietf-mobileip-ipv6-04.txt: 2939 - Replaced the ID Length field in the Binding Update with the 2940 Prefix Length field. 2942 - Added a definition of "interface identifier" in Section 3.1. 2944 - Added a description of dynamic home agent address discovery to 2945 the basic operation overview in Section 4.1. 2947 - Added a description of the new Home Agents List conceptual data 2948 structure in Section 4.3. This list is used in the dynamic home 2949 agent address discovery mechanism. 2951 - Added the Other Home Agents field to the Binding Acknowledgement 2952 option format, and modified the description of the setting 2953 for the Option Length field in the Binding Acknowledgement to 2954 accommodate the Other Home Agents field. This field is used in 2955 the dynamic home agent address discovery mechanism. 2957 - Added Section 9.1, describing the processing performed by a 2958 home agent to maintain its Home Agents List when the home agent 2959 receives a valid Router Advertisement message in which the Home 2960 Agent (H) bit is set. 2962 - Revised the description of dynamic home agent address discovery 2963 in Section 9.2 to include use of the new Home Agents List and 2964 the return of the IP addresses from this list in the Other Home 2965 Agents field of the Binding Acknowledgement that rejects the 2966 anycast Binding Update. 2968 - Revised Section 10.10 to include a description of the Other Home 2969 Agents field in the received Binding Acknowledgement. 2971 - Added Section 6, listing modifications to IPv6 Neighbor 2972 Discovery: The Router Advertisement message is changed to 2973 include the Home Agent (H) bit, a new Advertisement Interval 2974 option is defined for Router Advertisement messages, and the 2975 value of MinRtrAdvInterval for home agents is allowed to be less 2976 than the generic limit for routers of 3 seconds [11]. 2978 - Added a description in the IANA Considerations in Section 12, of 2979 the need to assign an Option Type value for the new Advertisement 2980 Interval option that can appear on Router Advertisement messages. 2982 - Changed the rule in Section 9.3 dealing with forwarding 2983 site-local-addressed packets to a mobile node while the mobile 2984 nodes is away from home. Such packets now MUST NOT be tunneled 2985 to the mobile node, unless the mobile node's registered primary 2986 care-of address is within the same site as the mobile node's home 2987 address. 2989 - Added a description in Section 10.9 of what a mobile node should 2990 do if it receives an ICMP Parameter Problem error message in 2991 response to the Home Address option in some packet that it 2992 sent. Although ALL IPv6 nodes MUST implement receipt of packets 2993 containing a Home Address option, the encoding of an Option Type 2994 value in IPv6 always specifies some behavior for the case in 2995 which the receiver does not recognize that type of option. 2997 - In Section 10.2, changed SHOULD to MAY in specifying that upon 2998 lower-layer indication of link-layer mobility, the mobile node 2999 MAY send Router Solicitation messages to determine if new routers 3000 are present on its new link. 3002 - Also in Section 10.2, added a description of how the value 3003 specified in the Advertisement Interval option in received 3004 Router Advertisements MAY be used in the mobile node's movement 3005 detection algorithm. 3007 - Moved the section on routing multicast packets to and from a 3008 mobile host while away from home, to now be Section 10.13, 3009 a subsection of the description of mobile node operation 3010 (Section 10), rather than being a separate section on its own. 3011 This better integrates this operation into the document. 3013 - Corrected the specification of the length of the Binding Update 3014 option. The correct length is 24, not 16, if the Care-of Address 3015 Present (C) bit is set. 3017 - Corrected the specification of the length of the Binding 3018 Acknowledgement option. The correct length is 11, not 12 (plus 3019 16 times the number of addresses listed in the Other Home Agents 3020 field in the Acknowledgement). 3022 - Other minor clarifications and correction of typographical errors 3023 throughout. 3025 Acknowledgements 3027 We would like to thank the members of the Mobile IP and IPng Working 3028 Groups for their comments and suggestions on this work. We would 3029 particularly like to thank Josh Broch, Thomas Narten, Erik Nordmark, 3030 and Jim Solomon for their detailed reviews of earlier versions of 3031 this draft. Their suggestions have helped to improve both the design 3032 and presentation of the protocol. 3034 References 3036 [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 3037 ACM Computer Communications Review, 19(2), March 1989. 3039 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 3040 Protocol for IPv6 (DHCPv6). Internet-Draft, 3041 draft-ietf-dhc-dhcpv6-10.txt, May 1997. Work in progress. 3043 [3] Scott Bradner. Key words for use in RFCs to indicate 3044 requirement levels. RFC 2119, March 1997. 3046 [4] Alex Conta and Stephen Deering. Generic packet 3047 tunneling in IPv6 specification. Internet-Draft, 3048 draft-ietf-ipngwg-ipv6-tunnel-07.txt, December 1996. 3049 Work in progress. 3051 [5] Stephen E. Deering and Robert M. Hinden. Internet 3052 Protocol version 6 (IPv6) specification. Internet-Draft, 3053 draft-ietf-ipngwg-ipv6-spec-v2-00.txt, July 1997. Work in 3054 progress. 3056 [6] Paul Ferguson and Daniel Senie. Network ingress filtering: 3057 Defeating denial of service attacks which employ IP source 3058 address spoofing. RFC 2267, January 1998. 3060 [7] Stephen Kent and Randall Atkinson. IP Authentication header. 3061 Internet-Draft, draft-ietf-ipsec-auth-header-02.txt, October 3062 1997. Work in progress. 3064 [8] Stephen Kent and Randall Atkinson. IP Encapsulating Security 3065 Payload (ESP). Internet-Draft, draft-ietf-ipsec-esp-v2-01.txt, 3066 October 1997. Work in progress. 3068 [9] P. Mockapetris. Domain Names---concepts and facilities. 3069 RFC 1034, November 1987. 3071 [10] P. Mockapetris. Domain Names---implementation and 3072 specification. RFC 1035, November 1987. 3074 [11] Thomas Narten, Erik Nordmark, and William Allen Simpson. 3075 Neighbor Discovery for IP version 6 (IPv6). Internet-Draft, 3076 draft-ietf-ipngwg-discovery-v2-00.txt, July 1997. Work in 3077 progress. 3079 [12] Charles Perkins. IP encapsulation within IP. RFC 2003, October 3080 1996. 3082 [13] Charles Perkins, editor. IP mobility support. RFC 2002, 3083 October 1996. 3085 [14] Charles Perkins. Minimal encapsulation within IP. RFC 2004, 3086 October 1996. 3088 [15] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 3090 [16] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 3091 September 1981. 3093 [17] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 3094 October 1994. 3096 [18] Susan Thomson and Thomas Narten. IPv6 stateless address 3097 autoconfiguration. Internet-Draft, 3098 draft-ietf-ipngwg-addrconf-v2-00.txt, July 1997. 3100 Chair's Address 3102 The Working Group can be contacted via its current chairs: 3104 Jim Solomon 3105 Motorola, Inc. 3106 1301 E. Algonquin Rd. 3107 Schaumburg, IL 60196 3108 USA 3110 Phone: +1 847 576-2753 3111 E-mail: solomon@comm.mot.com 3113 Erik Nordmark 3114 Sun Microsystems, Inc. 3115 2550 Garcia Avenue 3116 Mt. View, CA 94041 3117 USA 3119 Phone: +1 415 786-5166 3120 Fax: +1 415 786-5896 3121 E-mail: nordmark@sun.com 3123 Authors' Addresses 3125 Questions about this document can also be directed to the authors: 3127 David B. Johnson 3128 Carnegie Mellon University 3129 Computer Science Department 3130 5000 Forbes Avenue 3131 Pittsburgh, PA 15213-3891 3132 USA 3134 Phone: +1 412 268-7399 3135 Fax: +1 412 268-5576 3136 E-mail: dbj@cs.cmu.edu 3138 Charles Perkins 3139 Sun Microsystems, Inc. 3140 Technology Development Group 3141 Mail Stop MPK15-214 3142 Room 2682 3143 901 San Antonio Road 3144 Palo Alto, CA 94303 3145 USA 3147 Phone: +1 415 786-6464 3148 Fax: +1 415 786-6445 3149 E-mail: cperkins@eng.sun.com