idnits 2.17.1 draft-ietf-mobileip-ipv6-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 98 pages 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Packets sent by a mobile node while away from home generally include a Home Address option. When any node receives a packet containing a Home Address option, it MUST process the option in a manner consistent with copying the Home Address field from the Home Address option into the IPv6 header, replacing the original value of the Source Address field there. However, any actual modifications to the Source Address field in the packet's IPv6 header MUST not be performed until after all processing of other options contained in this same Destination Options extension header is completed. -- 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 (25 June 1999) is 9073 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2267 (ref. '6') (Obsoleted by RFC 2827) ** Obsolete normative reference: RFC 2373 (ref. '7') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2402 (ref. '9') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2461 (ref. '14') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2002 (ref. '16') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '18' ** Obsolete normative reference: RFC 793 (ref. '21') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '22') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2462 (ref. '23') (Obsoleted by RFC 4862) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group David B. Johnson 2 INTERNET-DRAFT Carnegie Mellon University 3 Charles Perkins 4 Sun Microsystems 5 25 June 1999 7 Mobility Support in IPv6 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note 18 that other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies the operation of mobile computers using IPv6. 35 Each mobile node is always identified by its home address, regardless 36 of its current point of attachment to the Internet. While situated 37 away from its home, a mobile node is also associated with a care-of 38 address, which provides information about the mobile node's current 39 location. IPv6 packets addressed to a mobile node's home address are 40 transparently routed to its care-of address. The protocol enables 41 IPv6 nodes to cache the binding of a mobile node's home address with 42 its care-of address, and to then send any packets destined for the 43 mobile node directly to it at this care-of address. To support this 44 operation, Mobile IPv6 defines four new IPv6 destination options, 45 including one that MUST be supported in packets received by any node, 46 whether mobile or stationary. 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 6 59 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 61 3.3. Specification Language . . . . . . . . . . . . . . . . . 8 63 4. Overview of Mobile IPv6 9 64 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 65 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11 66 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 13 67 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 17 69 5. New IPv6 Destination Options 19 70 5.1. Binding Update Option Format . . . . . . . . . . . . . . 19 71 5.2. Binding Acknowledgement Option Format . . . . . . . . . . 23 72 5.3. Binding Request Option Format . . . . . . . . . . . . . . 27 73 5.4. Home Address Option Format . . . . . . . . . . . . . . . 29 74 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 31 76 6. Modifications to IPv6 Neighbor Discovery 33 77 6.1. Modified Router Advertisement Message Format . . . . . . 33 78 6.2. Modified Prefix Information Option Format . . . . . . . . 34 79 6.3. New Advertisement Interval Option Format . . . . . . . . 36 80 6.4. New Home Agent Information Option Format . . . . . . . . 37 81 6.5. Changes to Sending Router Advertisements . . . . . . . . 39 82 6.6. Changes to Sending Router Solicitations . . . . . . . . . 40 84 7. Requirements for IPv6 Nodes 42 85 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 42 86 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 42 87 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 42 88 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 43 90 8. Correspondent Node Operation 45 91 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 45 92 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 45 93 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 46 94 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 47 95 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 47 96 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 48 97 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 48 98 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 49 99 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 50 101 9. Home Agent Operation 52 102 9.1. Receiving Router Advertisement Messages . . . . . . . . . 52 103 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 53 104 9.3. Primary Care-of Address Registration . . . . . . . . . . 55 105 9.4. Primary Care-of Address De-registration . . . . . . . . . 57 106 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 58 107 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 60 108 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 61 110 10. Mobile Node Operation 65 111 10.1. Sending Packets While Away from Home . . . . . . . . . . 65 112 10.2. Receiving Packets While Away from Home . . . . . . . . . 67 113 10.3. Movement Detection . . . . . . . . . . . . . . . . . . . 68 114 10.4. Forming New Care-of Addresses . . . . . . . . . . . . . . 71 115 10.5. Sending Binding Updates to the Home Agent . . . . . . . . 72 116 10.6. Dynamic Home Agent Address Discovery . . . . . . . . . . 73 117 10.7. Sending Binding Updates to Correspondent Nodes . . . . . 74 118 10.8. Sending Binding Updates to the Previous Default Router . 76 119 10.9. Retransmitting Binding Updates . . . . . . . . . . . . . 77 120 10.10. Rate Limiting for Sending Binding Updates . . . . . . . . 77 121 10.11. Receiving Binding Acknowledgements . . . . . . . . . . . 77 122 10.12. Receiving Binding Requests . . . . . . . . . . . . . . . 78 123 10.13. Receiving ICMP Error Messages . . . . . . . . . . . . . . 79 124 10.14. Receiving Tunneled Router Advertisements . . . . . . . . 79 125 10.15. Using Multiple Care-of Addresses . . . . . . . . . . . . 80 126 10.16. Routing Multicast Packets . . . . . . . . . . . . . . . . 81 127 10.17. Returning Home . . . . . . . . . . . . . . . . . . . . . 82 129 11. Constants 83 131 12. IANA Considerations 84 133 13. Security Considerations 85 134 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 85 135 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 85 136 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 86 138 Changes from Previous Version of the Draft 88 140 Acknowledgements 90 142 References 91 144 Chair's Address 93 146 Authors' Addresses 94 147 1. Introduction 149 This document specifies the operation of mobile computers using 150 Internet Protocol Version 6 (IPv6) [5]. Without specific support 151 for mobility in IPv6, packets destined to a mobile node (host or 152 router) would not be able to reach it while the mobile node is away 153 from its home link (the link on which its home IPv6 subnet prefix is 154 in use), since routing is based on the subnet prefix in a packet's 155 destination IP address. In order to continue communication in spite 156 of its movement, a mobile node could change its IP address each time 157 it moves to a new link, but the mobile node would then not be able 158 to maintain transport and higher-layer connections when it changes 159 location. Mobility support in IPv6 is particularly important, as 160 mobile computers are likely to account for a majority or at least a 161 substantial fraction of the population of the Internet during the 162 lifetime of IPv6. 164 The protocol operation defined here, known as Mobile IPv6, allows a 165 mobile node to move from one link to another without changing the 166 mobile node's IP address. A mobile node is always addressable by 167 its "home address", an IP address assigned to the mobile node within 168 its home subnet prefix on its home link. Packets may be routed to 169 the mobile node using this address regardless of the mobile node's 170 current point of attachment to the Internet, and the mobile node may 171 continue to communicate with other nodes (stationary or mobile) after 172 moving to a new link. The movement of a mobile node away from its 173 home link is thus transparent to transport and higher-layer protocols 174 and applications. 176 The Mobile IPv6 protocol is just as suitable for mobility across 177 homogeneous media as for mobility across heterogeneous media. For 178 example, Mobile IPv6 facilitates node movement from one Ethernet 179 segment to another as well as it facilitates node movement from an 180 Ethernet segment to a wireless LAN cell, with the mobile node's IP 181 address remaining unchanged in spite of such movement. 183 One can think of the Mobile IPv6 protocol as solving the "macro" 184 mobility management problem. More "micro" mobility management 185 applications -- for example, handoff among wireless transceivers, 186 each of which covers only a very small geographic area -- are 187 possibly more suited to other solutions. For example, in many 188 current wireless LAN products, link-layer mobility mechanisms allow a 189 "handoff" of a mobile node from one cell to another, reestablishing 190 link-layer connectivity to the node in each new location. As long 191 as such handoff occurs only within cells of the mobile node's home 192 link, such link-layer mobility mechanisms are likely to offer faster 193 convergence and lower overhead than Mobile IPv6. Extensions to the 194 Mobile IPv6 protocol are also possible to support a more local, 195 hierarchical form of mobility management, but such extensions are 196 beyond the scope of this document. 198 The protocol specified in this document solves the problem of 199 transparently routing packets to and from mobile nodes while away 200 from home. However, it does not attempt to solve all general 201 problems related to the use of mobile computers or wireless networks. 202 In particular, this protocol does not attempt to solve: 204 - Handling links with partial reachability, such as typical 205 wireless networks. Some aspects of this problem are addressed 206 by the movement detection procedure described in Section 10.3, 207 but no attempt has been made to fully solve this problem in its 208 general form. Most aspects of this problem can be solved by the 209 workaround of restricting such networks to only one router per 210 link, although there are still possible hidden terminal problems 211 when two nodes on the same link (on opposite sides of the router) 212 attempt to communicate directly. 214 - Access control on a link being visited by a mobile node. This 215 is a general problem any time an untrusted node is allowed 216 to connect to any link layer. It is independent whether the 217 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 218 address on the link. 220 2. Comparison with Mobile IP for IPv4 222 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 223 natural combination of the experiences gained from the development 224 of Mobile IP support in IPv4 (Mobile IPv4) [16, 15, 17], together 225 with the opportunities provided by the design and deployment of a new 226 version of IP itself (IPv6) and the new protocol features offered 227 by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, 228 but the protocol is now fully integrated into IP and provides many 229 improvements over Mobile IPv4. This section summarizes the major 230 differences between Mobile IPv4 and Mobile IPv6: 232 - Support for what is known in Mobile IPv4 as "Route 233 Optimization" [18] is now built in as a fundamental part 234 of the protocol, rather than being added on as a optional 235 set of extensions that may not be supported by all nodes 236 as in Mobile IPv4. This integration of Route Optimization 237 functionality allows direct routing from any correspondent node 238 to any mobile node, without needing to pass through the mobile 239 node's home network and be forwarded by its home agent, and thus 240 eliminates the problem of "triangle routing" present in the base 241 Mobile IPv4 protocol [16]. This integration also allows the 242 Mobile IPv4 "registration" functionality and the Mobile IPv4 243 Route Optimization functionality to be performed by a single 244 protocol rather than two separate (and different) protocols. 246 - Support is also integrated into Mobile IPv6 -- and into IPv6 247 itself -- for allowing mobile nodes and Mobile IP to coexist 248 efficiently with routers that perform "ingress filtering" [6]. A 249 mobile node now uses its care-of address as the Source Address in 250 the IP header of packets it sends, allowing the packets to pass 251 normally through ingress filtering routers. The home address 252 of the mobile node is carried in the packet in a Home Address 253 destination option, allowing the use of the care-of address in 254 the packet to be transparent above the IP layer. The ability 255 to correctly process a Home Address option in a received packet 256 is required in all IPv6 nodes, whether mobile nor stationary, 257 whether host or router. 259 - The use of the care-of address as the Source Address in each 260 packet's IP header also simplifies routing of multicast packets 261 sent by a mobile node. With Mobile IPv4, the mobile node 262 had to tunnel multicast packets to its home agent in order to 263 transparently use its home address as the source of the multicast 264 packets. With Mobile IPv6, the use of the Home Address option 265 allows the home address to be used but still be compatible with 266 multicast routing that is based in part on the packet's Source 267 Address. 269 - There is no longer any need to deploy special routers as 270 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 271 mobile nodes make use of the enhanced features of IPv6, such 272 as Neighbor Discovery [14] and Address Autoconfiguration [23], 273 to operate in any location away from home without any special 274 support required from its local router. 276 - Unlike Mobile IPv4, Mobile IPv6 utilizes IPsec [9, 10, 11] for 277 all security requirements (sender authentication, data integrity 278 protection, and replay protection) for Binding Updates (which 279 serve the role of both registration and Route Optimization in 280 Mobile IPv4). Mobile IPv4 relies on its own security mechanisms 281 for these functions, based on statically configured "mobility 282 security associations". 284 - The movement detection mechanism in Mobile IPv6 provides 285 bidirectional confirmation of a mobile node's ability to 286 communicate with its default router in its current location 287 (packets that the router sends are reaching the mobile node, and 288 packets that the mobile node sends are reaching the router). 289 This confirmation provides a detection of the "black hole" 290 situation that may exist in some wireless environments where the 291 link to the router does not work equally well in both directions, 292 such as when the mobile node has moved out of good wireless 293 transmission range from the router. The mobile node may then 294 attempt to find a new router and begin using a new care-of 295 address if its link to its current router is not working well. 296 In contrast, in Mobile IPv4, only the forward direction (packets 297 from the router are reaching the mobile node) is confirmed, 298 allowing the black hole condition to persist. 300 - Most packets sent to a mobile node while away from home in 301 Mobile IPv6 are tunneled using an IPv6 Routing header rather than 302 IP encapsulation, whereas Mobile IPv4 must use encapsulation 303 for all packets. The use of a Routing header requires less 304 additional header bytes to be added to the packet, reducing the 305 overhead of Mobile IP packet delivery. To avoid modifying the 306 packet in flight, however, packets intercepted and tunneled 307 by a mobile node's home agent in Mobile IPv6 must still use 308 encapsulation for tunneling. 310 - While a mobile node is away from home, its home agent intercepts 311 any packets for the mobile node that arrive at the home network, 312 using IPv6 Neighbor Discovery [14] rather than ARP [19] as is 313 used in Mobile IPv4. The use of Neighbor Discovery improves 314 the robustness of the protocol (e.g., due to the Neighbor 315 Advertisement "override" bit) and simplifies implementation 316 of Mobile IP due to the ability to not be concerned with any 317 particular link layer as is required in ARP. 319 - The use of IPv6 encapsulation (and the Routing header) removes 320 the need in Mobile IPv6 to manage "tunnel soft state", which was 321 required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 322 to the definition of ICMP for IPv6, the use of tunnel soft state 323 is no longer required in IPv6 for correctly relaying ICMP error 324 messages from within the tunnel back to the original sender of 325 the packet. 327 - The dynamic home agent address discovery mechanism in Mobile IPv6 328 uses IPv6 anycast [8] and returns a single reply to the mobile 329 node, rather than the corresponding Mobile IPv4 mechanism that 330 used IPv4 directed broadcast and returned a separate reply from 331 each home agent on the mobile node's home link. The Mobile IPv6 332 mechanism is more efficient and more reliable, since only 333 one packet need be sent back to the mobile node and since the 334 mobile node is less likely to lose one of the replies because no 335 "implosion" of replies is required by the protocol. 337 - Mobile IPv6 defines an Advertisement Interval option on 338 Router Advertisements (equivalent to Agent Advertisements in 339 Mobile IPv4), allowing a mobile node to decide for itself how 340 many Router Advertisements (Agent Advertisements) it is willing 341 to miss before declaring its current router unreachable. 343 - The use of IPv6 destination options allows all Mobile IPv6 344 control traffic to be piggybacked on any existing IPv6 packets, 345 whereas in Mobile IPv4 and its Route Optimization extensions, 346 separate UDP packets were required for each control message. 348 3. Terminology 350 3.1. General Terms 352 IP 354 Internet Protocol Version 6 (IPv6). 356 node 358 A device that implements IP. 360 router 362 A node that forwards IP packets not explicitly addressed to 363 itself. 365 host 367 Any node that is not a router. 369 link 371 A communication facility or medium over which nodes can 372 communicate at the link layer, such as an Ethernet (simple or 373 bridged). A link is the layer immediately below IP. 375 interface 377 A node's attachment to a link. 379 subnet prefix 381 A bit string that consists of some number of initial bits of an 382 IP address. 384 interface identifier 386 A number used to identify a node's interface on a link. The 387 interface identifier is the remaining low-order bits in the 388 node's IP address after the subnet prefix. 390 link-layer address 392 A link-layer identifier for an interface, such as IEEE 802 393 addresses on Ethernet links. 395 packet 397 An IP header plus payload. 399 3.2. Mobile IPv6 Terms 401 home address 403 An IP address assigned to a mobile node within its home link. 405 home subnet prefix 407 The IP subnet prefix corresponding to a mobile node's home 408 address. 410 home link 412 The link on which a mobile node's home subnet prefix is 413 defined. Standard IP routing mechanisms will deliver packets 414 destined for a mobile node's home address to its home link. 416 mobile node 418 A node that can change its point of attachment from one link to 419 another, while still being reachable via its home address. 421 movement 423 A change in a mobile node's point of attachment to the Internet 424 such that it is no longer connected to the same link as it was 425 previously. If a mobile node is not currently attached to its 426 home link, the mobile node is said to be "away from home". 428 correspondent node 430 A peer node with which a mobile node is communicating. The 431 correspondent node may be either mobile or stationary. 433 foreign subnet prefix 435 Any IP subnet prefix other than the mobile node's home subnet 436 prefix. 438 foreign link 440 Any link other than the mobile node's home link. 442 home agent 444 A router on a mobile node's home link with which the mobile 445 node has registered its current care-of address. While the 446 mobile node is away from home, the home agent intercepts 447 packets on the home link destined to the mobile node's home 448 address, encapsulates them, and tunnels them to the mobile 449 node's registered care-of address. 451 care-of address 453 An IP address associated with a mobile node while visiting a 454 foreign link; the subnet prefix of this IP address is a foreign 455 subnet prefix. Among the multiple care-of addresses that a 456 mobile node may have at a time (e.g., with different subnet 457 prefixes), the one registered with the mobile node's home agent 458 is called its "primary" care-of address. 460 binding 462 The association of the home address of a mobile node with a 463 care-of address for that mobile node, along with the remaining 464 lifetime of that association. 466 3.3. Specification Language 468 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 469 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 470 document are to be interpreted as described in RFC 2119 [3]. 472 4. Overview of Mobile IPv6 474 4.1. Basic Operation 476 A mobile node is always addressable by its home address, whether it 477 is currently attached to its home link or is away from home. While 478 a mobile node is at home, packets addressed to its home address are 479 routed to it using conventional Internet routing mechanisms in the 480 same way as if the node were never mobile. Since the subnet prefix 481 of a mobile node's home address is the subnet prefix (or one of the 482 subnet prefixes) on the mobile node's home link (it is the mobile 483 node's home subnet prefix), packets addressed to it will be routed to 484 its home link. 486 While a mobile node is attached to some foreign link away from home, 487 it is also addressable by one or more care-of addresses, in addition 488 to its home address. A care-of address is an IP address associated 489 with a mobile node while visiting a particular foreign link. The 490 subnet prefix of a mobile node's care-of address is the subnet prefix 491 (or one of the subnet prefixes) on the foreign link being visited by 492 the mobile node; if the mobile node is connected to this foreign link 493 while using that care-of address, packets addressed to this care-of 494 address will be routed to the mobile node in its location away from 495 home. 497 The association between a mobile node's home address and care-of 498 address is known as a "binding" for the mobile node. A mobile node 499 typically acquires its care-of address through stateless [23] or 500 stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according 501 to the methods of IPv6 Neighbor Discovery [14]. Other methods 502 of acquiring a care-of address are also possible, such as static 503 pre-assignment by the owner or manager of a particular foreign link, 504 but details of such other methods are beyond the scope of this 505 document. 507 While away from home, a mobile node registers one of its care-of 508 addresses with a router on its home link, requesting this router 509 to function as the "home agent" for the mobile node. This binding 510 registration is done by the mobile node sending to the home agent 511 a packet containing a "Binding Update" destination option; the 512 home agent then replies to the mobile node by returning a packet 513 containing a "Binding Acknowledgement" destination option. The 514 care-of address in this binding registered with its home agent is 515 known as the mobile node's "primary care-of address". The mobile 516 node's home agent thereafter uses proxy Neighbor Discovery to 517 intercept any IPv6 packets addressed to the mobile node's home 518 address (or home addresses) on the home link, and tunnels each 519 intercepted packet to the mobile node's primary care-of address. 520 To tunnel each intercepted packet, the home agent encapsulates the 521 packet using IPv6 encapsulation [4], with the outer IPv6 header 522 addressed to the mobile node's primary care-of address. 524 Section 10.15 discusses the reasons why it may be desirable for 525 a mobile node to use more than one care-of address at the same 526 time. However, a mobile node's primary care-of address is distinct 527 among these in that the home agent maintains only a single care-of 528 address registered for each mobile node, and always tunnels a mobile 529 node's packets intercepted from its home link to this mobile node's 530 registered primary care-of address. The home agent thus need not 531 implement any policy to determine which of possibly many care-of 532 addresses to which to tunnel each intercepted packet, leaving the 533 mobile node entirely in control of this policy by which of its 534 care-of addresses it registers with its home agent. 536 It is possible that while a mobile node is away from home, some nodes 537 on its home link may be reconfigured, such that the router that was 538 operating as the mobile node's home agent is replaced by a different 539 router serving this role. In this case, the mobile node may not 540 know the IP address of its own home agent. Mobile IPv6 provides a 541 mechanism, known as "dynamic home agent address discovery", that 542 allows a mobile node to dynamically discover the IP address of a home 543 agent on its home link with which it may register its care-of address 544 while away from home. The mobile node sends a Binding Update to the 545 "Mobile IPv6 Home-Agents" anycast address for its own home subnet 546 prefix [8] and thus reaches one of the (possibly many) routers on 547 its home link currently operating as a home agent. This home agent 548 rejects the mobile node's Binding Update, but returns in the Binding 549 Acknowledgement in response a list of all home agents on the home 550 link. This list of home agents is maintained by each home agent on 551 the home link through use of the Home Agent (H) bit in each home 552 agent's periodic unsolicited multicast Router Advertisements. 554 The Binding Update and Binding Acknowledgement destination options, 555 together with a "Binding Request" destination option, are also used 556 to allow IPv6 nodes communicating with a mobile node, to dynamically 557 learn and cache the mobile node's binding. When sending a packet 558 to any IPv6 destination, a node checks its cached bindings for an 559 entry for the packet's destination address. If a cached binding for 560 this destination address is found, the node uses an IPv6 Routing 561 header [5] (instead of IPv6 encapsulation) to route the packet to 562 the mobile node by way of the care-of address indicated in this 563 binding. If, instead, the sending node has no cached binding for 564 this destination address, the node sends the packet normally (with 565 no Routing header), and the packet is subsequently intercepted and 566 tunneled by the mobile node's home agent as described above. Any 567 node communicating with a mobile node is referred to in this document 568 as a "correspondent node" of the mobile node, and may itself be 569 either a stationary node or a mobile node. 571 Since a Binding Update, Binding Acknowledgement, and Binding Request 572 are each represented in a packet as an IPv6 destination option [5], 573 they may be included in any IPv6 packet. Any of these options can be 574 sent in either of two ways: 576 - A Binding Update, Binding Acknowledgement, or Binding Request can 577 be included within any IPv6 packet carrying any payload such as 578 TCP [21] or UDP [20]. 580 - A Binding Update, Binding Acknowledgement, or Binding Request can 581 be sent as a separate IPv6 packet containing no payload. In this 582 case, the Next Header field in the last extension header in the 583 packet is set to the value 59, to indicate "No Next Header" [5]. 585 Mobile IPv6 also defines one additional IPv6 destination option. 586 When a mobile node sends a packet while away from home, it will 587 generally set the Source Address in the packet's IPv6 header to one 588 of its current care-of addresses, and will also include a "Home 589 Address" destination option in the packet, giving the mobile node's 590 home address. Many routers implement security policies such as 591 "ingress filtering" [6] that do not allow forwarding of packets that 592 appear to have a Source Address that is not topologically correct. 593 By using the care-of address as the IPv6 header Source Address, 594 the packet will be able to pass normally through such routers, 595 yet ingress filtering rules will still be able to locate the true 596 topological source of the packet in the same way as packets from 597 non-mobile nodes. By also including the Home Address option in each 598 packet, the sending mobile node can communicate its home address to 599 the correspondent node receiving this packet, allowing the use of 600 the care-of address to be transparent above the Mobile IPv6 support 601 level (e.g., at the transport layer). The inclusion of a Home 602 Address option in a packet affects only the correspondent node's 603 receipt of this single packet; no state is created or modified in the 604 correspondent node as a result of receiving a Home Address option in 605 a packet. 607 4.2. New IPv6 Destination Options 609 As discussed in general in Section 4.1, the following four new IPv6 610 destination options are defined for Mobile IPv6: 612 Binding Update 614 A Binding Update option is used by a mobile node to notify 615 a correspondent node or the mobile node's home agent of 616 its current binding. The Binding Update sent to the mobile 617 node's home agent to register its primary care-of address is 618 marked as a "home registration". Any packet that includes a 619 Binding Update option MUST also include either an AH [9] or 620 ESP [10] header providing sender authentication, data integrity 621 protection, and replay protection. The Binding Update option 622 is described in detail in Section 5.1. 624 Binding Acknowledgement 626 A Binding Acknowledgement option is used to acknowledge receipt 627 of a Binding Update, if an acknowledgement was requested 628 in the Binding Update. Any packet that includes a Binding 629 Acknowledgement option MUST also include either an AH [9] or 630 ESP [10] header providing sender authentication, data integrity 631 protection, and replay protection. The Binding Acknowledgement 632 option is described in detail in Section 5.2. 634 Binding Request 636 A Binding Request option is used to request a mobile node to 637 send to the requesting node a Binding Update containing the 638 mobile node's current binding. This option is typically used 639 by a correspondent node to refresh a cached binding for a 640 mobile node, when the cached binding is in active use but the 641 binding's lifetime is close to expiration. No authentication 642 is required for the Binding Request option. The Binding 643 Request option is described in detail in Section 5.3. 645 Home Address 647 A Home Address option is used in a packet sent by a mobile 648 node to inform the recipient of that packet of the mobile 649 node's home address. For packets sent by a mobile node while 650 away from home, the mobile node generally uses one of its 651 care-of addresses as the Source Address in the packet's IPv6 652 header. By including a Home Address option in the packet, the 653 correspondent node receiving the packet is able to substitute 654 the mobile node's home address for this care-of address when 655 processing the packet, thus making the use of the care-of 656 address transparent to the correspondent node. If the IP 657 header of a packet carrying a Home Address option is covered 658 by authentication, then the Home Address option MUST also be 659 covered by this authentication, but no other authentication is 660 required for the Home Address option. The Home Address option 661 is described in detail in Section 5.4. 663 Sub-options within the format of these options MAY be included after 664 the fixed portion of the option data specified in this document. The 665 presence of such sub-options will be indicated by the Option Length 666 field within the option. When the Option Length is greater than the 667 length required for the option specified here, the remaining octets 668 are interpreted as sub-options. The encoding and format of defined 669 sub-options are described in Section 5.5. 671 4.3. Conceptual Data Structures 673 This document describes the Mobile IPv6 protocol in terms of the 674 following three conceptual data structures: 676 Binding Cache 678 A cache, maintained by each IPv6 node, of bindings for other 679 nodes. The Binding Cache MAY be implemented in any manner 680 consistent with the external behavior described in this 681 document, for example by being combined with the node's 682 Destination Cache as maintained by Neighbor Discovery [14]. 683 When sending a packet, the Binding Cache is searched before the 684 Neighbor Discovery conceptual Destination Cache [14] (i.e., any 685 Binding Cache entry for this destination SHOULD take precedence 686 over any Destination Cache entry for the same destination). 687 Each Binding Cache entry conceptually contains the following 688 fields: 690 - The home address of the mobile node for which this is the 691 Binding Cache entry. This field is used as the key for 692 searching the Binding Cache for the destination address of 693 a packet being sent. If the destination address of the 694 packet matches the home address in the Binding Cache entry, 695 this entry SHOULD be used in routing that packet. 697 - The care-of address for the mobile node indicated by 698 the home address field in this Binding Cache entry. If 699 the destination address of a packet being routed by a 700 node matches the home address in this entry, the packet 701 SHOULD be routed to this care-of address, as described in 702 Section 8.9, for packets originated by this node, or in 703 Section 9.6, if this node is the mobile node's home agent 704 and the packet was intercepted by it on the home link. 706 - A lifetime value, indicating the remaining lifetime 707 for this Binding Cache entry. The lifetime value is 708 initialized from the Lifetime field in the Binding Update 709 that created or last modified this Binding Cache entry. 710 Once the lifetime on this entry expires, the entry MUST be 711 deleted from the Binding Cache. 713 - A flag indicating whether or not this Binding Cache entry 714 is a "home registration" entry. 716 - A flag indicating whether or not this Binding Cache entry 717 represents a mobile node that should be advertised as a 718 router in proxy Neighbor Advertisements sent by this node 719 on its behalf. This flag is only valid if the Binding 720 Cache entry indicates that this is a "home registration" 721 entry. 723 - The value of the Prefix Length field received in the 724 Binding Update that created or last modified this Binding 725 Cache entry. This field is only valid if the "home 726 registration" flag is set on this Binding Cache entry. 728 - The maximum value of the Sequence Number field received 729 in previous Binding Updates for this mobile node home 730 address. The Sequence Number field is 16 bits long, and 731 all comparisons between Sequence Number values MUST be 732 performed modulo 2**16. 734 - Recent usage information for this Binding Cache entry, as 735 needed to implement the cache replacement policy in use in 736 the Binding Cache and to assist in determining whether a 737 Binding Request should be sent when the lifetime on this 738 entry nears expiration. 740 - The time at which a Binding Request was last sent for this 741 entry, as needed to implement the rate limiting restriction 742 for sending Binding Requests. 744 An entry in a node's Binding Cache for which the node is 745 serving as a home agent is marked as a "home registration" 746 entry and SHOULD NOT be deleted by the home agent until the 747 expiration of its binding lifetime. Other Binding Cache 748 entries MAY be replaced at any time by any reasonable local 749 cache replacement policy but SHOULD NOT be unnecessarily 750 deleted. Any node's Binding Cache may contain at most one 751 entry for each mobile node home address. The contents of a 752 node's Binding Cache MUST NOT be changed in response to a Home 753 Address option in a received packet. 755 Binding Update List 757 A list, maintained by each mobile node, recording information 758 for each Binding Update sent by this mobile node, for which 759 the Lifetime sent in that Binding Update has not yet expired. 760 The Binding Update List includes all bindings sent by the 761 mobile node: those to correspondent nodes, to the mobile 762 node's home agent, and to a previous default router of the 763 mobile node. The Binding Update List MAY be implemented in any 764 manner consistent with the external behavior described in this 765 document. Each Binding Update List entry conceptually contains 766 the following fields: 768 - The IP address of the node to which a Binding Update was 769 sent. This node might still have a Binding Cache entry 770 created or updated from this Binding Update, if the Binding 771 Update was successfully received by that node (e.g., not 772 lost by the network) and if that node has not deleted the 773 entry before its expiration (e.g., to reclaim space in its 774 Binding Cache for other entries). 776 - The home address for which that Binding Update was sent. 777 This will be one of the mobile node's home addresses for 778 most Binding Updates (Sections 10.5 and 10.7), but will 779 be the mobile node's previous care-of address for Binding 780 Updates sent to the mobile node's previous default router 781 (Section 10.8). 783 - The care-of address sent in that Binding Update. This 784 value is necessary for the mobile node to determine if it 785 has sent a Binding Update giving its new care-of address to 786 this destination after changing its care-of address. 788 - The remaining lifetime of that binding. This lifetime is 789 initialized from the Lifetime value sent in the Binding 790 Update and is decremented until it reaches zero, at which 791 time this entry MUST be deleted from the Binding Update 792 List. 794 - The maximum value of the Sequence Number field sent in 795 previous Binding Updates to this destination. The Sequence 796 Number field is 16 bits long, and all comparisons between 797 Sequence Number values MUST be performed modulo 2**16. 799 - The time at which a Binding Update was last sent to this 800 destination, as needed to implement the rate limiting 801 restriction for sending Binding Updates. 803 - The state of any retransmissions needed for this Binding 804 Update, if the Acknowledge (A) bit was set in this Binding 805 Update. This state includes the time remaining until the 806 next retransmission attempt for the Binding Update, and the 807 current state of the exponential back-off mechanism for 808 retransmissions. 810 - A flag that, when set, indicates that future Binding 811 Updates should not be sent to this destination. The 812 mobile node sets this flag in the Binding Update List 813 entry when it receives an ICMP Parameter Problem, Code 2, 814 error message in response to a Binding Update sent to that 815 destination, as described in Section 10.13. 817 Home Agents List 819 A list, maintained by each home agent, recording information 820 about each other home agent on a link on which this node 821 is serving as a home agent; each home agent maintains a 822 separate Home Agents List for each such link on which it is 823 serving. This list is used in the dynamic home agent address 824 discovery mechanism. The information for the list is learned 825 through receipt of the periodic unsolicited multicast Router 826 Advertisements from each other home agent on the link, in which 827 the Home Agent (H) bit is set, in a manner similar to the 828 Default Router List conceptual data structure maintained by 829 each host for Neighbor Discovery [14]. The Home Agents List 830 MAY be implemented in any manner consistent with the external 831 behavior described in this document. Each Home Agents List 832 entry conceptually contains the following fields: 834 - The link-local IP address of another router on the home 835 link that this node currently believes is operating as 836 a home agent for this link. A new entry is created or 837 an existing entry is updated in the Home Agents List in 838 response to receipt of a valid Router Advertisement in 839 which the Home Agent (H) bit is set. The link-local 840 address of the home agent is learned through the Source 841 Address of the Router Advertisements received from it [14]. 843 - One or more global IP addresses for this home agent, 844 learned through Prefix Information options with the 845 Router Address (R) bit is set, received in Router 846 Advertisements from this link-local address. Global 847 addresses for the router in a Home Agents List entry MUST 848 be deleted once the prefix associated with that address is 849 no longer valid [14]. 851 - The remaining lifetime of this Home Agents List entry. If 852 a Home Agent Information Option is present in a Router 853 Advertisement received from a home agent, the lifetime of 854 the Home Agents List entry representing this home agent 855 is initialized from the Home Agent Lifetime field in the 856 option; otherwise, the lifetime is initialized from the 857 Router Lifetime field in the received Router Advertisement. 858 The Home Agents List entry lifetime is decremented until it 859 reaches zero, at which time this entry MUST be deleted from 860 the Home Agents List. 862 - The preference for this home agent, for use in ordering the 863 Home Agents List returned in a Binding Acknowledgement; 864 higher values indicate a more preferable home agent. The 865 preference value is taken from the Home Agent Preference 866 field (a signed, twos-complement integer) in the received 867 Router Advertisement, if the Router Advertisement contains 868 a Home Agent Information Option, and is otherwise set to 869 the default value of 0. 871 4.4. Binding Management 873 When a mobile node configures a new care-of address and decides to 874 use this new address as its primary care-of address, the mobile 875 node registers this new binding with its home agent by sending 876 the home agent a Binding Update. The mobile node indicates 877 that an acknowledgement is needed for this Binding Update and 878 continues to periodically retransmit it until acknowledged. The 879 home agent acknowledges the Binding Update by returning a Binding 880 Acknowledgement to the mobile node. 882 When a mobile node receives a packet tunneled to it from its 883 home agent, the mobile node assumes that the original sending 884 correspondent node has no Binding Cache entry for the mobile node, 885 since the correspondent node would otherwise have sent the packet 886 directly to the mobile node using a Routing header. The mobile node 887 thus returns a Binding Update to the correspondent node, allowing 888 it to cache the mobile node's binding for routing future packets to 889 it. Although the mobile node may request an acknowledgement for 890 this Binding Update, it need not, since subsequent packets from the 891 correspondent node will continue to be intercepted and tunneled by 892 the mobile node's home agent, effectively causing any needed Binding 893 Update retransmission. 895 A correspondent node with a Binding Cache entry for a mobile node 896 may refresh this binding, for example if the binding's lifetime 897 is near expiration, by sending a Binding Request to the mobile 898 node. Normally, a correspondent node will only refresh a Binding 899 Cache entry in this way if it is actively communicating with the 900 mobile node and has indications, such as an open TCP connection to 901 the mobile node, that it will continue this communication in the 902 future. When a mobile node receives a Binding Request, it replies by 903 returning a Binding Update to the node sending the Binding Request. 905 A mobile node may use more than one care-of address at the same 906 time, although only one care-of address may be registered for it at 907 its home agent as its primary care-of address. The mobile node's 908 home agent will tunnel all intercepted packets for the mobile node 909 to its (single) registered primary care-of address, but the mobile 910 node will accept packets that it receives at any of its current 911 care-of addresses. Use of more than one care-of address by a mobile 912 node may be useful, for example, to improve smooth handoff when the 913 mobile node moves from one wireless link to another. If each of 914 these wireless links is connected to the Internet through a separate 915 base station, such that the wireless transmission range from the 916 two base stations overlap, the mobile node may be able to remain 917 connected to both links while in the area of overlap. In this case, 918 the mobile node could acquire a new care-of address on the new link 919 before moving out of transmission range and disconnecting from the 920 old link. The mobile node may thus still accept packets at its 921 old care-of address while it works to update its home agent and 922 correspondent nodes, notifying them of its new care-of address on the 923 new link. 925 Since correspondent nodes cache bindings, it is expected that 926 correspondent nodes usually will route packets directly to the mobile 927 node's care-of address, so that the home agent is rarely involved 928 with packet transmission to the mobile node. This is essential for 929 scalability and reliability, and for minimizing overall network load. 930 By caching the care-of address of a mobile node, optimal routing of 931 packets can be achieved from the correspondent node to the mobile 932 node. Routing packets directly to the mobile node's care-of address 933 also eliminates congestion at the mobile node's home agent and home 934 link. In addition, the impact of any possible failure of the home 935 agent, the home link, or intervening networks leading to or from the 936 home link is reduced, since these nodes and links are not involved in 937 the delivery of most packets to the mobile node. 939 5. New IPv6 Destination Options 941 5.1. Binding Update Option Format 943 The Binding Update destination option is used by a mobile node 944 to notify other nodes of a new care-of address for itself. As a 945 destination option, it MAY be included in any existing packet being 946 sent to this same destination or MAY be sent in a packet by itself; 947 a packet containing a Binding Update is sent in the same way as any 948 packet sent by a mobile node (Section 10.1). 950 The Binding Update option is encoded in type-length-value (TLV) 951 format as follows: 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Option Type | Option Length | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 |A|H|C|R|Reservd| Prefix Length | Sequence Number | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Lifetime | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | | 963 + + 964 | | 965 + Care-of Address + 966 | (only present if C bit set) | 967 + + 968 | | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Sub-Options... 971 +-+-+-+-+-+-+-+-+-+-+-+- 973 Option Type 975 198 = 0xC6 977 Option Length 979 8-bit unsigned integer. Length of the option, in octets, 980 excluding the Option Type and Option Length fields. This field 981 MUST be set to 8 (or to 24 if the Care-of Address Present (C) 982 bit is set), plus the total length of all sub-options present, 983 including their Sub-Option Type and Sub-Option Len fields. 985 Acknowledge (A) 987 The Acknowledge (A) bit is set by the sending mobile node to 988 request a Binding Acknowledgement (Section 5.2) be returned 989 upon receipt of the Binding Update. 991 Home Registration (H) 993 The Home Registration (H) bit is set by the sending mobile node 994 to request the receiving node to act as this node's home agent. 995 The destination of the packet carrying this option MUST be that 996 of a router sharing the same subnet prefix as the home address 997 of the mobile node in the binding (given by the Home Address 998 field in the Home Address option in the packet). 1000 Care-of Address Present (C) 1002 The Care-of Address Present (C) bit, when set, indicates the 1003 presence of the Care-of Address field in the Binding Update. 1004 The care-of address for this binding is either the address in 1005 the Care-of Address field in the Binding Update, if this bit is 1006 set, or the Source Address in the packet's IPv6 header, if this 1007 bit is not set. 1009 Router (R) 1011 The Router (R) bit, when set, indicates that the sending 1012 mobile node is a router. This bit is only valid when the 1013 Home Registration (H) bit is also set, and MUST NOT be set 1014 otherwise. This bit is saved in the home agent's "home 1015 registration" Binding Cache entry for the mobile node, and 1016 is copied into the corresponding bit in all proxy Neighbor 1017 Advertisement messages sent on behalf of this mobile node by 1018 the home agent using this Binding Cache entry. 1020 Reservd 1022 Reserved. Sent as 0; ignored on reception. 1024 Prefix Length 1026 The Prefix Length field is valid only for a "home registration" 1027 Binding Update. This field MUST be zero if the Home 1028 Registration (H) bit is not set in the Binding Update. The 1029 Prefix Length field is set by the sending mobile node to the 1030 (nonzero) length of its subnet prefix in its home address 1031 (given in the Home Address option in the packet) to request 1032 its home agent to use the interface identifier in the mobile 1033 node's home address (the remaining low-order bits after the 1034 indicated subnet prefix) to form all other home addresses for 1035 the mobile node on the home link. The home agent becomes the 1036 home agent not only for the individual home address given in 1037 this binding, but also for all other home addresses for this 1038 mobile node formed from this interface identifier. That is, 1039 for each on-link prefix on the home link, the home agent uses 1040 the interface identifier to form other valid addresses for the 1041 mobile node on the home link, and acts as a home agent also 1042 for those addresses. In addition, the home agent forms the 1043 link-local address and site-local address corresponding to 1044 this interface identifier, and defends each for purposes of 1045 Duplicate Address Detection. Details of this operation are 1046 described in Section 9.3. 1048 Sequence Number 1050 Used by the receiving node to sequence Binding Updates and by 1051 the sending node to match a returned Binding Acknowledgement 1052 with this Binding Update. Each Binding Update sent by a mobile 1053 node MUST use a Sequence Number greater than the Sequence 1054 Number value sent in the previous Binding Update (if any) to 1055 the same destination address (modulo 2**16). 1057 Lifetime 1059 32-bit unsigned integer. The number of seconds remaining 1060 before the binding must be considered expired. A value of all 1061 one bits (0xffffffff) indicates infinity. A value of zero 1062 indicates that the Binding Cache entry for the mobile node 1063 should be deleted. 1065 Care-of Address 1067 This field in the Binding Update is optional and is only 1068 present when the Care-of Address Present (C) bit is set. If 1069 present, it gives the care-of address of the mobile node for 1070 this binding. For most Binding Updates sent, it is expected 1071 that this field will not be present, and instead that the 1072 care-of address for the binding will be given by the Source 1073 Address field in the packet's IPv6 header. 1075 Sub-Options 1077 Additional information, associated with this Binding Update 1078 option, that need not be present in all Binding Updates sent. 1079 This use of sub-options also allows for future extensions to 1080 the format of the Binding Update option to be defined. The 1081 encoding and format of defined sub-options are described in 1082 Section 5.5. The following sub-options are valid in a Binding 1083 Update option: 1085 - Unique Identifier Sub-Option 1087 Any packet that includes a Binding Update option MUST also include 1088 a Home Address option. The home address of the mobile node in the 1089 binding given in the Binding Update option is indicated by the Home 1090 Address field in the Home Address option in the packet. 1092 Any packet that includes a Binding Update option MUST also include 1093 either an AH [9] or ESP [10] header providing sender authentication, 1094 data integrity protection, and replay protection. 1096 If the care-of address in the binding (either the Care-of Address 1097 field in the Binding Update option or the Source Address field in 1098 the packet's IPv6 header) is equal to the home address of the mobile 1099 node, the Binding Update option indicates that any existing binding 1100 for the mobile node MUST be deleted. Likewise, if the Lifetime 1101 field in the Binding Update option is equal to 0, the Binding Update 1102 option indicates that any existing binding for the mobile node MUST 1103 be deleted. In each of these cases, a Binding Cache entry for the 1104 mobile node MUST NOT be created in response to receiving the Binding 1105 Update. 1107 The last Sequence Number value sent to a destination in a Binding 1108 Update is stored by the mobile node in its Binding Update List entry 1109 for that destination; the last Sequence Number value received from 1110 a mobile node in a Binding Update is stored by a correspondent node 1111 in its Binding Cache entry for that mobile node. Thus, the mobile 1112 node's and the correspondent node's knowledge of the last sequence 1113 number expire at the same time. If the sending mobile node has no 1114 Binding Update List entry, the Sequence Number may start at any 1115 value; if the receiving correspondent node has no Binding Cache entry 1116 for the sending mobile node, it MUST accept any Sequence Number value 1117 in a received Binding Update from this mobile node. 1119 The three highest-order bits of the Option Type are encoded to 1120 indicate specific processing of the option [5]. For the Binding 1121 Update option, these three bits are set to 110, indicating that any 1122 IPv6 node processing this option that does not recognize the Option 1123 Type must discard the packet and, only if the packet's Destination 1124 Address was not a multicast address, return an ICMP Parameter 1125 Problem, Code 2, message to the packet's Source Address; and that the 1126 data within the option cannot change en-route to the packet's final 1127 destination. 1129 5.2. Binding Acknowledgement Option Format 1131 The Binding Acknowledgement destination option is used to acknowledge 1132 receipt of a Binding Update option (Section 5.1). When a node 1133 receives a packet containing a Binding Update option, with this 1134 node being the destination of the packet (only the destination node 1135 processes the option since it is a destination option), this node 1136 MUST return a Binding Acknowledgement to the source of the packet, 1137 if the Acknowledge (A) bit is set in the Binding Update. As a 1138 destination option, this node MAY include the Binding Acknowledgement 1139 in any existing packet being sent to the mobile node or MAY send it 1140 in a packet by itself. A packet containing a Binding Acknowledgement 1141 is sent in the same way as any packet to a mobile node, using a 1142 Routing header to route the packet to the mobile node by way of the 1143 care-of address in the binding (Section 8.9). 1145 The Binding Acknowledgement option is encoded in type-length-value 1146 (TLV) format as follows: 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+ 1151 | Option Type | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Option Length | Status | Sequence Number | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Lifetime | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Refresh | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Sub-Options... 1160 +-+-+-+-+-+-+-+-+-+-+-+- 1162 Option Type 1164 7 1166 Option Length 1168 8-bit unsigned integer. Length of the option, in octets, 1169 excluding the Option Type and Option Length fields. This field 1170 MUST be set to 11 plus the total length of all sub-options 1171 present, including their Sub-Option Type and Sub-Option Len 1172 fields. 1174 Status 1176 8-bit unsigned integer indicating the disposition of the 1177 Binding Update. Values of the Status field less than 128 1178 indicate that the Binding Update was accepted by the receiving 1179 node. The following such Status values are currently defined: 1181 0 Binding Update accepted 1183 Values of the Status field greater than or equal to 128 1184 indicate that the Binding Update was rejected by the receiving 1185 node. The following such Status values are currently defined: 1187 128 Reason unspecified 1188 129 Poorly formed Binding Update 1189 130 Administratively prohibited 1190 131 Insufficient resources 1191 132 Home registration not supported 1192 133 Not home subnet 1193 134 Sequence Number field value too small 1194 135 Dynamic home agent address discovery response 1195 136 Incorrect interface identifier length 1196 137 Not home agent for this mobile node 1198 Up-to-date values of the Status field are to be specified in 1199 the most recent "Assigned Numbers" [22]. 1201 Sequence Number 1203 The Sequence Number in the Binding Acknowledgement is copied 1204 from the Sequence Number field in the Binding Update being 1205 acknowledged, for use by the mobile node in matching this 1206 Acknowledgement with an outstanding Binding Update. 1208 Lifetime 1210 The granted lifetime for which this node will attempt to retain 1211 the entry for this mobile node in its Binding Cache. If the 1212 node sending the Binding Acknowledgement is serving as the 1213 mobile node's home agent, the Lifetime period also indicates 1214 the period for which this node will continue this service; if 1215 the mobile node requires home agent service from this node 1216 beyond this period, the mobile node MUST send a new Binding 1217 Update to it before the expiration of this period (even if 1218 it is not changing its primary care-of address), in order to 1219 extend the lifetime. The value of this field is undefined 1220 if the Status field indicates that the Binding Update was 1221 rejected. 1223 Refresh 1225 The recommended interval at which the mobile node SHOULD send 1226 a new Binding Update to this node in order to "refresh" the 1227 mobile node's binding in this node's Binding Cache. This 1228 refreshing of the binding is useful in case the node fails and 1229 loses its cache state. The Refresh period is determined by 1230 the node sending the Binding Acknowledgement (the node caching 1231 the binding). If this node is serving as the mobile node's 1232 home agent, the Refresh value may be set, for example, based on 1233 whether the node stores its Binding Cache in volatile storage 1234 or in nonvolatile storage. If the node sending the Binding 1235 Acknowledgement is not serving as the mobile node's home agent, 1236 the Refresh period SHOULD be set equal to the Lifetime period 1237 in the Binding Acknowledgement; even if this node loses this 1238 cache entry due to a failure of the node, packets from it can 1239 still reach the mobile node through the mobile node's home 1240 agent, causing a new Binding Update to this node to allow it 1241 to recreate this cache entry. The value of this field is 1242 undefined if the Status field indicates that the Binding Update 1243 was rejected. 1245 Sub-Options 1247 Additional information, associated with this Binding 1248 Acknowledgement option, that need not be present in all Binding 1249 Acknowledgements sent. This use of sub-options also allows for 1250 future extensions to the format of the Binding Acknowledgement 1251 option to be defined. The encoding and format of defined 1252 sub-options are described in Section 5.5. The following 1253 sub-options are valid in a Binding Acknowledgement option: 1255 - Home Agents List Sub-Option 1257 Any packet that includes a Binding Acknowledgement option MUST 1258 also include either an AH [9] or ESP [10] header providing sender 1259 authentication, data integrity protection, and replay protection. 1261 If the node returning the Binding Acknowledgement accepted the 1262 Binding Update for which the Acknowledgement is being returned (the 1263 value of the Status field in the Acknowledgement is less than 128), 1264 this node will have an entry for the mobile node in its Binding Cache 1265 and MUST use this entry (which includes the care-of address received 1266 in the Binding Update) in sending the packet containing the Binding 1267 Acknowledgement to the mobile node. The details of sending this 1268 packet to the mobile node are the same as for sending any packet to a 1269 mobile node using a binding, and are described in Section 8.9. The 1270 packet is sent using a Routing header, routing the packet to the 1271 mobile node by way of its care-of address recorded in the Binding 1272 Cache entry. 1274 If the node returning the Binding Acknowledgement instead 1275 rejected the Binding Update (the value of the Status field in the 1276 Acknowledgement is greater than or equal to 128), this node MUST 1277 similarly use a Routing header in sending the packet containing the 1278 Binding Acknowledgement, as described in Section 8.9, but MUST NOT 1279 use its Binding Cache in forming the IP header or Routing header 1280 in this packet. Rather, the care-of address used by this node in 1281 sending the packet containing the Binding Acknowledgement MUST be 1282 copied from the care-of address received in the rejected Binding 1283 Update; this node MUST NOT modify its Binding Cache in response 1284 to receiving this rejected Binding Update and MUST ignore its 1285 Binding Cache in sending the packet in which it returns this Binding 1286 Acknowledgement. The packet is sent using a Routing header, routing 1287 the packet to the home address of the rejected Binding Update by 1288 way of the care-of address indicated in the packet containing the 1289 Binding Update. When sending a Binding Acknowledgement to reject a 1290 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 1291 packet containing no payload (with the Next Header field in the last 1292 extension header in the packet set to indicate "No Next Header" [5]). 1294 The three highest-order bits of the Option Type are encoded to 1295 indicate specific processing of the option [5]. For the Binding 1296 Acknowledgement option, these three bits are set to 000, indicating 1297 that any IPv6 node processing this option that does not recognize the 1298 Option Type must skip over this option and continue processing the 1299 header, and that the data within the option cannot change en-route to 1300 the packet's final destination. 1302 5.3. Binding Request Option Format 1304 The Binding Request destination option is used to request a mobile 1305 node's binding from the mobile node. As a destination option, it 1306 MAY be included in any existing packet being sent to the mobile 1307 node or MAY be sent in a packet by itself; a packet containing a 1308 Binding Request option is sent in the same way as any packet to a 1309 mobile node (Section 8.9). When a mobile node receives a packet 1310 containing a Binding Request option, it SHOULD return a Binding 1311 Update (Section 5.1) to the source of the Binding Request. 1313 The Binding Request option is encoded in type-length-value (TLV) 1314 format as follows: 1316 0 1 1317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1319 | Option Type | Option Length | Sub-Options... 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1322 Option Type 1324 8 1326 Option Length 1328 8-bit unsigned integer. Length of the option, in octets, 1329 excluding the Option Type and Option Length fields. This field 1330 MUST be set to 0 plus the total length of all sub-options 1331 present, including their Sub-Option Type and Sub-Option Len 1332 fields. 1334 Sub-Options 1336 Additional information, associated with this Binding Request 1337 option, that need not be present in all Binding Requests sent. 1338 This use of sub-options also allows for future extensions to 1339 the format of the Binding Request option to be defined. The 1340 encoding and format of defined sub-options are described in 1341 Section 5.5. The following sub-options are valid in a Binding 1342 Request option: 1344 - Unique Identifier Sub-Option 1346 The three highest-order bits of the Option Type are encoded to 1347 indicate specific processing of the option [5]. For the Binding 1348 Request option, these three bits are set to 000, indicating that any 1349 IPv6 node processing this option that does not recognize the Option 1350 Type must skip over this option and continue processing the header, 1351 and that the data within the option cannot change en-route to the 1352 packet's final destination. 1354 5.4. Home Address Option Format 1356 The Home Address destination option is used in a packet sent by a 1357 mobile node while away from home, to inform the recipient of that 1358 packet of the mobile node's home address. For packets sent by a 1359 mobile node while away from home, the mobile node generally uses 1360 one of its care-of addresses as the Source Address in the packet's 1361 IPv6 header. By including a Home Address option in the packet, the 1362 correspondent node receiving the packet is able to substitute the 1363 mobile node's home address for this care-of address when processing 1364 the packet, thus making the use of the care-of address transparent to 1365 the correspondent node. 1367 The Home Address option is encoded in type-length-value (TLV) format 1368 as follows: 1370 0 1 2 3 1371 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 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Option Type | Option Length | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | | 1376 + + 1377 | | 1378 + Home Address + 1379 | | 1380 + + 1381 | | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Sub-Options... 1384 +-+-+-+-+-+-+-+-+-+-+-+- 1386 Option Type 1388 201 = 0xC9 1390 Option Length 1392 8-bit unsigned integer. Length of the option, in octets, 1393 excluding the Option Type and Option Length fields. This field 1394 MUST be set to 16 plus the total length of all sub-options 1395 present, including their Sub-Option Type and Sub-Option Len 1396 fields. 1398 Home Address 1400 The home address of the mobile node sending the packet. 1402 Sub-Options 1404 Additional information, associated with this Home Address 1405 option, that need not be present in all Home Address options 1406 sent. This use of sub-options also allows for future 1407 extensions to the format of the Home Address option to be 1408 defined. The encoding and format of defined sub-options are 1409 described in Section 5.5. Currently, no valid sub-options are 1410 defined for use in a Home Address option. 1412 The inclusion of a Home Address option in a packet affects the 1413 receiving node's processing of only this single packet; no state is 1414 created or modified in the receiving node as a result of receiving a 1415 Home Address option in a packet. In particular, the presence of a 1416 Home Address option in a received packet MUST NOT alter the contents 1417 of the receiver's Binding Cache and MUST NOT cause any changes in the 1418 routing of subsequent packets sent by this receiving node. 1420 No authentication of the Home Address option is required, except that 1421 if the IPv6 header of a packet is covered by authentication, then 1422 that authentication MUST also cover the Home Address option; this 1423 coverage is achieved automatically by the definition of the Option 1424 Type code for the Home Address option, since it indicates that the 1425 data within the option cannot change en-route to the packet's final 1426 destination, and thus the option is included in the authentication 1427 computation. If the packet carries no IP authentication, then the 1428 contents of the Home Address option, as well as the Source Address 1429 field or any other field in the IPv6 header, may have been forged or 1430 altered during transit. 1432 Upon receipt of a packet containing a Home Address option, the 1433 receiving node replaces the Source Address in the IPv6 header with 1434 the Home Address in the Home Address option. By requiring that any 1435 authentication of the IPv6 header also cover the Home Address option, 1436 the security of the Source Address field in the IPv6 header is not 1437 compromised by the presence of a Home Address option. Security 1438 issues related to the Home Address option are discussed further in 1439 Section 13. 1441 The three highest-order bits of the Option Type are encoded to 1442 indicate specific processing of the option [5]. For the Home Address 1443 option, these three bits are set to 110, indicating that any IPv6 1444 node processing this option that does not recognize the Option Type 1445 must discard the packet and, only if the packet's Destination Address 1446 was not a multicast address, return an ICMP Parameter Problem, 1447 Code 2, message to the packet's Source Address; and that the data 1448 within the option cannot change en-route to the packet's final 1449 destination. 1451 5.5. Mobile IPv6 Destination Option Sub-Options 1453 In order to allow optional fields that may not be needed in most uses 1454 of any given Mobile IPv6 destination option, and to allow future 1455 extensions to the format of these destination options to be defined, 1456 any of the Mobile IPv6 destination options defined in this document 1457 MAY include one or more sub-options. 1459 Such sub-options are included in the data portion of the destination 1460 option itself, after the fixed portion of the option data specified 1461 for that particular destination option (Sections 5.1 through 5.4). 1462 The presence of such sub-options will be indicated by the Option 1463 Length field. When the Option Length is greater than the standard 1464 length defined for that destination option, the remaining octets are 1465 interpreted as sub-options. 1467 These sub-options are encoded within the remaining space of the 1468 option data for that option, using a type-length-value (TLV) format 1469 as follows: 1471 0 1 2 3 1472 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 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 |Sub-Option Type| Sub-Option Len| Sub-Option Data... 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 Sub-Option Type 1479 8-bit identifier of the type of sub-option. In processing a 1480 Mobile IPv6 destination option containing a sub-option for 1481 which the Sub-Option Type value is not recognized by the 1482 receiver, the receiver SHOULD quietly ignore and skip over the 1483 sub-option, correctly handling any remaining sub-options in the 1484 option. 1486 Sub-Option Length 1488 8-bit unsigned integer. Length of the Sub-Option Data field 1489 of this sub-option, in octets. The Sub-Option Len does not 1490 include the length of the Sub-Option Type and Sub-Option Len 1491 fields. 1493 Sub-Option Data 1495 Variable-length field. Sub-Option-Type-specific data. 1497 Each section above defining the Mobile IPv6 destination options 1498 specifies which of the defined sub-options is valid for that 1499 destination option. 1501 Currently, the following two sub-option types are defined for use in 1502 Mobile IPv6 destination options: 1504 Unique Identifier Sub-Option 1506 This sub-option is valid only in Binding Request and Binding 1507 Update destination options. The Sub-Option Data contains a 1508 single 16-bit value that serves to uniquely identify a Binding 1509 Request among those sent by this Source Address, and to allow 1510 the Binding Update to identify the specific Binding Request to 1511 which it responds. This matching of Binding Updates to Binding 1512 Requests is required in the procedure for renumbering the home 1513 subnet while a mobile node is away from home (Section 9.7). 1514 The Sub-Option Type and Sub-Option Len fields for this 1515 sub-option MUST be set as follows: 1517 - Sub-Option Type: 1 1519 - Sub-Option Len: 2 1521 Home Agents List Sub-Option 1523 This sub-option is valid only in a Binding Acknowledgement 1524 destination option. The Sub-Option Data contains a list of 1525 home agents on the home link for the mobile node to which 1526 this Binding Acknowledgement is sent. This sub-option MUST 1527 NOT be present unless the Binding Acknowledgement is sent 1528 in response to a "Mobile IPv6 Home-Agents" anycast Binding 1529 Update sent by a mobile node attempting dynamic home agent 1530 address discovery [8]. In this case, the Status field in the 1531 Binding Acknowledgement MUST be set to 135 (dynamic home agent 1532 address discovery response). The specific construction of 1533 the Sub-Option Data field for this sub-option is defined in 1534 Section 9.2. The Sub-Option Type and Sub-Option Len fields for 1535 this sub-option MUST be set as follows: 1537 - Sub-Option Type: 2 1539 - Sub-Option Len: 16 * N, where N is the number of home 1540 agent addresses included in the Sub-Option Data. 1542 6. Modifications to IPv6 Neighbor Discovery 1544 6.1. Modified Router Advertisement Message Format 1546 Mobile IPv6 modifies the format of the Router Advertisement 1547 message [14] by the addition of a single flag bit for use in the 1548 dynamic home agent address discovery mechanism (Sections 9.2 1549 and 10.6). The format of the Router Advertisement message is 1550 as follows: 1552 0 1 2 3 1553 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 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Type | Code | Checksum | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Reachable Time | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | Retrans Timer | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Options ... 1564 +-+-+-+-+-+-+-+-+-+-+-+- 1566 This format represents the following changes over that originally 1567 specified for Neighbor Discovery [14]: 1569 Home Agent (H) 1571 The Home Agent (H) bit is set in a Router Advertisement to 1572 indicate that the router sending this Router Advertisement is 1573 also functioning as a Mobile IP home agent. 1575 Reserved 1577 Reduced from a 6-bit field to a 5-bit field to account for the 1578 addition of the Home Agent (H) bit. 1580 6.2. Modified Prefix Information Option Format 1582 Mobile IPv6 requires knowledge of a router's global address for two 1583 reasons: 1585 - To allow a home agent (a router) to learn the address of all 1586 other home agents on the link for which it is providing home 1587 agent service, for use in building its Home Agents List as 1588 part of the dynamic home agent address discovery mechanism 1589 (Sections 9.2 and 10.6). 1591 - To allow a mobile node to send a Binding Update to its previous 1592 default router, after moving to a new subnet and acquiring a new 1593 care-of address (Section 10.8). 1595 However, Neighbor Discovery [14] only advertises a router's 1596 link-local address, by requiring this address to be used as the IP 1597 Source Address of each Router Advertisement. 1599 Mobile IPv6 extends Neighbor Discovery to allow a router to easily 1600 and efficiently advertise its global address, by the addition of a 1601 single flag bit in the format of a Prefix Information option for 1602 use in Router Advertisement messages. The format of the Prefix 1603 Information option is as follows: 1605 0 1 2 3 1606 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 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | Type | Length | Prefix Length |L|A|R|Reserved1| 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | Valid Lifetime | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | Preferred Lifetime | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Reserved2 | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | | 1617 + + 1618 | | 1619 + Prefix + 1620 | | 1621 + + 1622 | | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 This format represents the following changes over that originally 1626 specified for Neighbor Discovery [14]: 1628 Router Address (R) 1630 1-bit router address flag. When set, indicates that the 1631 Prefix field, in addition to advertising the indicated prefix, 1632 contains a complete IP address assigned to the sending router. 1633 This router IP address has the same scope and conforms to the 1634 same lifetime values as the advertised prefix. This use of 1635 the Prefix field is compatible with its use in advertising 1636 the prefix itself, since prefix advertisement uses only the 1637 leading number Prefix bits specified by the Prefix Length 1638 field. Interpretation of this flag bit is thus independent 1639 of the processing required for the On-Link (L) and Autonomous 1640 Address-Configuration (A) flag bits. 1642 Reserved1 1644 Reduced from a 6-bit field to a 5-bit field to account for the 1645 addition of the Router Address (R) bit. 1647 In a solicited Router Advertisement, a router MUST include at least 1648 one Prefix Information option with the Router Address (R) bit set. 1649 Neighbor Discovery specifies that, if including all options in a 1650 Router Advertisement causes the size of the Advertisement to exceed 1651 the link MTU, multiple Advertisements can be sent, each containing 1652 a subset of the options [14]. In this case, at least one of these 1653 multiple Advertisements being sent instead of a single larger 1654 solicited Advertisement, MUST include a Prefix Information option 1655 with the Router Address (R) bit set. 1657 All routers SHOULD include at least on Prefix Information option with 1658 the Router Address (R) bit set, in each unsolicited multicast Router 1659 Advertisement that they send. If multiple Advertisements are being 1660 sent instead of a single larger unsolicited multicast Advertisement, 1661 at least one of these multiple Advertisements SHOULD include a Prefix 1662 Information option with the Router Address (R) bit set. 1664 6.3. New Advertisement Interval Option Format 1666 Mobile IPv6 defines a new Advertisement Interval option, used in 1667 Router Advertisement messages to advertise the interval at which the 1668 sending router sends unsolicited multicast Router Advertisements. 1669 The format of the Advertisement Interval option is as follows: 1671 0 1 2 3 1672 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 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Type | Length | Reserved | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Advertisement Interval | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 Type 1681 7 1683 Length 1685 8-bit unsigned integer. The length of the option (including 1686 the type and length fields) in units of 8 octets. The value of 1687 this field MUST be 1. 1689 Reserved 1691 This field is unused. It MUST be initialized to zero by the 1692 sender and MUST be ignored by the receiver. 1694 Advertisement Interval 1696 32-bit unsigned integer. The maximum time, in milliseconds, 1697 between successive unsolicited router Router Advertisement 1698 messages sent by this router on this network interface. Using 1699 the conceptual router configuration variables defined by 1700 Neighbor Discovery [14], this field MUST be equal to the value 1701 MaxRtrAdvInterval, expressed in milliseconds. 1703 Routers MAY include this option in their Router Advertisements. A 1704 mobile node receiving a Router Advertisement containing this option 1705 SHOULD utilize the specified Advertisement Interval for that router 1706 in its movement detection algorithm, as described in Section 10.3. 1708 This option MUST be silently ignored for other Neighbor Discovery 1709 messages. 1711 6.4. New Home Agent Information Option Format 1713 Mobile IPv6 defines a new Home Agent Information option, used in 1714 Router Advertisement messages sent by a home agent to advertise 1715 information specific to this router's functionality as a home agent. 1716 The format of the Home Agent Information option is as follows: 1718 0 1 2 3 1719 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 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | Type | Length | Reserved | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | Home Agent Preference | Home Agent Lifetime | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 Type 1728 8 1730 Length 1732 8-bit unsigned integer. The length of the option (including 1733 the type and length fields) in units of 8 octets. The value of 1734 this field MUST be 1. 1736 Reserved 1738 This field is unused. It MUST be initialized to zero by the 1739 sender and MUST be ignored by the receiver. 1741 Home Agent Preference 1743 16-bit signed, twos-complement integer. The preference for 1744 the home agent sending this Router Advertisement, for use 1745 in ordering the addresses contained in the Home Agents List 1746 Sub-Option returned in a Binding Acknowledgement; higher values 1747 mean more preferable. If this option is not included in a 1748 Router Advertisement in which the Home Agent (H) bit is set, 1749 the preference value for this home agent SHOULD be considered 1750 to be 0. Values greater than 0 indicate a home agent more 1751 preferable than this default value, and values less than 0 1752 indicate a less preferable home agent. In addition to the 1753 manual configuration of the Home Agent Preference value as 1754 described in Section 7.3, the Home Agent Preference sent by 1755 a home agent could, for example, be set dynamically by the 1756 sending home agent based on the number of mobile nodes it is 1757 currently serving or on its remaining resources for serving 1758 additional mobile nodes, but such dynamic settings are beyond 1759 the scope of this document. 1761 Home Agent Lifetime 1763 16-bit unsigned integer. The lifetime associated with the home 1764 agent in units of seconds. The maximum value corresponds to 1765 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 1766 Lifetime applies only to this router's usefulness as a home 1767 agent; it does not apply to information contained in other 1768 message fields or options. If this option is not included in 1769 a Router Advertisement in which the Home Agent (H) bit is set, 1770 the lifetime for this home agent SHOULD be considered to be the 1771 same as the Router Lifetime specified in the main body of the 1772 Router Advertisement message. 1774 Home agents MAY include this option in their Router Advertisements. 1775 This option MUST NOT be included in a Router Advertisement in which 1776 the Home Agent (H) bit (Section 6.1) is not set. 1778 This option MUST be silently ignored for other Neighbor Discovery 1779 messages. 1781 If both the Home Agent Preference and Home Agent Lifetime are set 1782 to their default values specified above, this option SHOULD NOT be 1783 included in the Router Advertisement messages sent by this home 1784 agent. 1786 6.5. Changes to Sending Router Advertisements 1788 The Neighbor Discovery protocol specification [14] limits routers to 1789 a minimum interval of 3 seconds between sending unsolicited multicast 1790 Router Advertisement messages from any given network interface 1791 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 1793 "Routers generate Router Advertisements frequently enough 1794 that hosts will learn of their presence within a few 1795 minutes, but not frequently enough to rely on an absence 1796 of advertisements to detect router failure; a separate 1797 Neighbor Unreachability Detection algorithm provides failure 1798 detection." 1800 This limitation, however, is not suitable to providing timely 1801 movement detection for mobile nodes. Mobile nodes detect their 1802 own movement by learning the presence of new routers as the mobile 1803 node moves into wireless transmission range of them (or physically 1804 connects to a new wired network), and by learning that previous 1805 routers are no longer reachable. Mobile nodes MUST be able to 1806 quickly detect when they move to a link served by a new router, so 1807 that they can acquire a new care-of address and send Binding Updates 1808 to register this care-of address with their home agent and to notify 1809 correspondent nodes as needed. 1811 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 1812 this limit such that routers MAY send unsolicited multicast Router 1813 Advertisements more frequently. In particular, on network interfaces 1814 where the router is expecting to provide service to visiting mobile 1815 nodes (e.g., wireless network interfaces), or on which it is serving 1816 as a home agent to one or more mobile nodes (who may return home and 1817 need to hear its Advertisements), the home agent SHOULD be configured 1818 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 1819 to allow sending of unsolicited multicast Router Advertisements more 1820 often. Recommended values for these limits are: 1822 - MinRtrAdvInterval 0.5 seconds 1824 - MaxRtrAdvInterval 1.5 seconds 1826 Use of these modified limits MUST be configurable, and specific 1827 knowledge of the type of network interface in use SHOULD be taken 1828 into account in configuring these limits for each network interface. 1830 When sending unsolicited multicast Router Advertisements more 1831 frequently than the standard limit on unsolicited multicast 1832 Advertisement frequency, the sending router need not include all 1833 options in each of these Advertisements, but it SHOULD include at 1834 least one Prefix Information option with the Router Address (R) bit 1835 set (Section 6.2) in each. 1837 6.6. Changes to Sending Router Solicitations 1839 In addition to the limit on routers sending unsolicited multicast 1840 Router Advertisement messages (Section 6.5), Neighbor Discovery 1841 defines limits on nodes sending Router Solicitation messages, such 1842 that a node SHOULD send no more than 3 Router Solicitations, and that 1843 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 1844 However, these limits prevent a mobile node from finding a new 1845 default router (and thus a new care-of address) quickly as it moves 1846 about. 1848 Mobile IPv6 relaxes this limit such that, while a mobile node is away 1849 from home, it MAY send Router Solicitations more frequently. The 1850 following limits for sending Router Solicitations are recommended for 1851 mobile nodes while away from home: 1853 - A mobile node that is not configured with any current care-of 1854 address (e.g., the mobile node has moved since its previous 1855 care-of address was configured), MAY send more than the defined 1856 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 1857 Solicitations. 1859 - The rate at which a mobile node sends Router Solicitations MUST 1860 be limited, although a mobile node MAY send Router Solicitations 1861 more frequently than the defined Neighbor Discovery limit of 1862 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 1863 be configurable, and specific knowledge of the type of network 1864 interface in use SHOULD be taken into account in configuring this 1865 limit for each network interface. A recommended minimum interval 1866 is 1 second. 1868 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 1869 a mobile node MUST reduce the rate at which it sends subsequent 1870 Router Solicitations. Subsequent Router Solicitations SHOULD 1871 be sent using a binary exponential backoff mechanism, doubling 1872 the interval between consecutive Router Solicitations, up to a 1873 maximum interval. The maximum interval MUST be configurable and 1874 SHOULD be chosen appropriately based on the characteristics of 1875 the type of network interface in use. 1877 - While still searching for a new default router and care-of 1878 address, a mobile node MUST NOT increase the rate at which it 1879 sends Router Solicitations unless it has received a positive 1880 indication (such as from lower network layers) that it has moved 1881 to a new link. After successfully acquiring a new care-of 1882 address, the mobile node SHOULD also increase the rate at which 1883 it will send Router Solicitations when it next begins searching 1884 for a new default router and care-of address. 1886 - A mobile node that is currently configured with a care-of 1887 address SHOULD NOT send Router Solicitations, until its movement 1888 detection algorithm (Section 10.3) determines that it has moved 1889 and that its current care-of address might no longer be valid. 1891 7. Requirements for IPv6 Nodes 1893 Mobile IPv6 places some special requirements on the functions 1894 provided by different types of IPv6 nodes. This section summarizes 1895 those requirements, identifying the functionality each requirement 1896 is intended to support. Further details on this functionality is 1897 provided in the following sections. 1899 7.1. Requirements for All IPv6 Hosts and Routers 1901 Since any IPv6 node may at any time be a correspondent node of a 1902 mobile node, either sending a packet to a mobile node or receiving a 1903 packet from a mobile node, the following requirements apply to ALL 1904 IPv6 nodes (whether host or router, whether mobile or stationary): 1906 - Every IPv6 node MUST be able to process a Home Address option 1907 received in any IPv6 packet. 1909 - Every IPv6 node SHOULD be able to process a Binding Update option 1910 received in a packet, and to return a Binding Acknowledgement 1911 option if the Acknowledge (A) bit is set in the received Binding 1912 Update. 1914 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 1915 bindings received in accepted Binding Updates. 1917 7.2. Requirements for All IPv6 Routers 1919 The following requirements apply to all IPv6 routers, even those not 1920 serving as a home agent for Mobile IPv6: 1922 - Every IPv6 router SHOULD be able to send an Advertisement 1923 Interval option in its Router Advertisements, to aid movement 1924 detection by mobile nodes. The use of this option in Router 1925 Advertisements MUST be configurable. 1927 - Every IPv6 router SHOULD be able to support sending unsolicited 1928 multicast Router Advertisements at the faster rate described in 1929 Section 6.5. The use of this faster rate MUST be configurable. 1931 7.3. Requirements for IPv6 Home Agents 1933 In order for a mobile node to operate correctly while away from home, 1934 at least one IPv6 router on the mobile node's home link must function 1935 as a home agent for the mobile node. The following additional 1936 requirements apply to all IPv6 routers capable of serving as a home 1937 agent: 1939 - Every home agent MUST be able to maintain an entry in its Binding 1940 Cache for each mobile node for which it is serving as the home 1941 agent. Each such Binding Cache entry records the mobile node's 1942 binding with its primary care-of address and is marked as a "home 1943 registration". 1945 - Every home agent MUST be able to intercept packets (using proxy 1946 Neighbor Discovery) addressed to a mobile node for which it is 1947 currently serving as the home agent, on that mobile node's home 1948 link, while the mobile node is away from home. 1950 - Every home agent MUST be able to encapsulate such intercepted 1951 packets in order to tunnel them to the primary care-of address 1952 for the mobile node indicated in its binding in the home agent's 1953 Binding Cache. 1955 - Every home agent MUST be able to return a Binding Acknowledgement 1956 option in response to a Binding Update option received with the 1957 Acknowledge (A) bit set. 1959 - Every home agent MUST be able to accept packets addressed 1960 to the "Mobile IPv6 Home-Agents" anycast address for the 1961 subnet on which it is serving as a home agent [8], and MUST be 1962 able to participate in dynamic home agent address discovery 1963 (Section 9.2). 1965 - Every home agent SHOULD support a configuration mechanism to 1966 allow a system administrator to manually set the value to be sent 1967 by this home agent in the Home Agent Preference field of the Home 1968 Agent Information Option in Router Advertisements that it sends. 1970 7.4. Requirements for IPv6 Mobile Nodes 1972 Finally, the following requirements apply to all IPv6 nodes capable 1973 of functioning as mobile nodes: 1975 - Every IPv6 mobile node MUST be able to perform IPv6 1976 decapsulation [4]. 1978 - Every IPv6 mobile node MUST support sending Binding Update 1979 options, as specified in Sections 10.5, 10.7, and 10.8; and MUST 1980 be able to receive and process Binding Acknowledgement options, 1981 as specified in Section 10.11. 1983 - Every IPv6 mobile node MUST support use of the dynamic home agent 1984 address discovery mechanism, as described in Section 10.6. 1986 - Every IPv6 mobile node MUST maintain a Binding Update List in 1987 which it records the IP address of each other node to which it 1988 has sent a Binding Update, for which the Lifetime sent in that 1989 binding has not yet expired. 1991 - Every IPv6 mobile node MUST support receiving a Binding Request 1992 option, by responding with a Binding Update option. 1994 - Every IPv6 mobile node MUST support sending packets containing a 1995 Home Address option; this option MUST be included in all packets 1996 sent while away from home, if the packet would otherwise have 1997 been sent with the mobile node's home address as the IP Source 1998 Address. 2000 8. Correspondent Node Operation 2002 A correspondent node is any node communicating with a mobile node. 2003 The correspondent node, itself, may be stationary or mobile, and may 2004 possibly also be functioning as a home agent for Mobile IPv6. The 2005 procedures in this section thus apply to all IPv6 nodes. 2007 8.1. Receiving Packets from a Mobile Node 2009 Packets sent by a mobile node while away from home generally include 2010 a Home Address option. When any node receives a packet containing 2011 a Home Address option, it MUST process the option in a manner 2012 consistent with copying the Home Address field from the Home Address 2013 option into the IPv6 header, replacing the original value of the 2014 Source Address field there. However, any actual modifications to 2015 the Source Address field in the packet's IPv6 header MUST not be 2016 performed until after all processing of other options contained in 2017 this same Destination Options extension header is completed. 2019 Further processing of such a packet after option processing (e.g., 2020 at the transport layer) thus need not know that the original Source 2021 Address was a care-of address, or that the Home Address option was 2022 used in the packet. Since the sending mobile node uses its home 2023 address at the transport layer when sending such a packet, the use of 2024 the care-of address and Home Address option is transparent to both 2025 the mobile node and the correspondent node above the level of the 2026 Home Address option generation and processing. 2028 8.2. Receiving Binding Updates 2030 Upon receiving a Binding Update option in some packet, the receiving 2031 node MUST validate the Binding Update according to the following 2032 tests: 2034 - The packet contains a valid AH [9] or ESP [10] header that 2035 provides sender authentication, integrity protection, and replay 2036 protection. 2038 - The packet MUST contain a valid Home Address option. The home 2039 address for the binding is specified by the Home Address field of 2040 the Home Address option. 2042 - The Option Length field in the Binding Update option is greater 2043 than or equal to the length specified in Section 5.1. 2045 - The Sequence Number field in the Binding Update option is greater 2046 than the Sequence Number received in the previous Binding Update 2047 for this home address, if any. The Sequence Number comparison is 2048 performed modulo 2**16. 2050 Any Binding Update not satisfying all of these tests MUST be 2051 silently ignored, and the packet carrying the Binding Update MUST be 2052 discarded. 2054 If the Binding Update is valid according to the tests above, then the 2055 Binding Update is processed further as follows: 2057 - If the Destination Address in the packet's IPv6 header is the 2058 "Mobile IPv6 Home-Agents" anycast address [8] for an on-link 2059 prefix and this address is assigned to one of this node's network 2060 interfaces, then the mobile node sending this Binding Update is 2061 attempting dynamic home agent address discovery. Processing for 2062 this type of received Binding Update is described in Section 9.2. 2063 (If the Destination Address is not assigned to one of this node's 2064 network interfaces, then the packet would have been forwarded as 2065 a normal packet and the Binding Update, as a destination option, 2066 would not be processed in any way by this node.) 2068 - If the Lifetime specified in the Binding Update is nonzero and 2069 the specified Care-of Address is not equal to the home address 2070 for the binding (as given in the Home Address option in the 2071 packet), then this is a request to cache a binding for the 2072 mobile node. If the Home Registration (H) bit is set in the 2073 Binding Update, the Binding Update is processed according to the 2074 procedure specified in Section 9.3; otherwise, it is processed 2075 according to the procedure specified in Section 8.3. 2077 - If the Lifetime specified in the Binding Update is zero or the 2078 specified Care-of Address matches the home address for the 2079 binding, then this is a request to delete the mobile node's 2080 cached binding. If the Home Registration (H) bit is set in the 2081 Binding Update, the Binding Update is processed according to the 2082 procedure specified in Section 9.4; otherwise, it is processed 2083 according to the procedure specified in Section 8.4. 2085 8.3. Requests to Cache a Binding 2087 When a node receives a Binding Update, it MUST validate it and 2088 determine the type of Binding Update according to the steps described 2089 in Section 8.2. This section describes the processing of a valid 2090 Binding Update that requests a node to cache a mobile node's binding, 2091 for which the Home Registration (H) bit is not set in the Binding 2092 Update. 2094 In this case, the receiving node SHOULD create a new entry in its 2095 Binding Cache for this mobile node (or update its existing Binding 2096 Cache entry for this mobile node, if such an entry already exists). 2097 The home address of the mobile node is taken from the Home Address 2098 field in the packet's Home Address option. The new Binding Cache 2099 entry records the association between this home address and the 2100 care-of address for the binding, as specified in either the Care-of 2101 Address field of the Binding Update or in the Source Address field 2102 in the packet's IPv6 header. Any Binding Cache entry created or 2103 updated in response to processing this Binding Update MUST be deleted 2104 after the expiration of the Lifetime period specified in the Binding 2105 Update. 2107 8.4. Requests to Delete a Binding 2109 When a node receives a Binding Update, it MUST validate it and 2110 determine the type of Binding Update according to the steps described 2111 in Section 8.2. This section describes the processing of a valid 2112 Binding Update that requests a node to delete a mobile node's binding 2113 from its Binding Cache, for which the Home Registration (H) bit is 2114 not set in the Binding Update. 2116 In this case, the receiving node MUST delete any existing entry in 2117 its Binding Cache for this mobile node. The home address of the 2118 mobile node is taken from the Home Address field in the packet's Home 2119 Address option. 2121 8.5. Sending Binding Acknowledgements 2123 When any node receives a packet containing a Binding Update option 2124 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 2125 Acknowledgement option acknowledging receipt of the Binding Update. 2126 If the node accepts the Binding Update and creates or updates an 2127 entry in its Binding Cache for this binding, the Status field in 2128 the Binding Acknowledgement MUST be set to a value less than 128; 2129 if the node rejects the Binding Update and does not create or 2130 update an entry for this binding, the Status field in the Binding 2131 Acknowledgement MUST be set to a value greater than or equal to 128. 2132 Specific values for the Status field are described in Section 5.2 and 2133 in the most recent "Assigned Numbers" [22]. 2135 As described in Section 5.2, the packet in which the Binding 2136 Acknowledgement is returned MUST include either an AH [9] or ESP [10] 2137 header providing sender authentication, data integrity protection, 2138 and replay protection; and the packet MUST be sent using a Routing 2139 header in the same way as any other packet sent to a mobile node 2140 using a care-of address (even if the binding was rejected), as 2141 described in Section 8.9. The packet is routed first to the care-of 2142 address contained in the Binding Update being acknowledged, and 2143 then to the mobile node's home address. This use of the Routing 2144 header ensures that the Binding Acknowledgement will be routed to the 2145 current location of the node sending the Binding Update, whether the 2146 Binding Update was accepted or rejected. 2148 8.6. Sending Binding Requests 2150 Entries in a node's Binding Cache MUST be deleted when their lifetime 2151 expires. If such an entry is still in active use in sending packets 2152 to a mobile node, the next packet sent to the mobile node will be 2153 routed normally to the mobile node's home link, where it will be 2154 intercepted and tunneled to the mobile node. The mobile node will 2155 then return a Binding Update to the sender, allowing it to create 2156 a new Binding Cache entry for sending future packets to the mobile 2157 node. Communication with the mobile node continues uninterrupted, 2158 but the forwarding of this packet through the mobile node's home 2159 agent creates additional overhead and latency in delivering packets 2160 to the mobile node. 2162 If the sender knows that the Binding Cache entry is still in active 2163 use, it MAY send a Binding Request option to the mobile node in 2164 an attempt to avoid this overhead and latency due to deleting and 2165 recreating the Binding Cache entry. Since a Binding Request is a 2166 destination option, it may, for example, be included in any packet 2167 already being sent to the mobile node, such as a packet that is part 2168 of ongoing TCP communication with the mobile node. When the mobile 2169 node receives a packet from some sender containing a Binding Request 2170 option, it returns a Binding Update option to that sender, giving its 2171 current binding and a new lifetime. 2173 8.7. Cache Replacement Policy 2175 Any entry in a node's Binding Cache MUST be deleted after the 2176 expiration of the Lifetime specified in the Binding Update from 2177 which the entry was created or last updated. Conceptually, a node 2178 maintains a separate timer for each entry in its Binding Cache. When 2179 creating or updating a Binding Cache entry in response to a received 2180 and accepted Binding Update, the node sets the timer for this entry 2181 to the specified Lifetime period. When a Binding Cache entry's timer 2182 expires, the node deletes the entry. 2184 Each node's Binding Cache will, by necessity, have a finite size. 2185 A node MAY use any reasonable local policy for managing the space 2186 within its Binding Cache, except that any entry marked as a "home 2187 registration" (Section 9.3) MUST NOT be deleted from the cache until 2188 the expiration of its lifetime period. When attempting to add a 2189 new "home registration" entry in response to a Binding Update with 2190 the Home Registration (H) bit set, if insufficient space exists (or 2191 can be reclaimed) in the node's Binding Cache, the node MUST reject 2192 the Binding Update and SHOULD return a Binding Acknowledgement to 2193 the sending mobile node, in which the Status field is set to 131 2194 (insufficient resources). When otherwise attempting to add a new 2195 entry to its Binding Cache, a node MAY, if needed, choose to drop any 2196 entry already in its Binding Cache, other than a "home registration" 2197 entry, in order to make space for the new entry. For example, a 2198 "least-recently used" (LRU) strategy for cache entry replacement 2199 among entries not marked as a "home registration" is likely to work 2200 well. 2202 Any binding dropped from a node's Binding Cache due to lack of cache 2203 space will be rediscovered and a new cache entry created, if the 2204 binding is still in active use by the node for sending packets. If 2205 the node sends a packet to a destination for which it has dropped the 2206 entry from its Binding Cache, the packet will be routed normally, 2207 leading to the mobile node's home link. There, the packet will be 2208 intercepted by the mobile node's home agent and tunneled to the 2209 mobile node's current primary care-of address. As when a Binding 2210 Cache entry is initially created, this indirect routing to the mobile 2211 node through its home agent will result in the mobile node sending 2212 a Binding Update to this sending node when it receives the tunneled 2213 packet, allowing it to add an entry again for this destination mobile 2214 node to its Binding Cache. 2216 8.8. Receiving ICMP Error Messages 2218 When a correspondent node sends a packet to a mobile node, if the 2219 correspondent node has a Binding Cache entry for the destination 2220 address of the packet, then the correspondent node uses a Routing 2221 header to deliver the packet to the mobile node through the care-of 2222 address in the binding recorded in the Binding Cache entry. Any ICMP 2223 error message caused by the packet on its way to the mobile node will 2224 be returned normally to the correspondent node. 2226 On the other hand, if the correspondent node has no Binding Cache 2227 entry for the mobile node, the packet will be routed to the mobile 2228 node's home link. There, it will be intercepted by the mobile node's 2229 home agent, encapsulated, and tunneled to the mobile node's primary 2230 care-of address. Any ICMP error message caused by the packet on 2231 its way to the mobile node while in the tunnel, will be returned to 2232 the mobile node's home agent (the source of the tunnel). By the 2233 definition of IPv6 encapsulation [4], this encapsulating node MUST 2234 relay certain ICMP error messages back to the original sender of the 2235 packet, which in this case is the correspondent node. 2237 Likewise, if a packet for a mobile node arrives at the mobile node's 2238 previous default router (e.g., the mobile node moved after the packet 2239 was sent), the router will encapsulate and tunnel the packet to the 2240 mobile node's new care-of address (if it has a Binding Cache entry 2241 for the mobile node). As above, any ICMP error message caused by the 2242 packet while in this tunnel will be returned to the previous default 2243 router (the source of the tunnel), which MUST relay certain ICMP 2244 error messages back to the correspondent node [4]. 2246 Thus, in all cases, any meaningful ICMP error messages caused 2247 by packets from a correspondent node to a mobile node will be 2248 returned to the correspondent node. If the correspondent node 2249 receives persistent ICMP Destination Unreachable messages after 2250 sending packets to a mobile node based on an entry in its Binding 2251 Cache, the correspondent node SHOULD delete this Binding Cache 2252 entry. If the correspondent node subsequently transmits another 2253 packet to the mobile node, the packet will be routed to the mobile 2254 node's home link, intercepted by the mobile node's home agent, and 2255 tunneled to the mobile node's primary care-of address using IPv6 2256 encapsulation. The mobile node will then return a Binding Update to 2257 the correspondent node, allowing it to recreate a (correct) Binding 2258 Cache entry for the mobile node. 2260 8.9. Sending Packets to a Mobile Node 2262 Before sending any packet, the sending node SHOULD examine its 2263 Binding Cache for an entry for the destination address to which the 2264 packet is being sent. If the sending node has a Binding Cache entry 2265 for this address, the sending node SHOULD use a Routing header to 2266 route the packet to this mobile node (the destination node) by way 2267 of the care-of address in the binding recorded in that Binding Cache 2268 entry. For example, assuming use of a Type 0 Routing header [5], if 2269 no other use of a Routing header is involved in the routing of this 2270 packet, the mobile node sets the fields in the packet's IPv6 header 2271 and Routing header as follows: 2273 - The Destination Address in the packet's IPv6 header is set to 2274 the mobile node's care-of address copied from the Binding Cache 2275 entry. 2277 - The Routing header is initialized to contain a single route 2278 segment, with an Address of the mobile node's home address (the 2279 original destination address to which the packet was being sent). 2281 Following the definition of a Type 0 Routing header [5], this packet 2282 will be routed to the mobile node's care-of address, where it will 2283 be delivered to the mobile node (the mobile node has associated the 2284 care-of address with its network interface). Normal processing of 2285 the Routing header by the mobile node will then proceed as follows: 2287 - The mobile node swaps the Destination Address in the packet's 2288 IPv6 header and the Address specified in the Routing header. 2290 This results in the packet's IP Destination Address being set to 2291 the mobile node's home address. 2293 - The mobile node then resubmits the packet to its IPv6 module for 2294 further processing, "looping back" the packet inside the mobile 2295 node. Since the mobile node recognizes its own home address as 2296 one of its current IP addresses, the packet is processed further 2297 within the mobile node, in the same way then as if the mobile 2298 node was at home. 2300 If, instead, the sending node has no Binding Cache entry for the 2301 destination address to which the packet is being sent, the sending 2302 node simply sends the packet normally, with no Routing header. If 2303 the destination node is not a mobile node (or is a mobile node that 2304 is currently at home), the packet will be delivered directly to this 2305 node and processed normally by it. If, however, the destination node 2306 is a mobile node that is currently away from home, the packet will 2307 be intercepted by the mobile node's home agent and tunneled (using 2308 IPv6 encapsulation [4]) to the mobile node's current primary care-of 2309 address, as described in Section 9.6. The mobile node will then send 2310 a Binding Update to the sending node, as described in Section 10.7, 2311 allowing the sending node to create a Binding Cache entry for its use 2312 in sending subsequent packets to this mobile node. 2314 9. Home Agent Operation 2316 9.1. Receiving Router Advertisement Messages 2318 For each link on which a router provides service as a home agent, the 2319 router maintains a Home Agents List recording information about all 2320 other home agents on that link. This list is used in the dynamic 2321 home agent address discovery mechanism, described in Section 9.2. 2322 The information for the list is learned through receipt of the 2323 periodic unsolicited multicast Router Advertisements from each other 2324 home agent on the link, in which the Home Agent (H) bit is set, in a 2325 manner similar to the Default Router List conceptual data structure 2326 maintained by each host for Neighbor Discovery [14]. 2328 On receipt of a valid Router Advertisement, as defined in the 2329 processing algorithm specified for Neighbor Discovery [14], the home 2330 agent performs the following steps, in addition to any steps already 2331 required of it by Neighbor Discovery: 2333 - If the Home Agent (H) bit in the Router Advertisement is not set, 2334 skip all of the following steps. There are no special processing 2335 steps required by Mobile IP for this Router Advertisement, since 2336 the Advertisement was not sent by a home agent. 2338 - Otherwise, extract the Source Address from the IP header of the 2339 Router Advertisement. This is the link-local IP address on this 2340 link of the home agent sending this Advertisement [14]. 2342 - Determine from the Router Advertisement the preference for this 2343 home agent. If the Router Advertisement contains a Home Agent 2344 Information Option, then the preference is taken from the Home 2345 Agent Preference field in the option; otherwise, the default 2346 preference of 0 SHOULD be used. 2348 - Determine from the Router Advertisement the lifetime for 2349 this home agent. If the Router Advertisement contains a Home 2350 Agent Information Option, then the lifetime is taken from 2351 the Home Agent Lifetime field in the option; otherwise, the 2352 lifetime specified by the Router Lifetime field in the Router 2353 Advertisement SHOULD be used. 2355 - If the link-local address of the home agent sending this 2356 Advertisement is already present in this home agent's Home 2357 Agents List and the received home agent lifetime value is zero, 2358 immediately delete this entry in the Home Agents List. 2360 - Otherwise, if the link-local address of the home agent sending 2361 this Advertisement is already present in the receiving home 2362 agent's Home Agents List, reset its lifetime and preference to 2363 the values determined above. 2365 - If the link-local address of the home agent sending this 2366 Advertisement, as determined above, is not already present in 2367 the Home Agents List maintained by the receiving home agent, and 2368 the lifetime for the sending home agent, as determined above, 2369 is non-zero, create a new entry in the list, and initialize its 2370 lifetime and preference to the values determined above. 2372 - If the Home Agents List entry for the link-local address of 2373 the home agent sending this Advertisement was not deleted as 2374 described above, determine any global address(es) of the home 2375 agent based on each Prefix Information option received in 2376 this Advertisement in which the Router Address (R) bit is set 2377 (Section 6.2). For each such global address determined from this 2378 Advertisement, add this global address to the list of global 2379 addresses for this home agent in this Home Agents List entry. 2381 A home agent SHOULD maintain an entry in its Home Agents List for 2382 each such valid home agent address until that entry's lifetime 2383 expires, after which time the entry MUST be deleted. 2385 9.2. Dynamic Home Agent Address Discovery 2387 When a node receives a Binding Update, it MUST validate it and 2388 determine the type of Binding Update according to the steps described 2389 in Section 8.2. This section describes the processing of a valid 2390 Binding Update that indicates that the mobile node sending it is 2391 attempting dynamic home agent address discovery. 2393 As described in Section 10.6, a mobile node attempts dynamic home 2394 agent address discovery by sending its "home registration" Binding 2395 Update to the "Mobile IPv6 Home-Agents" anycast address [8] for its 2396 home IP subnet prefix (the packet MUST also include a Home Address 2397 option). A home agent receiving such a Binding Update that is 2398 serving this subnet (the home agent is configured with this anycast 2399 address on one of its network interfaces) MUST reject the Binding 2400 Update and SHOULD return a Binding Acknowledgement indicating this 2401 rejection, with the Source Address of the packet carrying the Binding 2402 Acknowledgement set to one of the global unicast addresses of the 2403 home agent. The Status field in the Binding Acknowledgement MUST be 2404 set to 135 (dynamic home agent address discovery response). 2406 In this Binding Acknowledgement rejecting the dynamic home agent 2407 address discovery Binding Update, this home agent SHOULD include a 2408 Home Agents List Sub-Option as follows: 2410 - The Home Agents List Sub-Option in this Binding Acknowledgement 2411 SHOULD contain one global IP address for each home agent 2412 currently listed in this home agent's own Home Agents List 2413 (Section 4.3). However, if this home agent's own global IP 2414 address would be placed in the list (as described below) as the 2415 first entry in the list, then this home agent SHOULD NOT include 2416 its own address in the list in the sub-option in the Binding 2417 Acknowledgement. Not placing this home agent's own IP address in 2418 the list will cause the receiving mobile node to consider this 2419 home agent as the most preferred home agent; otherwise, this home 2420 agent will be considered to be preferred in its order given by 2421 its place in the list returned. 2423 - The IP addresses in the Home Agents List should be placed in 2424 the Home Agents List Sub-Option in the Binding Acknowledgement 2425 in order of decreasing preference value, based either on the 2426 respective advertised preference from a Home Agent Information 2427 option or on the default preference of 0 if no preference is 2428 advertised (or on the configured home agent preference for this 2429 home agent itself). The home agent with the highest preference 2430 SHOULD be listed first, and the home agent with the lowest 2431 preference SHOULD be listed last. 2433 - Among home agents with equal preference, their IP addresses in 2434 the Home Agents List SHOULD be listed in an order randomized with 2435 respect to other home agents with equal preference, each time a 2436 Binding Acknowledgement with a Home Agents List Sub-Option is 2437 returned by this home agent. 2439 - For each entry in this home agent's Home Agents List, if more 2440 than one global IP address is associated with this list entry, 2441 then one of these global IP addresses SHOULD be selected to 2442 include in the Home Agents List Sub-Option to be returned in the 2443 Binding Acknowledgement. As described in Section 4.3, one Home 2444 Agents List entry, identified by the home agent's link-local 2445 address, exists for each home agent on the link; associated with 2446 that list entry is one or more global IP addresses for this 2447 home agent, learned through Prefix Information options with the 2448 Router Address (R) bit is set, received in Router Advertisements 2449 from this link-local address. The selected global IP address 2450 for each home agent to include in forming the Home Agents List 2451 Sub-Option to be returned in the Binding Acknowledgement MUST 2452 be the global IP address of the respective home agent sharing a 2453 prefix with the mobile node's home address for which the Binding 2454 Acknowledgement is being returned; if no such global IP address 2455 is known for some home agent, an entry for that home agent MUST 2456 NOT be included in the Home Agents List Sub-Option returned in 2457 the Binding Acknowledgement. 2459 - In order to avoid the possibility of the packet carrying the 2460 Binding Acknowledgement being fragmented, if the resulting 2461 total packet size containing the complete Home Agents List 2462 Sub-Option would exceed the minimum IPv6 MTU [5], the home agent 2463 SHOULD reduce the number of home agent IP addresses returned 2464 in the packet to the number of addresses that will fit without 2465 exceeding this limit. The home agent addresses returned in the 2466 packet SHOULD be those from the complete list with the highest 2467 preference. 2469 The mobile node, upon receiving this Binding Acknowledgement, MAY 2470 then resend its Binding Update to the home agent address given as the 2471 IP Source Address of the packet carrying the Binding Acknowledgement 2472 or to any of the unicast IP addresses listed in the Home Agents List 2473 Sub-Option in the Acknowledgement. For example, the mobile node may 2474 re-attempt its home registration with each of these home agents in 2475 turn, by sending each a Binding Update and waiting for the matching 2476 Binding Acknowledgement, until its registration is accepted by one 2477 of these home agents. In trying each of the returned home agent 2478 addresses, the mobile node SHOULD try each in the order listed in the 2479 Home Agents List Sub-Option in the Binding Acknowledgement. If the 2480 home agent identified by the Source Address field in the IP header 2481 of the packet carrying the Binding Acknowledgement is not listed in 2482 the Home Agents List Sub-Option, it SHOULD be tried before the first 2483 address given in the list; otherwise, it SHOULD be tried in the in 2484 its listed order. 2486 9.3. Primary Care-of Address Registration 2488 When a node receives a Binding Update, it MUST validate it and 2489 determine the type of Binding Update according to the steps described 2490 in Section 8.2. This section describes the processing of a valid 2491 Binding Update that requests the receiving node to serve as its home 2492 agent, registering its primary care-of address. 2494 To begin processing the Binding Update, the home agent MUST perform 2495 the following sequence of tests: 2497 - If the node is not a router that implements home agent 2498 functionality, then the node MUST reject the Binding Update and 2499 SHOULD return a Binding Acknowledgement to the mobile node, in 2500 which the Status field is set to 132 (home registration not 2501 supported). 2503 - Else, if the home address for the binding (the Home Address field 2504 in the packet's Home Address option) is not an on-link IPv6 2505 address with respect to the home agent's current Prefix List, 2506 then the home agent MUST reject the Binding Update and SHOULD 2507 return a Binding Acknowledgement to the mobile node, in which the 2508 Status field is set to 133 (not home subnet). 2510 - Else, if the Prefix Length field is nonzero in the Binding Update 2511 and this length differs from the length of the home agent's own 2512 knowledge of the corresponding subnet prefix on the home link, 2513 then the home agent MUST reject the Binding Update and SHOULD 2514 return a Binding Acknowledgement to the mobile node, in which the 2515 Status field is set to 136 (incorrect subnet prefix length). 2517 - Else, if the home agent chooses to reject the Binding Update for 2518 any other reason (e.g., insufficient resources to serve another 2519 mobile node as a home agent), then the home agent SHOULD return a 2520 Binding Acknowledgement to the mobile node, in which the Status 2521 field is set to an appropriate value to indicate the reason for 2522 the rejection. 2524 If the home agent does not reject the Binding Update as described 2525 above, then it becomes the home agent for the mobile node. The new 2526 home agent (the receiving node) MUST then create a new entry in its 2527 Binding Cache for this mobile node (or update its existing Binding 2528 Cache entry for this mobile node, if such an entry already exists) 2529 The home address of the mobile node is taken from the Home Address 2530 field in the packet's Home Address option. The care-of address for 2531 this Binding Cache entry is taken from the Care-of Address field of 2532 the Binding Update (if the Care-of Address Present (C) bit is set in 2533 the Binding Update) or from the Source Address field in the packet's 2534 IPv6 header (otherwise). 2536 The home agent MUST mark this Binding Cache entry as a "home 2537 registration" to indicate that the node is serving as a home 2538 agent for this binding. Binding Cache entries marked as a "home 2539 registration" MUST be excluded from the normal cache replacement 2540 policy used for the Binding Cache (Section 8.7) and MUST NOT be 2541 removed from the Binding Cache until the expiration of the Lifetime 2542 period. 2544 In addition, the home agent MUST copy the Router (R) bit from the 2545 Binding Update into the corresponding bit in this Binding Cache entry 2546 for this mobile node. 2548 The lifetime for the Binding Cache entry MUST NOT be greater than 2549 the remaining valid lifetime for the subnet prefix in the mobile 2550 node's home address specified with the Binding Update. The remaining 2551 valid lifetime for this prefix is determined by the home agent based 2552 on its own Prefix List entry for this prefix [14]. Furthermore, 2553 if the Prefix Length field in the Binding Update is nonzero, then 2554 the lifetime for the Binding Cache entry MUST NOT be greater than 2555 the minimum remaining valid lifetime for all subnet prefixes on 2556 the mobile node's home link. If the value of the Lifetime field 2557 specified by the mobile node in its Binding Update is greater than 2558 this prefix lifetime, the home agent MUST decrease the binding 2559 lifetime to less than or equal to the prefix valid lifetime. The 2560 home agent MAY further decrease the specified lifetime for the 2561 binding, for example based on a local policy implemented by the home 2562 agent. The resulting lifetime is stored by the home agent in the 2563 Binding Cache entry, and this Binding Cache entry MUST be deleted by 2564 the home agent after the expiration of this lifetime. 2566 The Prefix Length in the Binding Update MUST also be saved in the 2567 Binding Cache entry. 2569 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2570 be), then the home agent MUST return a Binding Acknowledgement to the 2571 mobile node, constructed as follows: 2573 - The Status field MUST be set to a value indicating success (the 2574 value MUST be less than 128). The only currently defined success 2575 Status value is 0, indicating simply that the Binding Update was 2576 accepted. 2578 - The Sequence Number field MUST be copied from the Sequence Number 2579 given in the Binding Update. 2581 - The Lifetime field MUST be set to the remaining lifetime for 2582 the binding as set by the home agent in its "home registration" 2583 Binding Cache entry for the mobile node. As described above, 2584 this lifetime MUST NOT be greater than the remaining valid 2585 lifetime for the subnet prefix in the mobile node's home address. 2587 - The Refresh field MUST be set to a value less than or equal to 2588 the Lifetime value being returned in the Binding Update. If the 2589 home agent stores the Binding Cache entry in nonvolatile storage 2590 (that survives the crash or other failure of the home agent), 2591 then the Refresh field SHOULD be set to the same value as the 2592 Lifetime field; otherwise, the home agent MAY set the Refresh 2593 field to a value less than the Lifetime field, to indicate that 2594 the mobile node SHOULD attempt to refresh its home registration 2595 at the indicated shorter interval (although the home agent will 2596 still retain the registration for the Lifetime period, even if 2597 the mobile node does not refresh its registration within the 2598 Refresh period). 2600 In addition, the home agent MUST follow the procedure defined in 2601 Section 9.5 to intercept packets on the mobile node's home link 2602 addressed to the mobile node, while the home agent is serving as the 2603 home agent for this mobile node. 2605 9.4. Primary Care-of Address De-registration 2607 When a node receives a Binding Update, it MUST validate it and 2608 determine the type of Binding Update according to the steps described 2609 in Section 8.2. This section describes the processing of a valid 2610 Binding Update that requests the receiving node to no longer serve as 2611 its home agent, de-registering its primary care-of address. 2613 To begin processing the Binding Update, the home agent MUST perform 2614 the following test: 2616 - If the receiving node has no entry in its Binding Cache for this 2617 mobile node that is marked as a "home registration", then this 2618 node MUST reject the Binding Update and SHOULD return a Binding 2619 Acknowledgement to the mobile node, in which the Status field is 2620 set to 137 (not home agent for this mobile node). 2622 If the home agent does not reject the Binding Update as described 2623 above, then it MUST delete any existing entry in its Binding Cache 2624 for this mobile node. 2626 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2627 be), then the home agent MUST return a Binding Acknowledgement to the 2628 mobile node, constructed as follows: 2630 - The Status field MUST be set to a value indicating success (the 2631 value MUST be less than 128). The only currently defined success 2632 Status value is 0, indicating simply that the Binding Update was 2633 accepted. 2635 - The Sequence Number field MUST be copied from the Sequence Number 2636 given in the Binding Update. 2638 - The Lifetime field MUST be set to zero. 2640 - The Refresh field MUST be set to zero. 2642 In addition, the home agent MUST stop intercepting packets on the 2643 mobile node's home link addressed to the mobile node (Section 9.5). 2645 9.5. Intercepting Packets for a Mobile Node 2647 While a node is serving as the home agent for mobile node (while the 2648 node has an entry in its Binding Cache for this mobile node that is 2649 marked as a "home registration"), this node MUST attempt to intercept 2650 packets on the mobile node's home link addressed to the mobile node, 2651 and MUST tunnel each intercepted packet to the mobile node using 2652 using IPv6 encapsulation [4]. 2654 In order to intercept such packets on the home link, when a node 2655 becomes the home agent for some mobile node (it did not already 2656 have a Binding Cache entry for this mobile node marked as a "home 2657 registration"), then the home agent MUST multicast onto the home link 2658 a "gratuitous" Neighbor Advertisement message [14] on behalf of the 2659 mobile node. Specifically, the home agent performs the following 2660 steps: 2662 - The home agent examines the value of the Prefix Length field 2663 in the new "home registration" Binding Cache entry. If this 2664 value is zero, the following step is carried out only for the 2665 individual home address specified for this binding. If, instead, 2666 this field is nonzero, then the following step is carried out 2667 for each address for the mobile node formed from the interface 2668 identifier in the mobile node's home address in this binding 2669 (the remaining low-order bits in the address after the indicated 2670 subnet prefix), together with each one of the subnet prefixes 2671 currently considered by the home agent to be on-link (including 2672 both the link-local and site-local prefix). 2674 - For each specific IP address for the mobile node determined 2675 in the first step above, the home agent multicasts onto the 2676 home link (to the all-nodes multicast address) a Neighbor 2677 Advertisement message [14] on behalf of the mobile node, to 2678 advertise the home agent's own link-layer address for this IP 2679 address. The Target Address in the Neighbor Advertisement 2680 message MUST be set to this IP address for the mobile node, and 2681 the Advertisement MUST include a Target Link-layer Address option 2682 specifying the home agent's link-layer address. In addition, 2683 the Router (R) bit in the Advertisement MUST be copied from the 2684 corresponding bit in the home agent's Binding Cache entry for 2685 the mobile node. The Solicited Flag (S) in the Advertisement 2686 MUST NOT be set, since it was not solicited by any Neighbor 2687 Solicitation message. The Override Flag (O) in the Advertisement 2688 MUST be set, indicating that the Advertisement SHOULD override 2689 any existing Neighbor Cache entry at any node receiving it. 2691 Any node on the home link receiving one of the Neighbor Advertisement 2692 messages described above will thus update its Neighbor Cache to 2693 associate the mobile node's address with the home agent's link 2694 layer address, causing it to transmit any future packets for the 2695 mobile node normally destined to this address instead to the mobile 2696 node's home agent. Since multicasts on the local link (such as 2697 Ethernet) are typically not guaranteed to be reliable, the home 2698 agent MAY retransmit this Neighbor Advertisement message up to 2699 MAX_ADVERT_REXMIT times to increase its reliability. It is still 2700 possible that some nodes on the home link will not receive any of 2701 these Neighbor Advertisements, but these nodes will eventually be 2702 able to detect the link-layer address change for the mobile node's 2703 home address, through use of Neighbor Unreachability Detection [14]. 2705 While a node is serving as a home agent for some mobile node (it 2706 still has a "home registration" entry for this mobile node in its 2707 Binding Cache), the home agent uses IPv6 Neighbor Discovery [14] 2708 to intercept unicast packets on the home link addressed the mobile 2709 node's home address. In order to intercept packets in this way, 2710 the home agent MUST act as a proxy for this mobile node to reply to 2711 any received Neighbor Solicitation messages for it. When a home 2712 agent receives a Neighbor Solicitation message, it MUST check if the 2713 Target Address specified in the message matches the home address 2714 of any mobile node for which it has a Binding Cache entry marked 2715 as a "home registration". This check MUST include all possible 2716 home addresses for the mobile node, based on the subnet prefixes 2717 currently considered to be on-link by the home agent (including the 2718 corresponding link-local address and site-local address), if the 2719 Prefix Length in the Binding Cache entry for this mobile node (from 2720 the Binding Update that created this Cache entry) is nonzero. 2722 If such an entry exists in the home agent's Binding Cache, the home 2723 agent MUST reply to the Neighbor Solicitation message with a Neighbor 2724 Advertisement message, giving the home agent's own link-layer address 2725 as the link-layer address for the specified Target Address. In 2726 addition, the Router (R) bit in the Advertisement MUST be copied from 2727 the corresponding bit in the home agent's Binding Cache entry for the 2728 mobile node. Acting as a proxy in this way allows other nodes on 2729 the mobile node's home link to resolve the mobile node's IPv6 home 2730 address, and allows the home agent to to defend these addresses on 2731 the home link for Duplicate Address Detection [14]. 2733 9.6. Tunneling Intercepted Packets to a Mobile Node 2735 For any packet sent to a mobile node from the mobile node's home 2736 agent (for which the home agent is the original sender of the 2737 packet), the home agent is operating as a correspondent node of 2738 the mobile node for this packet and the procedures described in 2739 Section 8.9 apply. The home agent (as a correspondent node) uses a 2740 Routing header to route the packet to the mobile node by way of the 2741 care-of address in the home agent's Binding Cache (the mobile node's 2742 primary care-of address, in this case). 2744 While the mobile node is away from home and this node is acting 2745 as the mobile node's home agent, the home agent intercepts any 2746 packets on the home link addressed to the mobile node's home address 2747 (including addresses formed from other on-link prefixes, if the 2748 Prefix Length field was nonzero in the Binding Update), as described 2749 in Section 9.5. The home agent cannot use a Routing header to 2750 forward these intercepted packets to the mobile node, since it cannot 2751 modify the packet in flight without invalidating any existing IPv6 2752 AH [9] or ESP [10] header present in the packet. 2754 For forwarding each intercepted packet to the mobile node, the 2755 home agent MUST tunnel the packet to the mobile node using IPv6 2756 encapsulation [4]; the tunnel entry point node is the home agent, 2757 and the tunnel exit point node is the primary care-of address as 2758 registered with the home agent (which is an address of the mobile 2759 node itself). When a home agent encapsulates an intercepted packet 2760 for forwarding to the mobile node, the home agent sets the Source 2761 Address in the prepended tunnel IP header to the home agent's own IP 2762 address, and sets the Destination Address in the tunnel IP header 2763 to the mobile node's primary care-of address. When received by the 2764 mobile node (using its primary care-of address), normal processing of 2765 the tunnel header [4] will result in decapsulation and processing of 2766 the original packet by the mobile node. 2768 However, packets addressed to the mobile node's link-local address 2769 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 2770 be discarded, and the home agent SHOULD return an ICMP Destination 2771 Unreachable, Code 3, message to the packet's Source Address (unless 2772 this Source Address is a multicast address). Packets addressed to 2773 the mobile node's site-local address SHOULD be tunneled to the mobile 2774 node by default, but this behavior MUST be configurable to disable 2775 it; currently, the exact definition and semantics of a "site" and a 2776 site-local address are undefined in IPv6, and this default behavior 2777 might change at some point in the future. 2779 Tunneling of multicast packets to a mobile node follows similar 2780 limitations to those defined above for unicast packets addressed to 2781 the mobile node's link-local and site-local addresses. Multicast 2782 packets addressed to a multicast address with link-local scope [7], 2783 to which the mobile node is subscribed, MUST NOT be tunneled 2784 to the mobile node; such packets SHOULD be silently discarded 2785 (after delivering to other local multicast recipients). Multicast 2786 packets addressed to a multicast address with scope larger 2787 than link-local but smaller than global (e.g., site-local and 2788 organization-local) [7], to which the mobile node is subscribed, 2789 SHOULD be tunneled to the mobile node by default, but this behavior 2790 MUST be configurable to disable it; this default behavior might 2791 change at some point in the future as the definition of these scopes 2792 become better defined in IPv6. 2794 9.7. Renumbering the Home Subnet 2796 IPv6 provides mechanisms through Neighbor Discovery [14] and Address 2797 Autoconfiguration [23] to aid in renumbering a subnet, such as when a 2798 site switches to a new network service provider. In renumbering, new 2799 prefixes and addresses can be introduced for the subnet and old ones 2800 can be deprecated and removed. These mechanisms are defined to work 2801 while all nodes using the old prefixes are at home, connected to the 2802 link using these prefixes. Mobile IPv6 extends these mechanisms for 2803 the case in which one or more mobile nodes using the old prefixes are 2804 away from home while the renumbering takes place. 2806 The IPv6 renumbering mechanisms are based on nodes on the link 2807 receiving Prefix Information options in Router Advertisement messages 2808 giving the valid lifetime and preferred lifetime for different 2809 prefixes on the link [14]. Mobile IPv6 arranges to tunnel certain 2810 Router Advertisements giving "important" Prefix Information options 2811 to mobile nodes while away from home. To avoid the need to tunnel 2812 all Router Advertisements from the home link to a mobile node away 2813 from home, those Router Advertisements that are tunneled to the 2814 mobile node are retransmitted until acknowledged. To avoid possible 2815 security attacks from forged Router Advertisements tunneled to 2816 the mobile node, all such tunneled Router Advertisements must be 2817 authenticated to the mobile node by its home agent using AH [9] or 2818 ESP [10]. 2820 Specifically, a home agent serving some mobile node SHOULD construct 2821 and tunnel to the mobile node a new Router Advertisement when any of 2822 the following conditions occur: 2824 - The preferred or valid lifetime for an existing prefix on the 2825 home link is reduced. 2827 - A new prefix is introduced on the home link. 2829 - The state of the home agent's AdvManagedFlag flag [14] changes 2830 from FALSE to TRUE or from TRUE to FALSE. 2832 The home agent determines these conditions based on its own 2833 configuration as a router and based on the Router Advertisements 2834 that it receives on the home link. The home agent constructs a new 2835 Router Advertisement message containing no options other than the 2836 Prefix Information options describing the prefixes for which one of 2837 the conditions above has occurred since the last Router Advertisement 2838 tunneled to and acknowledged by the mobile node. When multiple 2839 conditions occur at or near the same time, the home agent SHOULD 2840 attempt to combine them into a single Router Advertisement message to 2841 the mobile node. 2843 In tunneling each such Router Advertisement to the mobile node, the 2844 home agent MUST construct the packet as follows: 2846 - The Source Address in the packet's IPv6 header MUST be set to the 2847 home agent's IP address to which the mobile node addressed its 2848 current home registration. 2850 - The packet MUST include either an AH [9] or ESP [10] header 2851 providing sender authentication, data integrity protection, and 2852 replay protection. 2854 - The packet MUST include a Binding Request destination option. 2856 - The Binding Request destination option MUST include a Unique 2857 Identifier Sub-Option (Section 5.5), with the unique identifier 2858 in the sub-option data set to a value different than that in 2859 any other Binding Request sent recently by this node. The word 2860 "recently" here means within the maximum likely lifetime of a 2861 packet, including transit time from source to destination and 2862 time spent awaiting reassembly with other fragments of the same 2863 packet, if fragmented. However, it is not required that a source 2864 node know the maximum packet lifetime. Rather, it is assumed 2865 that the requirement can be met by maintaining a simple 16-bit 2866 "wrap-around" counter to generate unique identifiers for Binding 2867 Requests that contain a Unique Identifier Sub-Option, incremented 2868 each time a Binding Request containing a Unique Identifier 2869 Sub-Option is sent. 2871 - The packet MUST be tunneled to the mobile node's primary care-of 2872 address using a Routing header, in the same way as any packet 2873 sent to the mobile node originated by the home agent (rather than 2874 using IPv6 encapsulation, as would be used by the home agent for 2875 intercepted packets). 2877 The home agent SHOULD periodically continue to retransmit this 2878 tunneled packet to the mobile node, until it is acknowledged by 2879 the receipt from the mobile node of a Binding Update matching 2880 the Binding Request in the packet (i.e., with matching Sequence 2881 Number). A Binding Update matches a Binding Request if it specifies 2882 a binding for the mobile node to which the Binding Request was sent 2883 and contains a Unique Identifier Sub-Option matching the unique 2884 identifier sent in the Unique Identifier Sub-Option in the Binding 2885 Request. 2887 If while the home agent is still retransmitting a Router 2888 Advertisement to the mobile node, another condition as described 2889 above occurs on the home link causing another Router Advertisement 2890 to be tunneled to the mobile node, the home agent SHOULD combine any 2891 Prefix Information options in the unacknowledged Router Advertisement 2892 into the new Router Advertisement and then begin retransmitting the 2893 new Router Advertisement rather than the old one. When tunneling 2894 a new Router Advertisement, even if it contains Prefix Information 2895 options sent previously in an unacknowledged tunneled Router 2896 Advertisement, the home agent MUST generate a new unique identifer 2897 for use in the Unique Identifier Sub-Option in the Binding Request 2898 tunneled with the new Router Advertisement. 2900 In addition, as described in Section 9.3, the lifetime returned by a 2901 mobile node's home agent in its Binding Acknowledgement in response 2902 to registration of a new primary care-of address by the mobile node 2903 MUST be no greater than the remaining valid lifetime for the subnet 2904 prefix in the mobile node's home address. Furthermore, as described 2905 in Section 10.7, Binding Updates sent by the mobile node to other 2906 nodes MUST use a lifetime no greater than the remaining lifetime of 2907 its home registration of its primary care-of address. These limits 2908 on a binding lifetimes ensure that no node uses a mobile node's home 2909 address beyond the time that it becomes invalid. The mobile node 2910 SHOULD further limit the lifetimes that it sends on any Binding 2911 Updates to be within the remaining preferred lifetime for the prefix 2912 in its home address. 2914 10. Mobile Node Operation 2916 10.1. Sending Packets While Away from Home 2918 While a mobile node is away from home, it continues to use its home 2919 address as well as also using one or more care-of addresses. When 2920 sending a packet while away from home, a mobile node MAY choose among 2921 these in selecting the address that it will use as the source of the 2922 packet, as follows: 2924 - From the point of view of protocol layers and applications 2925 above Mobile IP (e.g., transport protocols), the mobile node 2926 will generally use its home address as the source of the packet 2927 for most packets, even while away from home, since Mobile IP 2928 is designed to make mobility transparent to such software. 2929 Doing so also makes the node's mobility and the fact that it is 2930 currently away from home transparent to the correspondent nodes 2931 with which it communicates. For packets sent that are part of 2932 transport-level connections established while the mobile node 2933 was at home, the mobile node MUST use its home address in this 2934 way. Likewise, for packets sent that are part of transport-level 2935 connections that the mobile node may still be using after moving 2936 to a new location, the mobile node SHOULD use its home address 2937 in this way. When sending such packets, Mobile IP will modify 2938 the packet to move the home address into a Home Address option 2939 and will set the IPv6 header's Source Address field to one of 2940 the mobile node's care-of addresses; these modifications to 2941 the packet are then reversed in the node receiving the packet, 2942 restoring the mobile node's home address to be the packet's 2943 Source Address before processing by higher protocol layers and 2944 applications. 2946 - For short-term communication, particularly for communication that 2947 may easily be retried if it fails, the mobile node MAY choose 2948 to directly use one of its care-of addresses as the source of 2949 the packet, thus not requiring the use of a Home Address option 2950 in the packet. An example of this type of communication might 2951 be DNS queries sent by the mobile node [12, 13]. Using the 2952 mobile node's care-of address as the source for such queries will 2953 generally have a lower overhead than using the mobile node's 2954 home address, since no extra options need be used in either the 2955 query or its reply, and all packets can be routed normally, 2956 directly between their source and destination without relying 2957 on Mobile IP. If the mobile node has no particular knowledge 2958 that the communication being sent fits within this general type 2959 of communication, however, the mobile node SHOULD NOT use its 2960 care-of address as the source of the packet in this way. 2962 If the mobile node uses one of its care-of addresses as the source 2963 of some packet while away from home, no special Mobile IP processing 2964 is required for sending this packet. The packet is simply addressed 2965 and transmitted in the same way as any normal IPv6 packet, setting 2966 the Source Address field in the packet's IPv6 header to this care-of 2967 address. 2969 On the other hand, if while away from home, the mobile node uses its 2970 home address as the source of a packet from the point of view of 2971 higher protocol layers or applications as described above, special 2972 Mobile IP processing of this packet is required for the insertion of 2973 the Home Address option. Specifically: 2975 - Since Mobile IP is transparent to higher protocol layers (e.g., 2976 to TCP), the packet is initially constructed using the mobile 2977 node's home address as the packet's Source Address, in the same 2978 way as if the mobile node were at home. 2980 - If the mobile node is at home, no special Mobile IP processing 2981 for this packet is required. The packet is sent normally and the 2982 following additional steps are not performed. 2984 - Likewise, if the Source Address field in the packet's IPv6 header 2985 is not the mobile node's home address, no special Mobile IP 2986 processing for this packet is required. The packet is sent 2987 normally and the following additional steps are not performed. 2989 - Otherwise, insert a Home Address option into the packet, with the 2990 Home Address field copied from the original value of the Source 2991 Address field in the packet. 2993 - Change the Source Address field in the packet's IPv6 header to 2994 one of the mobile node's care-of addresses. This will typically 2995 be the mobile node's current primary care-of address, but MUST 2996 be a care-of address with a subnet prefix that is on-link on the 2997 network interface on which the mobile node will transmit the 2998 packet. 3000 This addition of the Home Address option to a packet MUST be 3001 performed before outgoing IPsec processing, such as the addition of 3002 an AH [9] or ESP [10] header to the packet, is performed. Likewise, 3003 IPsec processing for a received packet containing a Home Address 3004 option MUST be performed before the packet is possibly modified as 3005 part of processing the Home Address option. By using the care-of 3006 address as the Source Address in the IPv6 header, with the mobile 3007 node's home address instead in the Home Address option, the packet 3008 will be able to safely pass through any router implementing ingress 3009 filtering [6]. 3011 10.2. Receiving Packets While Away from Home 3013 While away from home, a mobile node will receive packets addressed to 3014 its home address, by one of three methods: 3016 - Packets sent by a correspondent node that does not have a 3017 Binding Cache entry for the mobile node, will be sent by the 3018 correspondent node in the same way as any normal IP packet. Such 3019 packets will then be intercepted by the mobile node's home agent, 3020 encapsulated using IPv6 encapsulation [4], and tunneled to the 3021 mobile node's primary care-of address. 3023 - Packets sent by a correspondent node that has a Binding Cache 3024 entry for the mobile node that contains the mobile node's current 3025 care-of address, will be sent by the correspondent node using 3026 a Routing header. The packet will be addressed to the mobile 3027 node's care-of address, with the final hop in the Routing header 3028 directing the packet to the mobile node's home address; the 3029 processing of this last hop of the Routing header is entirely 3030 internal to the mobile node, since the care-of address and home 3031 address are both addresses within the mobile node. 3033 - Packets sent by a correspondent node that has a Binding Cache 3034 entry for the mobile node that contains an out-of-date care-of 3035 address for the mobile node, will be sent by the correspondent 3036 node using a Routing header, as described above. If the mobile 3037 node sent a Binding Update to its previous default router when 3038 moving from this care-of address to another, and if the Binding 3039 Cache entry that was created from this Binding Update is still 3040 present in this router's Binding Cache, then such a packet 3041 will be intercepted by this router, encapsulated using IPv6 3042 encapsulation [4], and tunneled to the mobile node's primary 3043 care-of address (registered with this router, acting as a home 3044 agent for this out-of-date care-of address). 3046 For packets received by either the first or last of these three 3047 methods, the mobile node SHOULD send a Binding Update to the original 3048 sender of the packet, as described in Section 10.7, subject to the 3049 rate limiting defined in Section 10.10. The mobile node SHOULD 3050 also process the received packet in the manner defined for IPv6 3051 encapsulation [4], which will result in the encapsulated (inner) 3052 packet being processed normally by upper-layer protocols within the 3053 mobile node, as if it had been addressed (only) to the mobile node's 3054 home address. 3056 For packets received by the second method above (using a Routing 3057 header), the mobile node SHOULD process the received packet in the 3058 manner defined for the type of IPv6 Routing header used [5], which 3059 will result in the packet being processed normally by upper-layer 3060 protocols within the mobile node, as if it had been addressed (only) 3061 to the mobile node's home address. 3063 In addition, the general procedures defined by IPv6 for Routing 3064 headers suggest that a received Routing header MAY be automatically 3065 "reversed" to construct a Routing header for use in any response 3066 packets sent by upper-layer protocols, if the received packet is 3067 authenticated [5]. If this is done for upper-layer protocol response 3068 packets sent by a mobile node while away from home, the mobile 3069 node SHOULD NOT include its own care-of address, which appears in 3070 the Routing header of the received packet, in the reversed route 3071 for the response packet. If the received Routing header contained 3072 no additional hops (other than the mobile node's home address and 3073 care-of address), then any upper-layer protocol response packet 3074 SHOULD NOT include a Routing header. 3076 10.3. Movement Detection 3078 A mobile node MAY use any combination of mechanisms available to it 3079 to detect when it has moved from one link to another. The primary 3080 movement detection mechanism for Mobile IPv6 defined here uses the 3081 facilities of IPv6 Neighbor Discovery, including Router Discovery and 3082 Neighbor Unreachability Detection. The description here is based on 3083 the conceptual model of the organization and data structures defined 3084 by Neighbor Discovery [14]. 3086 Mobile nodes SHOULD use Router Discovery to discover new routers and 3087 on-link subnet prefixes; a mobile node MAY send Router Solicitation 3088 messages, or MAY wait for unsolicited (periodic) multicast Router 3089 Advertisement messages, as specified for Router Discovery [14]. 3090 Based on received Router Advertisement messages, a mobile node (in 3091 the same way as any other node) maintains an entry in its Default 3092 Router List for each router, and an entry in its Prefix List for each 3093 subnet prefix, that it currently considers to be on-link. Each entry 3094 in these lists has an associated invalidation timer value (extracted 3095 from the Router Advertisement) used to expire the entry when it 3096 becomes invalid. 3098 While away from home, a mobile node SHOULD select one router from 3099 its Default Router List to use as its default router, and one subnet 3100 prefix advertised by that router from its Prefix List to use as 3101 the subnet prefix in its primary care-of address. A mobile node 3102 MAY also have associated additional care-of addresses, using other 3103 subnet prefixes from its Prefix List. The method by which a mobile 3104 node selects and forms a care-of address from the available subnet 3105 prefixes is described in Section 10.4. The mobile node registers 3106 its primary care-of address with its home agent, as described in 3107 Section 10.5. 3109 While a mobile node is away from home and using some router as its 3110 default router, it is important for the mobile node to be able to 3111 quickly detect when that router becomes unreachable, so that it can 3112 switch to a new default router and to a new primary care-of address. 3113 Since some links (notably wireless) do not necessarily work equally 3114 well in both directions, it is likewise important for the mobile 3115 node to detect when it becomes unreachable to packets sent from its 3116 default router, so that the mobile node can take steps to ensure that 3117 any correspondent nodes attempting to communicate with it can still 3118 reach it through some other route. 3120 To detect when its default router becomes unreachable, a mobile 3121 node SHOULD use Neighbor Unreachability Detection. As specified in 3122 Neighbor Discovery [14], while the mobile node is actively sending 3123 packets to (or through) its default router, the mobile node can 3124 detect that the router (as its neighbor) is still reachable either 3125 through indications from upper layer protocols on the mobile node 3126 that a connection is making "forward progress" (e.g., receipt of TCP 3127 acknowledgements for new data transmitted), or through receipt of a 3128 Neighbor Advertisement message from its default router in response 3129 to an explicit Neighbor Solicitation messages to it. Note that 3130 although this mechanism detects that the mobile node's default router 3131 has become unreachable to the mobile node only while the mobile node 3132 is actively sending packets to it, this is the only time that this 3133 direction of reachability confirmation is needed. Confirmation 3134 that the mobile node is still reachable from the router is handled 3135 separately, as described below. 3137 For a mobile node to detect when it has become unreachable from its 3138 default router, the mobile node cannot efficiently rely on Neighbor 3139 Unreachability Detection alone, since the network overhead would be 3140 prohibitively high in many cases for a mobile node to continually 3141 probe its default router with Neighbor Solicitation messages even 3142 when it is not otherwise actively sending packets to it. Instead, 3143 a mobile node SHOULD consider receipt of any IPv6 packets from its 3144 current default router as an indication that it is still reachable 3145 from the router. Both packets from the router's IP address and 3146 (IPv6) packets from its link-layer address (e.g., those forwarded but 3147 not originated by the router) SHOULD be considered. 3149 Since the router SHOULD be sending periodic unsolicited multicast 3150 Router Advertisement messages, the mobile node will have frequent 3151 opportunity to check if it is still reachable from its default 3152 router, even in the absence of other packets to it from the router. 3153 If Router Advertisements that the mobile node receives include 3154 an Advertisement Interval option, the mobile node MAY use its 3155 Advertisement Interval field as an indication of the frequency with 3156 which it should expect to continue to receive future Advertisements 3157 from that router. This field specifies the minimum rate (the maximum 3158 amount of time between successive Advertisements) that the mobile 3159 node should expect. If this amount of time elapses without the 3160 mobile node receiving any Advertisement from this router, the mobile 3161 node can be sure that at least one Advertisement sent by the router 3162 has been lost. It is thus possible for the mobile node to implement 3163 its own policy for determining the number of Advertisements from 3164 its current default router it is willing to tolerate losing before 3165 deciding to switch to a different router from which it may currently 3166 be correctly receiving Advertisements. 3168 On some types of network interfaces, the mobile node MAY also 3169 supplement this monitoring of Router Advertisements, by setting its 3170 network interface into "promiscuous" receive mode, so that it is able 3171 to receive all packets on the link, including those not link-level 3172 addressed to it (i.e., disabling link-level address filtering). The 3173 mobile node will then be able to detect any packets sent by the 3174 router, in order to to detect reachability from the router. This 3175 use of promiscuous mode may be useful on very low bandwidth (e.g., 3176 wireless) links, but its use MUST be configurable on the mobile node. 3178 If the above means do not provide indication that the mobile node is 3179 still reachable from its current default router (i.e., the mobile 3180 node receives no packets from the router for a period of time), then 3181 the mobile node SHOULD attempt to actively probe the router with 3182 Neighbor Solicitation messages, even if it is not otherwise actively 3183 sending packets to the router. If it receives a solicited Neighbor 3184 Advertisement message in response from the router, then the mobile 3185 node can deduce that it is still reachable. It is expected that the 3186 mobile node will in most cases be able to determine its reachability 3187 from the router by listening for packets from the router as described 3188 above, and thus, such extra Neighbor Solicitation probes should 3189 rarely be necessary. 3191 With some types of networks, it is possible that additional 3192 indications about link-layer mobility can be obtained from 3193 lower-layer protocol or device driver software within the mobile 3194 node. However, a mobile node MUST NOT assume that all link-layer 3195 mobility indications from lower layers indicate a movement of the 3196 mobile node to a new link, such that the mobile node would need to 3197 switch to a new default router and primary care-of address. For 3198 example, movement of a mobile node from one cell to another in many 3199 wireless LANs can be made transparent to the IP level through use of 3200 a link-layer "roaming" protocol, as long as the different wireless 3201 LAN cells all operate as part of the same IP link with the same 3202 subnet prefix. Upon lower-layer indication of link-layer mobility, 3203 the mobile node MAY send Router Solicitation messages to determine if 3204 new routers (and new on-link subnet prefixes) are present on its new 3205 link. 3207 Such lower-layer information might also be useful to a mobile node in 3208 deciding to switch its primary care-of address to one of the other 3209 care-of addresses it has formed from the on-link subnet prefixes 3210 currently available through different routers from which the mobile 3211 node is reachable. For example, a mobile node MAY use signal 3212 strength or signal quality information (with suitable hysteresis) for 3213 its link with the available routers to decide when to switch to a new 3214 primary care-of address using that router rather than its current 3215 default router (and current primary care-of address). Even though 3216 the mobile node's current default router may still be reachable in 3217 terms of Neighbor Unreachability Detection, the mobile node MAY use 3218 such lower-layer information to determine that switching to a new 3219 default router would provide a better connection. 3221 10.4. Forming New Care-of Addresses 3223 After detecting that it has moved from one link to another (i.e., its 3224 current default router has become unreachable and it has discovered 3225 a new default router), a mobile node SHOULD form a new primary 3226 care-of address using one of the on-link subnet prefixes advertised 3227 by the new router. A mobile node MAY form a new primary care-of 3228 address at any time, except that it MUST NOT do so too frequently. 3229 Specifically, a mobile node MUST NOT send a Binding Update about a 3230 new care-of address to its home agent (which is required to register 3231 the new address as its primary care-of address) more often than once 3232 per MAX_UPDATE_RATE seconds. 3234 In addition, after discovering a new on-link subnet prefix, a mobile 3235 node MAY form a new (non-primary) care-of address using that subnet 3236 prefix, even when it has not switched to a new default router. A 3237 mobile node can have only one primary care-of address at a time 3238 (which is registered with its home agent), but it MAY have an 3239 additional care-of address for any or all of the prefixes on its 3240 current link. Furthermore, since a wireless network interface may 3241 actually allow a mobile node to be reachable on more than one link at 3242 a time (i.e., within wireless transmitter range of routers on more 3243 than one separate link), a mobile node MAY have care-of addresses 3244 on more than one link at a time. The use of more than one care-of 3245 address at a time is described in Section 10.15. 3247 As described in Section 4, in order to form a new care-of address, 3248 a mobile node MAY use either stateless [23] or stateful (e.g., 3249 DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to 3250 send packets as part of the method of address autoconfiguration, 3251 it MUST use an IPv6 link-local address rather than its own IPv6 3252 home address as the Source Address in the IPv6 header of each such 3253 autoconfiguration packet. 3255 In some cases, a mobile node may already know a (constant) IPv6 3256 address that has been assigned to it for its use only while 3257 visiting a specific foreign link. For example, a mobile node may be 3258 statically configured with an IPv6 address assigned by the system 3259 administrator of some foreign link, for its use while visiting that 3260 link. If so, rather than using Address Autoconfiguration to form a 3261 new care-of address using this subnet prefix, the mobile node MAY use 3262 its own pre-assigned address as its care-of address on this link. 3264 10.5. Sending Binding Updates to the Home Agent 3266 After deciding to change its primary care-of address as described 3267 in Sections 10.3 and 10.4, a mobile node MUST register this care-of 3268 address with its home agent in order to make this its primary care-of 3269 address. To do so, the mobile node sends a packet to its home agent 3270 containing a Binding Update option, with the packet constructed as 3271 follows: 3273 - The Home Registration (H) bit MUST be set in the Binding Update. 3275 - The Acknowledge (A) bit MUST be set in the Binding Update. 3277 - The packet MUST contain a Home Address option, giving the mobile 3278 node's home address for the binding. 3280 - The care-of address for the binding MUST be used as the Source 3281 Address in the packet's IPv6 header, or the Care-of Address 3282 Present (C) bit MUST be set in the Binding Update and the care-of 3283 address for the binding MUST be specified in the Care-of Address 3284 field in the Binding Update. 3286 - The Prefix Length field SHOULD be set to the length of the mobile 3287 node's subnet prefix in its home address, to request the mobile 3288 node's home agent to serve as a home agent for all home addresses 3289 for the mobile node based on all on-link subnet prefixes on the 3290 home link. Otherwise, this field MUST be set to zero. 3292 The Acknowledge (A) bit in the Binding Update requests the home 3293 agent to return a Binding Acknowledgement in response to this 3294 Binding Update. As described in Section 5.2, the mobile node SHOULD 3295 retransmit this Binding Update to its home agent until it receives 3296 a matching Binding Acknowledgement. Once reaching a retransmission 3297 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 3298 continue to periodically retransmit the Binding Update at this rate 3299 until acknowledged (or until it begins attempting to register a 3300 different primary care-of address). 3302 The Prefix Length field in the Binding Update allows the mobile node 3303 to request its home agent to serve all home addresses for the mobile 3304 node, as indicated by the interface identifier in the mobile node's 3305 home address (the remaining low-order bits after the indicated subnet 3306 prefix), together with each on-link subnet prefix on the home link. 3308 Until the lifetime of this registration expires, the home agent 3309 considers itself the home agent for each such home address of the 3310 mobile node. As the set of on-link subnet prefixes on the home link 3311 changes over time, the home agent changes the set of home addresses 3312 for this mobile node for which it is serving as the home agent. 3314 If the mobile node has additional home addresses using a different 3315 interface identifier, then the mobile node SHOULD send an additional 3316 packet containing a Binding Update to its home agent to register 3317 the care-of address for each such other home address (or set of 3318 home addresses sharing an interface identifier). These additional 3319 Binding Updates MUST each be sent as a separate packet, since each 3320 MUST contain an AH [9] or ESP [10] header to authenticate the Binding 3321 Update as coming from the home address being bound. 3323 10.6. Dynamic Home Agent Address Discovery 3325 It is possible that when the mobile node needs to send a Binding 3326 Update to its home agent to register its new primary care-of address, 3327 as described in Section 10.5, the mobile node may not know the 3328 address of any router on its home link that can serve as a home agent 3329 for it. For example, some nodes on its home link may have been 3330 reconfigured while the mobile node has been away from home, such that 3331 the router that was operating as the mobile node's home agent has 3332 been replaced by a different router serving this role. 3334 In this case, the mobile node SHOULD use the dynamic home agent 3335 address discovery procedure to find the address of a suitable home 3336 agent on its home link. To do so, the mobile node sends the packet, 3337 as described above, with the Destination Address in the packet's 3338 IPv6 header set to the "Mobile IPv6 Home-Agents" anycast address [8] 3339 for its home subnet prefix. As described in Section 9.2, the 3340 home agent on its home link that receives this Binding Update will 3341 reject the Update, returning to the mobile node the home agent's own 3342 global unicast IP address along with a list of the global unicast IP 3343 addresses of each other home agent operating on the home link. The 3344 mobile node SHOULD then retransmit its Binding Update to one of these 3345 homes agent using the provided global unicast address; the mobile 3346 node MAY re-attempt this home registration with each of these home 3347 agents in turn, by sending each a Binding Update and waiting for the 3348 matching Binding Acknowledgement, until its registration is accepted 3349 by one of these home agents. 3351 If the mobile node has a current registration with some home agent 3352 on its home link (the Lifetime for that registration has not yet 3353 expired), then the mobile node MUST attempt any new registration 3354 first with that home agent. If that registration attempt fails 3355 (e.g., times out or is rejected), the mobile node SHOULD then 3356 reattempt this registration with another home agent on its home link. 3358 If the mobile node knows of no other suitable home agent, then it MAY 3359 attempt the dynamic home agent address discovery procedure described 3360 above. 3362 10.7. Sending Binding Updates to Correspondent Nodes 3364 A mobile node MAY send a Binding Update to any correspondent node at 3365 any time to allow the correspondent node to cache the mobile node's 3366 current care-of address (subject to the rate limiting defined in 3367 Section 10.10). In any Binding Update sent by a mobile node, the 3368 care-of address (either the Source Address in the packet's IPv6 3369 header or the Care-of Address field in the Binding Update) MUST be 3370 set to one of the care-of addresses currently in use by the mobile 3371 node or to the mobile node's home address. 3373 If set to one of the mobile node's current care-of addresses (the 3374 care-of address given MAY differ from the mobile node's primary 3375 care-of address), the Binding Update requests the correspondent node 3376 to create or update an entry for the mobile node in the correspondent 3377 node's Binding Cache to record this care-of address for use in 3378 sending future packets to the mobile node. In this case, the 3379 Lifetime value sent in the Binding Update MUST be no greater than 3380 the remaining lifetime of the mobile node's home registration of its 3381 primary care-of address at its home agent. 3383 If, instead, the care-of address is set to the mobile node's home 3384 address, the Binding Update requests the correspondent node to delete 3385 any existing Binding Cache entry that it has for the mobile node. 3386 A mobile node MAY set the care-of address differently for sending 3387 Binding Updates to different correspondent nodes. 3389 When sending any Binding Update, the mobile node MUST record in its 3390 Binding Update List the following fields from the Binding Update: 3392 - The IP address of the node to which the Binding Update was sent. 3394 - The home address for which the Binding Update was sent (the value 3395 in the Home Address option in the packet carrying the Binding 3396 Update). 3398 - The remaining lifetime of the binding, initialized from the 3399 Lifetime field sent in the Binding Update. 3401 The mobile node MUST retain in its Binding Update List information 3402 about all Binding Updates sent, for which the lifetime of the binding 3403 has not yet expired. However, when sending a Binding Update, if an 3404 entry already exists in the mobile node's Binding Update List for 3405 an earlier Binding Update sent to that same destination node, the 3406 existing Binding Update List entry is updated to reflect the new 3407 Binding Update rather than creating a new Binding Update List entry. 3409 In general, when a mobile node sends a Binding Update to its home 3410 agent to register a new primary care-of address (as described in 3411 Section 10.5), the mobile node will also send a Binding Update to 3412 each other node for which an entry exists in the mobile node's 3413 Binding Update List. Thus, other relevant nodes are generally kept 3414 updated about the mobile node's binding and can send packets directly 3415 to the mobile node using the mobile node's current care-of address. 3417 The mobile node, however, need not send these Binding Updates 3418 immediately after configuring a new care-of address. For example, 3419 since the Binding Update is a destination option and can be included 3420 in any packet sent by a mobile node, the mobile node MAY delay 3421 sending a new Binding Update to any correspondent node for a 3422 short period of time, in hopes that the needed Binding Update 3423 can be included in some packet that the mobile node sends to that 3424 correspondent node for some other reason (for example, as part of 3425 some TCP connection in use). In this case, when sending a packet 3426 to some correspondent node, the mobile node SHOULD check in its 3427 Binding Update List to determine if a new Binding Update to this 3428 correspondent node is needed, and SHOULD include the new Binding 3429 Update in this packet as necessary. 3431 In addition, when a mobile node receives a packet for which the 3432 mobile node can deduce that the original sender of the packet has 3433 no Binding Cache entry for the mobile node, or for which the mobile 3434 node can deduce that the original sender of the packet has an 3435 out-of-date care-of address for the mobile node in its Binding Cache, 3436 the mobile node SHOULD return a Binding Update to the sender giving 3437 its current care-of address (subject to the rate limiting defined 3438 in Section 10.10). In particular, the mobile node SHOULD return a 3439 Binding Update in response to receiving a packet that meets all of 3440 the following tests: 3442 - The packet was tunneled using IPv6 encapsulation. 3444 - The Destination Address in the tunnel (outer) IPv6 header is 3445 equal to any of the mobile node's care-of addresses. 3447 - The Destination Address in the original (inner) IPv6 header 3448 is equal to one of the mobile node's home addresses; or this 3449 Destination Address is equal to one of the mobile node's previous 3450 care-of addresses, if the mobile node has an entry in its Binding 3451 Update List representing an unexpired Binding Update sent to 3452 a previous default router for this previous care-of address 3453 (Section 10.8). 3455 - The Source Address in the tunnel (outer) IPv6 header differs from 3456 the Source Address in the original (inner) IPv6 header. 3458 The destination address to which the Binding Update should be sent 3459 in response to receiving a packet meeting all of the above tests is 3460 the Source Address in the original (inner) IPv6 header of the packet. 3461 The home address for which this Binding Update is sent should be the 3462 Destination Address of the original (inner) packet. 3464 Binding Updates sent to correspondent nodes are not generally 3465 required to be acknowledged. However, if the mobile node wants 3466 to be sure that its new care-of address has been entered into a 3467 correspondent node's Binding Cache, the mobile node MAY request an 3468 acknowledgement by setting the Acknowledge (A) bit in the Binding 3469 Update. In this case, however, the mobile node SHOULD NOT continue 3470 to retransmit the Binding Update once the retransmission timeout 3471 period has reached MAX_BINDACK_TIMEOUT. 3473 A mobile node MAY choose to keep its location private from certain 3474 correspondent nodes, and thus need not send new Binding Updates to 3475 those correspondents. A mobile node MAY also send a Binding Update 3476 to such a correspondent node to instruct it to delete any existing 3477 binding for the mobile node from its Binding Cache, as described in 3478 Section 5.1. No other IPv6 nodes are authorized to send Binding 3479 Updates on behalf of a mobile node. 3481 10.8. Sending Binding Updates to the Previous Default Router 3483 After switching to a new default router (and thus also changing its 3484 primary care-of address), a mobile node MAY send a Binding Update to 3485 its previous default router, giving its new care-of address. The 3486 packet carrying the Binding Update MUST be addressed to the mobile 3487 node's previous default router's global unicast address, learned 3488 by the mobile node based on Prefix Information options received in 3489 Router Advertisements from it in which the Router Address (R) bit is 3490 set (Sections 4.3 and 6.2). 3492 If the mobile node sends such a Binding Update, the home address 3493 for the binding, specified in the Home Address option included in 3494 the packet carrying this Binding Update, MUST be set the mobile 3495 node's old primary care-of address (that it used while using this 3496 default router), and the care-of address for the binding (either the 3497 Source Address in the packet's IPv6 header or the Care-of Address 3498 field in the Binding Update) MUST be set to the mobile node's new 3499 primary care-of address. In addition, the Home Registration (H) 3500 bit MUST also be set in this Binding Update, to request the mobile 3501 node's previous default router to temporarily act as a home agent 3502 for the mobile node's old primary care-of address. The previous 3503 default router will thus tunnel packets for the mobile node to its 3504 new care-of address. All of the procedures defined for home agent 3505 operation must be followed by this previous default router for this 3506 registration. Note that the previous router does not necessarily 3507 know the mobile node's (permanent) home address as part of this 3508 registration. 3510 10.9. Retransmitting Binding Updates 3512 If, after sending a Binding Update in which the Acknowledge (A) bit 3513 is set, a mobile node fails to receive a Binding Acknowledgement 3514 within INITIAL_BINDACK_TIMEOUT seconds, the mobile node SHOULD 3515 retransmit the Binding Update until a Binding Acknowledgement 3516 is received. Such a retransmitted Binding Update MUST use the 3517 same Sequence Number value as the original transmission. The 3518 retransmissions by the mobile node MUST use an exponential 3519 back-off process, in which the timeout period is doubled 3520 upon each retransmission until either the node receives a 3521 Binding Acknowledgement or the timeout period reaches the value 3522 MAX_BINDACK_TIMEOUT. 3524 10.10. Rate Limiting for Sending Binding Updates 3526 A mobile node MUST NOT send Binding Updates about the same binding 3527 to any node more often than once per MAX_UPDATE_RATE seconds. After 3528 sending MAX_FAST_UPDATES consecutive Binding Updates to a particular 3529 node with the same care-of address, the mobile node SHOULD reduce 3530 its rate of sending Binding Updates to that node, to the rate of 3531 SLOW_UPDATE_RATE per second. The mobile node MAY continue to send 3532 Binding Updates at this slower rate indefinitely, in hopes that the 3533 node will eventually be able to process a Binding Update and begin 3534 to route its packets directly to the mobile node at its new care-of 3535 address. 3537 10.11. Receiving Binding Acknowledgements 3539 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 3540 node MUST validate the packet according to the following tests: 3542 - The packet contains a valid AH [9] or ESP [10] header providing 3543 sender authentication, data integrity protection, and replay 3544 protection. 3546 - The Option Length field in the option is greater than or equal to 3547 11 octets. 3549 - The Sequence Number field matches the Sequence Number sent by the 3550 mobile node to this destination address in an outstanding Binding 3551 Update. 3553 Any Binding Acknowledgement not satisfying all of these tests MUST be 3554 silently ignored, although the remainder of the packet (i.e., other 3555 options, extension headers, or payload) SHOULD be processed normally 3556 according to any procedure defined for that part of the packet. 3558 When a mobile node receives a packet carrying a valid Binding 3559 Acknowledgement, the mobile node MUST examine the Status field as 3560 follows: 3562 - If the Status field indicates that the Binding Update was 3563 accepted (the Status field is less than 128), then the mobile 3564 node MUST update the corresponding entry in its Binding Update 3565 List to indicate that the Binding Update has been acknowledged. 3566 The mobile node MUST then stop retransmitting the Binding Update. 3568 - If the Status field indicates that the Binding Update was 3569 rejected (the Status field is greater than or equal to 128), then 3570 the mobile node MUST delete the corresponding Binding Update List 3571 entry (and MUST also stop retransmitting the Binding Update). 3572 Optionally, the mobile node MAY then take steps to correct the 3573 cause of the error and retransmit the Binding Update (with a new 3574 Sequence Number value), subject to the rate limiting restriction 3575 specified in Section 10.10. In particular, if the Status field 3576 is equal to 135 (dynamic home agent address discovery response), 3577 then the mobile node MAY reattempt its home registration with 3578 the home agent address given in the Source Address field of the 3579 packet carrying the Binding Acknowledgement or with any of the 3580 home agent IP addresses listed in the Home Agents List Sub-Option 3581 in the Binding Acknowledgement. If any of these addresses is not 3582 a global unicast address or does not have a subnet prefix equal 3583 to the mobile node's own subnet prefix, then that particular 3584 address MUST be ignored and the mobile node MUST NOT reattempt 3585 its home registration with that home agent. 3587 10.12. Receiving Binding Requests 3589 When a mobile node receives a packet containing a Binding Request, 3590 it SHOULD return to the sender a packet containing a Binding Update. 3591 The Lifetime field in this Binding Update SHOULD be set to a new 3592 lifetime, extending any current lifetime remaining from a previous 3593 Binding Update sent to this node (as indicated in any existing 3594 Binding Update List entry for this node), except that this lifetime 3595 MUST NOT exceed the remaining lifetime for the mobile node's primary 3596 care-of address registration at its home agent. When sending this 3597 Binding Update, the mobile node MUST update its Binding Update List 3598 in the same way as for any other Binding Update sent by the mobile 3599 node. 3601 Note, however, that the mobile node MAY choose to keep its current 3602 binding private from the sender of the Binding Request. In this 3603 case, the mobile node instead SHOULD returns a Binding Update to the 3604 sender, in which the Lifetime field is set to zero and the care-of 3605 address is set to the mobile node's home address. 3607 If the Binding Request for which the Binding Update is being returned 3608 contains a Unique Identifer Sub-Option, the Binding Update MUST also 3609 include a Unique Identifier Sub-Option. The unique identifier in the 3610 SUb-Option Data field of the Unique Identifier Sub-Option MUST be 3611 copied from the unique identifier carried in the Binding Request. 3613 10.13. Receiving ICMP Error Messages 3615 The Option Type value for a Binding Update option specifies that 3616 any node receiving this option that does not recognize the Option 3617 Type SHOULD return an ICMP Parameter Problem, Code 2, message to 3618 the sender of the packet containing the Binding Update option. If 3619 a node sending a Binding Update receives such an ICMP error message 3620 in response, it should record in its Binding Update List that future 3621 Binding Updates should not be sent to this destination. 3623 Likewise, although ALL IPv6 nodes (whether host or router, whether 3624 mobile or stationary) MUST implement the ability to correctly process 3625 received packets containing a Home Address option, all Option Type 3626 values in IPv6 include a specification of the behavior that a node 3627 receiving a packet containing this option performs if it does not 3628 implement receipt of that type of option. For the Home Address 3629 option, the Option Type value specifies that any node receiving 3630 this option that does not recognize the Option Type SHOULD return 3631 an ICMP Parameter Problem, Code 2, message to the sender of the 3632 packet containing the Home Address option. If a mobile node receives 3633 such an ICMP error message from some node indicating that it does 3634 not recognize the mobile node's Home Address option, the mobile 3635 node SHOULD log the error and then discard the ICMP message; this 3636 error message indicates that the node to which the original packet 3637 was addressed (the node returning the ICMP error message) does not 3638 correctly implement this required part of the IPv6 protocol. 3640 10.14. Receiving Tunneled Router Advertisements 3642 Section 9.7 describes the operation of a home agent to support 3643 renumbering a mobile node's home subnet while the mobile node is 3644 away from home. The home agent tunnels certain Router Advertisement 3645 messages to the mobile node while away from home, giving "important" 3646 Prefix Information options that describe changes in the prefixes in 3647 use on the mobile node's home link. 3649 When a mobile node receives a tunneled Router Advertisement, it MUST 3650 validate it according to the following tests: 3652 - The Source Address of the IP packet carrying the Router 3653 Advertisement is the same as the home agent address to which the 3654 mobile node last sent an accepted "home registration" Binding 3655 Update to register its primary care-of address. 3657 - The packet contains either an AH [9] or ESP [10] header providing 3658 sender authentication, data integrity protection, and replay 3659 protection. 3661 - The packet contains a Binding Request destination option. 3663 - The Binding Request option contains a Unique Identifier 3664 Sub-Option. 3666 Any received tunneled Router Advertisement not meeting all of these 3667 tests MUST be silently discarded. 3669 If a received tunneled Router Advertisement is not discarded 3670 according to the tests listed above, the mobile node MUST process the 3671 Router Advertisement as if it were connected to its home link [14]. 3672 Such processing MAY result in the mobile node configuring a new home 3673 address, although due to separation between preferred lifetime and 3674 valid lifetime, such changes should not affect most communication by 3675 the mobile node, in the same way as for nodes that are at home. 3677 In addition, in processing the packet containing this Router 3678 Advertisement, the mobile node SHOULD return to the home agent a 3679 Binding Update in response to the Binding Request carried in the 3680 packet. The correct formation of this Binding Update by the mobile 3681 node and processing of it by the home agent will be viewed by the 3682 home agent as an acknowledgement of this Router Advertisement, 3683 confirming to it that this Router Advertisement was received by the 3684 mobile node. 3686 10.15. Using Multiple Care-of Addresses 3688 As described in Section 10.4, a mobile node MAY use more than one 3689 care-of address at a time. Particularly in the case of many wireless 3690 networks, a mobile node effectively might be reachable through 3691 multiple links at the same time (e.g., with overlapping wireless 3692 cells), on which different on-link subnet prefixes may exist. A 3693 mobile node SHOULD select a primary care-of address from among those 3694 care-of addresses it has formed using any of these subnet prefixes, 3695 based on the movement detection mechanism in use, as described in 3696 Section 10.3. When the mobile node selects a new primary care-of 3697 address, it MUST register it with its home agent by sending it a 3698 Binding Update with the Home Registration (H) and Acknowledge (A) 3699 bits set, as described in Section 10.5. 3701 To assist with smooth handoffs, a mobile node SHOULD retain 3702 its previous primary care-of address as a (non-primary) care-of 3703 address, and SHOULD still accept packets at this address, even after 3704 registering its new primary care-of address with its home agent. 3705 This is reasonable, since the mobile node could only receive packets 3706 at its previous primary care-of address if it were indeed still 3707 connected to that link. If the previous primary care-of address was 3708 allocated using stateful Address Autoconfiguration [2], the mobile 3709 node may not wish to release the address immediately upon switching 3710 to a new primary care-of address. 3712 10.16. Routing Multicast Packets 3714 A mobile node that is connected to its home link functions in the 3715 same way as any other (stationary) node. Thus, when it is at home, 3716 a mobile node functions identically to other multicast senders and 3717 receivers. This section therefore describes the behavior of a mobile 3718 node that is not on its home link. 3720 In order to receive packets sent to some multicast group, a mobile 3721 node must join that multicast group. One method by which a mobile 3722 node MAY join the group is via a (local) multicast router on the 3723 foreign link being visited. The mobile node SHOULD use its care-of 3724 address sharing a subnet prefix with the multicast router, as 3725 the source IPv6 address of its multicast group membership control 3726 messages. 3728 Alternatively, a mobile node MAY join multicast groups via a 3729 bi-directional tunnel to its home agent. The mobile node tunnels its 3730 multicast group membership control packets to its home agent, and the 3731 home agent forwards multicast packets down the tunnel to the mobile 3732 node. 3734 A mobile node that wishes to send packets to a multicast group 3735 also has two options: (1) send directly on the foreign link being 3736 visited; or (2) send via a tunnel to its home agent. Because 3737 multicast routing in general depends upon the Source Address used in 3738 the IPv6 header of the multicast packet, a mobile node that tunnels a 3739 multicast packet to its home agent MUST use its home address as the 3740 IPv6 Source Address of the inner multicast packet. 3742 10.17. Returning Home 3744 A mobile node detects that it has returned to its home link through 3745 the movement detection algorithm in use (Section 10.3), when the 3746 mobile node detects that its home subnet prefix is again on-link. 3747 The mobile node SHOULD then send a Binding Update to its home agent, 3748 to instruct its home agent to no longer intercept or tunnel packets 3749 for it. In this Binding Update, the mobile node MUST set the care-of 3750 address for the binding (the Source Address field in the packet's 3751 IPv6 header) to the mobile node's own home address. As with other 3752 Binding Updates sent to register with its home agent, the mobile 3753 node MUST set the Acknowledge (A) and Home Registration (H) bits, 3754 and SHOULD retransmit the Binding Update until a matching Binding 3755 Acknowledgement is received. 3757 In addition, the mobile node MUST multicast onto the home link 3758 (to the all-nodes multicast address) a Neighbor Advertisement 3759 message [14], to advertise the mobile node's own link-layer address 3760 for its own home address. The Target Address in this Neighbor 3761 Advertisement message MUST be set to the mobile node's home address, 3762 and the Advertisement MUST include a Target Link-layer Address option 3763 specifying the mobile node's link-layer address. The mobile node 3764 MUST multicast such a Neighbor Advertisement message for each of its 3765 home addresses, as defined by the current on-link prefixes, including 3766 its link-local address and site-local address. The Solicited 3767 Flag (S) in these Advertisements MUST NOT be set, since they were 3768 not solicited by any Neighbor Solicitation message. The Override 3769 Flag (O) in these Advertisements MUST be set, indicating that the 3770 Advertisements SHOULD override any existing Neighbor Cache entries at 3771 any node receiving them. 3773 Since multicasts on the local link (such as Ethernet) are typically 3774 not guaranteed to be reliable, the mobile node MAY retransmit these 3775 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 3776 increase their reliability. It is still possible that some nodes on 3777 the home link will not receive any of these Neighbor Advertisements, 3778 but these nodes will eventually be able to recover through use of 3779 Neighbor Unreachability Detection [14]. 3781 11. Constants 3783 INITIAL_BINDACK_TIMEOUT 1 second 3785 MAX_BINDACK_TIMEOUT 256 seconds 3787 MAX_UPDATE_RATE once per second 3789 SLOW_UPDATE_RATE once per 10 seconds 3791 MAX_FAST_UPDATES 5 transmissions 3793 MAX_ADVERT_REXMIT 3 transmissions 3795 12. IANA Considerations 3797 This document defines four new types of IPv6 destination options, 3798 each of which must be assigned an Option Type value: 3800 - The Binding Update option, described in Section 5.1 3802 - The Binding Acknowledgement option, described in Section 5.2 3804 - The Binding Request option, described in Section 5.3 3806 - The Home Address option, described in Section 5.4 3808 In addition, this document defines two new Neighbor Discovery [14] 3809 options, which must be assigned Option Type values within the option 3810 numbering space for Neighbor Discovery messages: 3812 - The Advertisement Interval option, described in Section 6.3. 3814 - The Home Agent Information option, described in Section 6.4. 3816 Finally, this document defines a new type of anycast address, which 3817 must be assigned a reserved value for use with any subnet prefix to 3818 define this anycast address on each subnet: 3820 - The "Mobile IPv6 Home-Agents" anycast address [8], used in the 3821 dynamic home agent address discovery procedure described in 3822 Sections 9.2 and 10.6. 3824 13. Security Considerations 3826 13.1. Binding Updates, Acknowledgements, and Requests 3828 The Binding Update option described in this document will result 3829 in packets addressed to a mobile node being delivered instead to 3830 its care-of address. This ability to change the routing of these 3831 packets could be a significant vulnerability if any packet containing 3832 a Binding Update option was not authenticated. Such use of "remote 3833 redirection", for instance as performed by the Binding Update option, 3834 is widely understood to be a security problem in the current Internet 3835 if not authenticated [1]. 3837 The Binding Acknowledgement option also requires authentication, 3838 since, for example, an attacker could otherwise trick a mobile node 3839 into believing a different outcome from a registration attempt with 3840 its home agent. 3842 No authentication is required for the Binding Request option, since 3843 the use of this option does not modify or create any state in either 3844 the sender or the receiver. The Binding Request option does open 3845 some issues with binding privacy, but those issues can be dealt with 3846 either through existing IPsec encryption mechanisms or through use of 3847 firewalls. 3849 The existing IPsec replay protection mechanisms allow a "replay 3850 protection window" to support receiving packets out of order. 3851 Although appropriate for many forms of communication, Binding Updates 3852 MUST be applied only in the order sent. The Binding Update option 3853 thus includes a Sequence Number field to provide this necessary 3854 sequencing. The use of this Sequence Number together with IPsec 3855 replay protection is similar in many ways, for example, to the the 3856 sequence number in TCP. IPsec provides strong replay protection but 3857 no ordering, and the sequence number provides ordering but need not 3858 worry about replay protection such as through the sequence number 3859 wrapping around. 3861 13.2. Home Address Option 3863 No special authentication of the Home Address option is required, 3864 except that if the IPv6 header of a packet is covered by 3865 authentication, then that authentication MUST also cover the Home 3866 Address option; this coverage is achieved automatically by the 3867 definition of the Option Type code for the Home Address option 3868 (Section 5.4), since it indicates that the option is included in the 3869 authentication computation. Thus, even when authentication is used 3870 in the IPv6 header, the security of the Source Address field in the 3871 IPv6 header is not compromised by the presence of a Home Address 3872 option. Without authentication of the packet, then any field in the 3873 IPv6 header, including the Source Address field, and any other parts 3874 of the packet, including the Home Address option, can be forged or 3875 modified in transit. In this case, the contents of the Home Address 3876 option is no more suspect than any other part of the packet. 3878 The use of the Home Address option allows packets sent by a 3879 mobile node to pass normally through routers implementing ingress 3880 filtering [6]. Since the care-of address used in the Source Address 3881 field of the packet's IPv6 header is topologically correct for the 3882 sending location of the mobile node, ingress filtering can trace the 3883 location of the mobile node in the same way as can be done with any 3884 sender when ingress filtering is in use. 3886 However, if a node receiving a packet that includes a Home Address 3887 option implements the processing of this option by physically 3888 copying the Home Address field from the option into the IPv6 header, 3889 replacing the Source Address field there, then the ability to 3890 trace the true location of the sender is removed once this step 3891 in the processing is performed. This diminishing of the power of 3892 ingress filtering only occurs once the packet has been received at 3893 its ultimate destination, and does not affect the capability of 3894 ingress filtering while the packet is in transit. Furthermore, this 3895 diminishing can be entirely eliminated by appropriate implementation 3896 techniques in the receiving node. For example, the original contents 3897 of the Source Address field (the sending care-of address) could be 3898 saved elsewhere in memory with the packet, until all processing of 3899 the packet is completed. 3901 13.3. General Mobile Computing Issues 3903 The mobile computing environment is potentially very different from 3904 the ordinary computing environment. In many cases, mobile computers 3905 will be connected to the network via wireless links. Such links 3906 are particularly vulnerable to passive eavesdropping, active replay 3907 attacks, and other active attacks. Furthermore, mobile computers 3908 are more susceptible to loss or theft than stationary computers. 3909 Any secrets such as authentication or encryption keys stored on the 3910 mobile computer are thus subject to compromise in ways generally not 3911 common in the non-mobile environment. 3913 Users who have sensitive data that they do not wish others to have 3914 access to should use additional mechanisms (such as encryption) to 3915 provide privacy protection, but such mechanisms are beyond the scope 3916 of this document. Users concerned about traffic analysis should 3917 consider appropriate use of link encryption. If stronger location 3918 privacy is desired, the mobile node can create a tunnel to its home 3919 agent. Then, packets destined for correspondent nodes will appear 3920 to emanate from the home subnet, and it may be more difficult to 3921 pinpoint the location of the mobile node. Such mechanisms are all 3922 beyond the scope of this document. 3924 Changes from Previous Version of the Draft 3926 This appendix briefly lists some of the major changes in this 3927 draft relative to the previous version of this same draft, 3928 draft-ietf-mobileip-ipv6-07.txt: 3930 - Changed the listed Option Type codes for the destination options 3931 and Type codes Router Advertisement options to their official 3932 values, now that IPv6 has finally officially assigned these. 3934 - Added a Router (R) bit in the Binding Update option format, for 3935 use in "home registration" Binding Updates. This flag bit tells 3936 the home agent that the mobile node is a router, so that the 3937 home agent can set the corresponding bit correctly in all proxy 3938 Neighbor Advertisements that it sends on behalf of this mobile 3939 node. Also added a bit to save this flag in the definition of 3940 the Binding Cache entry format, and defined how it is used in 3941 sending proxy Neighbor Advertisements. 3943 - Added a bit of text in a few places to clarify the meaning of 3944 MAX_UPDATE_RATE. 3946 - Added to Section 7.3 a requirement that every home agent SHOULD 3947 support a configuration mechanism to allow a system administrator 3948 to manually set the value to be sent by this home agent in the 3949 Home Agent Preference field of the Home Agent Information Option 3950 in Router Advertisements that it sends. 3952 - Added a suggestion in Section 6.4 that the Home Agent Preference 3953 field in a Home Agent Information option being sent by a home 3954 agent could be set dynamically by the sending home agent based 3955 on factors such as the number of mobile nodes it is currently 3956 serving or the remaining resources it has for serving additional 3957 mobile nodes. However, the details of such dynamic settings 3958 are beyond the scope of this document since they do not involve 3959 protocol standardization issues. 3961 - Normalized all references to the "Mobile IPv6 Home-Agents" 3962 anycast address to use the full name of this specific anycast 3963 address and to point to the new definition of reserved IPv6 3964 subnet anycast addresses, RFC 2526. 3966 - Updated all references to their most recent versions, including 3967 changing old Internet-Draft references into new RFC references 3968 where available. Changed remaining specific Internet-Draft 3969 references to be generic "Work in progress" references. 3971 - Updated the "Status of This Memo" section to the new official 3972 version of this text. 3974 - Corrected a few minor typographical errors in places. 3976 Acknowledgements 3978 We would like to thank the members of the Mobile IP and IPng Working 3979 Groups for their comments and suggestions on this work. We would 3980 particularly like to thank (in alphabetical order) Josh Broch 3981 (Carnegie Mellon University), Thomas Narten (IBM), Erik Nordmark (Sun 3982 Microsystems), Simon Nybroe (Telebit Communications), Patrice Romand 3983 (Bull S.A.), Tom Soderlund (Nokia Research), and Jim Solomon (RedBack 3984 Networks) for their detailed reviews of earlier versions of this 3985 draft. Their suggestions have helped to improve both the design and 3986 presentation of the protocol. 3988 References 3990 [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 3991 ACM Computer Communications Review, 19(2), March 1989. 3993 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 3994 Protocol for IPv6 (DHCPv6), February 1999. Work in progress. 3996 [3] Scott Bradner. Key words for use in RFCs to indicate 3997 requirement levels. RFC 2119, March 1997. 3999 [4] Alex Conta and Stephen Deering. Generic packet tunneling in 4000 IPv6 specification. RFC 2473, December 1998. 4002 [5] Stephen E. Deering and Robert M. Hinden. Internet Protocol 4003 version 6 (IPv6) specification. RFC 2460, December 1998. 4005 [6] Paul Ferguson and Daniel Senie. Network ingress filtering: 4006 Defeating denial of service attacks which employ IP source 4007 address spoofing. RFC 2267, January 1998. 4009 [7] Robert M. Hinden and Stephen E. Deering. IP Version 6 4010 addressing architecture. RFC 2373, July 1998. 4012 [8] David B. Johnson and Stephen E. Deering. Reserved ipv6 subnet 4013 anycast addresses. RFC 2526, March 1999. 4015 [9] Stephen Kent and Randall Atkinson. IP Authentication header. 4016 RFC 2402, November 1998. 4018 [10] Stephen Kent and Randall Atkinson. IP Encapsulating Security 4019 Payload (ESP). RFC 2406, November 1998. 4021 [11] Stephen Kent and Randall Atkinson. Security architecture for 4022 the Internet Protocol. RFC 2401, November 1998. 4024 [12] P. Mockapetris. Domain Names -- concepts and facilities. 4025 RFC 1034, November 1987. 4027 [13] P. Mockapetris. Domain Names -- implementation and 4028 specification. RFC 1035, November 1987. 4030 [14] Thomas Narten, Erik Nordmark, and William Allen Simpson. 4031 Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December 4032 1998. 4034 [15] Charles Perkins. IP encapsulation within IP. RFC 2003, October 4035 1996. 4037 [16] Charles Perkins, editor. IP mobility support. RFC 2002, 4038 October 1996. 4040 [17] Charles Perkins. Minimal encapsulation within IP. RFC 2004, 4041 October 1996. 4043 [18] Charles Perkins and David B. Johnson. Route optimization in 4044 Mobile IP, February 1999. Work in progress. 4046 [19] David C. Plummer. An Ethernet address resolution protocol: 4047 Or converting network protocol addresses to 48.bit Ethernet 4048 addresses for transmission on Ethernet hardware. RFC 826, 4049 November 1982. 4051 [20] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 4053 [21] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 4054 September 1981. 4056 [22] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 4057 October 1994. 4059 [23] Susan Thomson and Thomas Narten. IPv6 stateless address 4060 autoconfiguration. RFC 2462, December 1998. 4062 Chair's Address 4064 The Working Group can be contacted via its current chairs: 4066 Erik Nordmark 4067 Sun Microsystems, Inc. 4068 2550 Garcia Avenue 4069 Mt. View, CA 94041 4070 USA 4072 Phone: +1 415 786-5166 4073 Fax: +1 415 786-5896 4074 E-mail: nordmark@sun.com 4076 Basavaraj Patil 4077 Nortel Networks, Inc. 4078 2201 Lakeside Blvd. 4079 Richardson, TX 75082-4399 4080 USA 4082 Phone: +1 972 684-1489 4083 E-mail: bpatil@nortelnetworks.com 4085 Authors' Addresses 4087 Questions about this document can also be directed to the authors: 4089 David B. Johnson 4090 Carnegie Mellon University 4091 Computer Science Department 4092 5000 Forbes Avenue 4093 Pittsburgh, PA 15213-3891 4094 USA 4096 Phone: +1 412 268-7399 4097 Fax: +1 412 268-5576 4098 E-mail: dbj@cs.cmu.edu 4100 Charles Perkins 4101 Sun Microsystems, Inc. 4102 Technology Development Group 4103 Mail Stop MPK15-214 4104 Room 2682 4105 901 San Antonio Road 4106 Palo Alto, CA 94303 4107 USA 4109 Phone: +1 415 786-6464 4110 Fax: +1 415 786-6445 4111 E-mail: cperkins@eng.sun.com