idnits 2.17.1 draft-ietf-mobileip-ipv6-12.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (27 April 2000) is 8762 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 2463 (ref. '5') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. '6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2267 (ref. '7') (Obsoleted by RFC 2827) ** Obsolete normative reference: RFC 2409 (ref. '8') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2373 (ref. '9') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '12') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2401 (ref. '13') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (ref. '14') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2461 (ref. '17') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2002 (ref. '19') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '21' ** Obsolete normative reference: RFC 2407 (ref. '22') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 793 (ref. '25') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '26') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2462 (ref. '27') (Obsoleted by RFC 4862) Summary: 18 errors (**), 0 flaws (~~), 3 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 Nokia 5 27 April 2000 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 22 months, and may be updated, replaced, or obsoleted by other documents 23 at 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. Alignment Requirements for New Destination Options . . . 13 67 4.4. IPsec Requirements for New Destination Options . . . . . 13 68 4.5. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14 69 4.6. Conceptual Data Structures . . . . . . . . . . . . . . . 14 70 4.7. Binding Management . . . . . . . . . . . . . . . . . . . 19 72 5. New IPv6 Destination Options and Message Types 21 73 5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 21 74 5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 25 75 5.3. Binding Request Option . . . . . . . . . . . . . . . . . 29 76 5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 31 77 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 34 78 5.6. ICMP Home Agent Address Discovery Request Message . . . . 37 79 5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 39 81 6. Modifications to IPv6 Neighbor Discovery 41 82 6.1. Modified Router Advertisement Message Format . . . . . . 41 83 6.2. Modified Prefix Information Option Format . . . . . . . . 42 84 6.3. New Advertisement Interval Option Format . . . . . . . . 44 85 6.4. New Home Agent Information Option Format . . . . . . . . 45 86 6.5. Changes to Sending Router Advertisements . . . . . . . . 47 87 6.6. Changes to Sending Router Solicitations . . . . . . . . . 48 89 7. Requirements for IPv6 Nodes 50 90 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 50 91 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 50 92 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 50 93 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 51 95 8. Correspondent Node Operation 53 96 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 53 97 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 53 98 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 54 99 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 55 100 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 55 101 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 55 102 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 56 103 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 57 104 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 58 106 9. Home Agent Operation 60 107 9.1. Receiving Router Advertisement Messages . . . . . . . . . 60 108 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 61 109 9.3. Primary Care-of Address Registration . . . . . . . . . . 63 110 9.4. Primary Care-of Address De-registration . . . . . . . . . 65 111 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 66 112 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 68 113 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 69 115 10. Mobile Node Operation 73 116 10.1. Sending Packets While Away from Home . . . . . . . . . . 73 117 10.2. Interaction with Outbound IPsec Processing . . . . . . . 74 118 10.3. Receiving Packets While Away from Home . . . . . . . . . 76 119 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 77 120 10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 80 121 10.6. Sending Binding Updates to the Home Agent . . . . . . . . 82 122 10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 83 123 10.8. Sending Binding Updates to Correspondent Nodes . . . . . 84 124 10.9. Establishing Forwarding from a Previous Care-of Address . 87 125 10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 88 126 10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 88 127 10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 89 128 10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 90 129 10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 90 130 10.15. Receiving Local Router Advertisement Messages . . . . . . 91 131 10.16. Receiving Tunneled Router Advertisements . . . . . . . . 92 132 10.17. Using Multiple Care-of Addresses . . . . . . . . . . . . 93 133 10.18. Routing Multicast Packets . . . . . . . . . . . . . . . . 94 134 10.19. Returning Home . . . . . . . . . . . . . . . . . . . . . 95 136 11. Protocol Constants 97 138 12. IANA Considerations 98 140 13. Security Considerations 99 141 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 99 142 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 99 143 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 100 145 Changes from Previous Version of the Draft 102 147 Acknowledgements 105 149 References 106 151 Chair's Address 108 153 Authors' Addresses 109 154 1. Introduction 156 This document specifies the operation of mobile computers using 157 Internet Protocol Version 6 (IPv6) [6]. Without specific support 158 for mobility in IPv6, packets destined to a mobile node (host or 159 router) would not be able to reach it while the mobile node is away 160 from its home link (the link on which its home IPv6 subnet prefix is 161 in use), since routing is based on the subnet prefix in a packet's 162 destination IP address. In order to continue communication in spite 163 of its movement, a mobile node could change its IP address each time 164 it moves to a new link, but the mobile node would then not be able 165 to maintain transport and higher-layer connections when it changes 166 location. Mobility support in IPv6 is particularly important, as 167 mobile computers are likely to account for a majority or at least a 168 substantial fraction of the population of the Internet during the 169 lifetime of IPv6. 171 The protocol operation defined here, known as Mobile IPv6, allows a 172 mobile node to move from one link to another without changing the 173 mobile node's IP address. A mobile node is always addressable by 174 its "home address", an IP address assigned to the mobile node within 175 its home subnet prefix on its home link. Packets may be routed to 176 the mobile node using this address regardless of the mobile node's 177 current point of attachment to the Internet, and the mobile node may 178 continue to communicate with other nodes (stationary or mobile) after 179 moving to a new link. The movement of a mobile node away from its 180 home link is thus transparent to transport and higher-layer protocols 181 and applications. 183 The Mobile IPv6 protocol is just as suitable for mobility across 184 homogeneous media as for mobility across heterogeneous media. For 185 example, Mobile IPv6 facilitates node movement from one Ethernet 186 segment to another as well as it facilitates node movement from an 187 Ethernet segment to a wireless LAN cell, with the mobile node's IP 188 address remaining unchanged in spite of such movement. 190 One can think of the Mobile IPv6 protocol as solving the "macro" 191 mobility management problem. More "micro" mobility management 192 applications -- for example, handoff among wireless transceivers, 193 each of which covers only a very small geographic area -- are 194 possibly more suited to other solutions. For example, in many 195 current wireless LAN products, link-layer mobility mechanisms allow a 196 "handoff" of a mobile node from one cell to another, reestablishing 197 link-layer connectivity to the node in each new location. As long 198 as such handoff occurs only within cells of the mobile node's home 199 link, such link-layer mobility mechanisms are likely to offer faster 200 convergence and lower overhead than Mobile IPv6. Extensions to the 201 Mobile IPv6 protocol are also possible to support a more local, 202 hierarchical form of mobility management, but such extensions are 203 beyond the scope of this document. 205 The protocol specified in this document solves the problem of 206 transparently routing packets to and from mobile nodes while away 207 from home. However, it does not attempt to solve all general 208 problems related to the use of mobile computers or wireless networks. 209 In particular, this protocol does not attempt to solve: 211 - Handling links with partial reachability, such as typical 212 wireless networks. Some aspects of this problem are addressed 213 by the movement detection procedure described in Section 10.4, 214 but no attempt has been made to fully solve this problem in its 215 general form. Most aspects of this problem can be solved by the 216 workaround of restricting such networks to only one router per 217 link, although there are still possible hidden terminal problems 218 when two nodes on the same link (on opposite sides of the router) 219 attempt to communicate directly. 221 - Access control on a link being visited by a mobile node. This 222 is a general problem any time an untrusted node is allowed to 223 connect to any link layer. It is independent of whether the 224 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 225 address on the link. 227 2. Comparison with Mobile IP for IPv4 229 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 230 natural combination of the experiences gained from the development 231 of Mobile IP support in IPv4 (Mobile IPv4) [19, 18, 20], together 232 with the opportunities provided by the design and deployment of a new 233 version of IP itself (IPv6) and the new protocol features offered 234 by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, 235 but the protocol is now fully integrated into IP and provides many 236 improvements over Mobile IPv4. This section summarizes the major 237 differences between Mobile IPv4 and Mobile IPv6: 239 - Support for what is known in Mobile IPv4 as "Route 240 Optimization" [21] is now built in as a fundamental part 241 of the protocol, rather than being added on as an optional 242 set of extensions that may not be supported by all nodes 243 as in Mobile IPv4. This integration of Route Optimization 244 functionality allows direct routing from any correspondent node 245 to any mobile node, without needing to pass through the mobile 246 node's home network and be forwarded by its home agent, and thus 247 eliminates the problem of "triangle routing" present in the base 248 Mobile IPv4 protocol [19]. This integration also allows the 249 Mobile IPv4 "registration" functionality and the Mobile IPv4 250 Route Optimization functionality to be performed by a single 251 protocol rather than two separate (and different) protocols. 253 - Support is also integrated into Mobile IPv6 -- and into IPv6 254 itself -- for allowing mobile nodes and Mobile IP to coexist 255 efficiently with routers that perform "ingress filtering" [7]. A 256 mobile node now uses its care-of address as the Source Address in 257 the IP header of packets it sends, allowing the packets to pass 258 normally through ingress filtering routers. The home address 259 of the mobile node is carried in the packet in a Home Address 260 destination option, allowing the use of the care-of address in 261 the packet to be transparent above the IP layer. The ability 262 to correctly process a Home Address option in a received packet 263 is required in all IPv6 nodes, whether mobile nor stationary, 264 whether host or router. 266 - The use of the care-of address as the Source Address in each 267 packet's IP header also simplifies routing of multicast packets 268 sent by a mobile node. With Mobile IPv4, the mobile node 269 had to tunnel multicast packets to its home agent in order to 270 transparently use its home address as the source of the multicast 271 packets. With Mobile IPv6, the use of the Home Address option 272 allows the home address to be used but still be compatible with 273 multicast routing that is based in part on the packet's Source 274 Address. 276 - There is no longer any need to deploy special routers as 277 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 278 mobile nodes make use of the enhanced features of IPv6, such 279 as Neighbor Discovery [17] and Address Autoconfiguration [27], 280 to operate in any location away from home without any special 281 support required from its local router. 283 - Unlike Mobile IPv4, Mobile IPv6 utilizes IP Security 284 (IPsec) [11, 12, 13] for all security requirements (sender 285 authentication, data integrity protection, and replay protection) 286 for Binding Updates (which serve the role of both registration 287 and Route Optimization in Mobile IPv4). Mobile IPv4 relies 288 on its own security mechanisms for these functions, based on 289 statically configured "mobility security associations". 291 - The movement detection mechanism in Mobile IPv6 provides 292 bidirectional confirmation of a mobile node's ability to 293 communicate with its default router in its current location 294 (packets that the router sends are reaching the mobile node, and 295 packets that the mobile node sends are reaching the router). 296 This confirmation provides a detection of the "black hole" 297 situation that may exist in some wireless environments where the 298 link to the router does not work equally well in both directions, 299 such as when the mobile node has moved out of good wireless 300 transmission range from the router. The mobile node may then 301 attempt to find a new router and begin using a new care-of 302 address if its link to its current router is not working well. 303 In contrast, in Mobile IPv4, only the forward direction (packets 304 from the router are reaching the mobile node) is confirmed, 305 allowing the black hole condition to persist. 307 - Most packets sent to a mobile node while away from home in 308 Mobile IPv6 are sent using an IPv6 Routing header rather than IP 309 encapsulation, whereas Mobile IPv4 must use encapsulation for all 310 packets. The use of a Routing header requires less additional 311 header bytes to be added to the packet, reducing the overhead 312 of Mobile IP packet delivery. To avoid modifying the packet in 313 flight, however, packets intercepted and tunneled by a mobile 314 node's home agent in Mobile IPv6 must still use encapsulation for 315 delivery to the mobile node. 317 - While a mobile node is away from home, its home agent intercepts 318 any packets for the mobile node that arrive at the home network, 319 using IPv6 Neighbor Discovery [17] rather than ARP [23] as is 320 used in Mobile IPv4. The use of Neighbor Discovery improves 321 the robustness of the protocol (e.g., due to the Neighbor 322 Advertisement "override" bit) and simplifies implementation 323 of Mobile IP due to the ability to not be concerned with any 324 particular link layer as is required in ARP. 326 - The use of IPv6 encapsulation (and the Routing header) removes 327 the need in Mobile IPv6 to manage "tunnel soft state", which was 328 required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 329 to the definition of ICMP for IPv6, the use of tunnel soft state 330 is no longer required in IPv6 for correctly relaying ICMP error 331 messages from within the tunnel back to the original sender of 332 the packet. 334 - The dynamic home agent address discovery mechanism in Mobile IPv6 335 uses IPv6 anycast [10] and returns a single reply to the mobile 336 node, rather than the corresponding Mobile IPv4 mechanism that 337 used IPv4 directed broadcast and returned a separate reply from 338 each home agent on the mobile node's home link. The Mobile IPv6 339 mechanism is more efficient and more reliable, since only 340 one packet need be sent back to the mobile node and since the 341 mobile node is less likely to lose one of the replies because no 342 "implosion" of replies is required by the protocol. 344 - Mobile IPv6 defines an Advertisement Interval option on 345 Router Advertisements (equivalent to Agent Advertisements in 346 Mobile IPv4), allowing a mobile node to decide for itself how 347 many Router Advertisements (Agent Advertisements) it is willing 348 to miss before declaring its current router unreachable. 350 - The use of IPv6 destination options allows all Mobile IPv6 351 control traffic to be piggybacked on any existing IPv6 packets, 352 whereas in Mobile IPv4 and its Route Optimization extensions, 353 separate UDP packets were required for each control message. 355 3. Terminology 357 3.1. General Terms 359 IP 361 Internet Protocol Version 6 (IPv6). 363 node 365 A device that implements IP. 367 router 369 A node that forwards IP packets not explicitly addressed to 370 itself. 372 host 374 Any node that is not a router. 376 link 378 A communication facility or medium over which nodes can 379 communicate at the link layer, such as an Ethernet (simple or 380 bridged). A link is the layer immediately below IP. 382 interface 384 A node's attachment to a link. 386 subnet prefix 388 A bit string that consists of some number of initial bits of an 389 IP address. 391 interface identifier 393 A number used to identify a node's interface on a link. The 394 interface identifier is the remaining low-order bits in the 395 node's IP address after the subnet prefix. 397 link-layer address 399 A link-layer identifier for an interface, such as IEEE 802 400 addresses on Ethernet links. 402 packet 404 An IP header plus payload. 406 3.2. Mobile IPv6 Terms 408 home address 410 An IP address assigned to a mobile node within its home link. 412 home subnet prefix 414 The IP subnet prefix corresponding to a mobile node's home 415 address. 417 home link 419 The link on which a mobile node's home subnet prefix is 420 defined. Standard IP routing mechanisms will deliver packets 421 destined for a mobile node's home address to its home link. 423 mobile node 425 A node that can change its point of attachment from one link to 426 another, while still being reachable via its home address. 428 movement 430 A change in a mobile node's point of attachment to the Internet 431 such that it is no longer connected to the same link as it was 432 previously. If a mobile node is not currently attached to its 433 home link, the mobile node is said to be "away from home". 435 correspondent node 437 A peer node with which a mobile node is communicating. The 438 correspondent node may be either mobile or stationary. 440 foreign subnet prefix 442 Any IP subnet prefix other than the mobile node's home subnet 443 prefix. 445 foreign link 447 Any link other than the mobile node's home link. 449 home agent 451 A router on a mobile node's home link with which the mobile 452 node has registered its current care-of address. While the 453 mobile node is away from home, the home agent intercepts 454 packets on the home link destined to the mobile node's home 455 address, encapsulates them, and tunnels them to the mobile 456 node's registered care-of address. 458 care-of address 460 An IP address associated with a mobile node while visiting a 461 foreign link; the subnet prefix of this IP address is a foreign 462 subnet prefix. Among the multiple care-of addresses that a 463 mobile node may have at a time (e.g., with different subnet 464 prefixes), the one registered with the mobile node's home agent 465 is called its "primary" care-of address. 467 binding 469 The association of the home address of a mobile node with a 470 care-of address for that mobile node, along with the remaining 471 lifetime of that association. 473 3.3. Specification Language 475 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 476 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 477 document are to be interpreted as described in RFC 2119 [3]. 479 4. Overview of Mobile IPv6 481 4.1. Basic Operation 483 A mobile node is always addressable by its home address, whether it 484 is currently attached to its home link or is away from home. While 485 a mobile node is at home, packets addressed to its home address are 486 routed to it using conventional Internet routing mechanisms in the 487 same way as if the node were never mobile. Since the subnet prefix 488 of a mobile node's home address is the subnet prefix (or one of the 489 subnet prefixes) on the mobile node's home link (it is the mobile 490 node's home subnet prefix), packets addressed to it will be routed to 491 its home link. 493 While a mobile node is attached to some foreign link away from home, 494 it is also addressable by one or more care-of addresses, in addition 495 to its home address. A care-of address is an IP address associated 496 with a mobile node while visiting a particular foreign link. The 497 subnet prefix of a mobile node's care-of address is the subnet prefix 498 (or one of the subnet prefixes) on the foreign link being visited by 499 the mobile node; if the mobile node is connected to this foreign link 500 while using that care-of address, packets addressed to this care-of 501 address will be routed to the mobile node in its location away from 502 home. 504 The association between a mobile node's home address and care-of 505 address is known as a "binding" for the mobile node. A mobile node 506 typically acquires its care-of address through stateless [27] or 507 stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according 508 to the methods of IPv6 Neighbor Discovery [17]. Other methods 509 of acquiring a care-of address are also possible, such as static 510 pre-assignment by the owner or manager of a particular foreign link, 511 but details of such other methods are beyond the scope of this 512 document. 514 While away from home, a mobile node registers one of its care-of 515 addresses with a router on its home link, requesting this router 516 to function as the "home agent" for the mobile node. This binding 517 registration is done by the mobile node sending to the home agent 518 a packet containing a "Binding Update" destination option; the 519 home agent then replies to the mobile node by returning a packet 520 containing a "Binding Acknowledgement" destination option. The 521 care-of address in this binding registered with its home agent is 522 known as the mobile node's "primary care-of address". The mobile 523 node's home agent thereafter uses proxy Neighbor Discovery to 524 intercept any IPv6 packets addressed to the mobile node's home 525 address (or home addresses) on the home link, and tunnels each 526 intercepted packet to the mobile node's primary care-of address. 527 To tunnel each intercepted packet, the home agent encapsulates the 528 packet using IPv6 encapsulation [4], with the outer IPv6 header 529 addressed to the mobile node's primary care-of address. 531 Section 10.17 discusses the reasons why it may be desirable for 532 a mobile node to use more than one care-of address at the same 533 time. However, a mobile node's primary care-of address is distinct 534 among these in that the home agent maintains only a single care-of 535 address registered for each mobile node, and always tunnels a mobile 536 node's packets intercepted from its home link to this mobile node's 537 registered primary care-of address. The home agent thus need not 538 implement any policy to determine which of possibly many care-of 539 addresses to which to tunnel each intercepted packet, leaving the 540 mobile node entirely in control of this policy by which of its 541 care-of addresses it registers with its home agent. 543 It is possible that while a mobile node is away from home, some nodes 544 on its home link may be reconfigured, such that the router that was 545 operating as the mobile node's home agent is replaced by a different 546 router serving this role. In this case, the mobile node may not 547 know the IP address of its own home agent. Mobile IPv6 provides a 548 mechanism, known as "dynamic home agent address discovery", that 549 allows a mobile node to dynamically discover the IP address of a home 550 agent on its home link with which it may register its care-of address 551 while away from home. The mobile node sends an ICMP "Home Agent 552 Address Discovery Request" message to the "Mobile IPv6 Home-Agents" 553 anycast address for its own home subnet prefix [10] and thus reaches 554 one of the (possibly many) routers on its home link currently 555 operating as a home agent. This home agent then returns an ICMP 556 "Home Agent Address Discovery Reply" message to the mobile node, 557 including a list of home agents on the home link. This list of home 558 agents is maintained by each home agent on the home link through use 559 of the Home Agent (H) bit in each home agent's periodic unsolicited 560 multicast Router Advertisements. 562 The Binding Update and Binding Acknowledgement destination options, 563 together with a "Binding Request" destination option, are also used 564 to allow IPv6 nodes communicating with a mobile node, to dynamically 565 learn and cache the mobile node's binding. When sending a packet 566 to any IPv6 destination, a node checks its cached bindings for an 567 entry for the packet's destination address. If a cached binding for 568 this destination address is found, the node uses an IPv6 Routing 569 header [6] (instead of IPv6 encapsulation) to route the packet to 570 the mobile node by way of the care-of address indicated in this 571 binding. If, instead, the sending node has no cached binding for 572 this destination address, the node sends the packet normally (with 573 no Routing header), and the packet is subsequently intercepted and 574 tunneled by the mobile node's home agent as described above. Any 575 node communicating with a mobile node is referred to in this document 576 as a "correspondent node" of the mobile node, and may itself be 577 either a stationary node or a mobile node. 579 Since a Binding Update, Binding Acknowledgement, and Binding Request 580 are each represented in a packet as an IPv6 destination option [6], 581 they may be included in any IPv6 packet. Any of these options can be 582 sent in either of two ways: 584 - A Binding Update, Binding Acknowledgement, or Binding Request can 585 be included within any IPv6 packet carrying any payload such as 586 TCP [25] or UDP [24]. 588 - A Binding Update, Binding Acknowledgement, or Binding Request can 589 be sent as a separate IPv6 packet containing no payload. In this 590 case, the Next Header field in the last extension header in the 591 packet is set to the value 59, to indicate "No Next Header" [6]. 593 Mobile IPv6 also defines one additional IPv6 destination option. 594 When a mobile node sends a packet while away from home, it will 595 generally set the Source Address in the packet's IPv6 header to one 596 of its current care-of addresses, and will also include a "Home 597 Address" destination option in the packet, giving the mobile node's 598 home address. Many routers implement security policies such as 599 "ingress filtering" [7] that do not allow forwarding of packets that 600 appear to have a Source Address that is not topologically correct. 601 By using the care-of address as the IPv6 header Source Address, 602 the packet will be able to pass normally through such routers, 603 yet ingress filtering rules will still be able to locate the true 604 topological source of the packet in the same way as packets from 605 non-mobile nodes. By also including the Home Address option in each 606 packet, the sending mobile node can communicate its home address to 607 the correspondent node receiving this packet, allowing the use of 608 the care-of address to be transparent above the Mobile IPv6 support 609 level (e.g., at the transport layer). The inclusion of a Home 610 Address option in a packet affects only the correspondent node's 611 receipt of this single packet; no state is created or modified in the 612 correspondent node as a result of receiving a Home Address option in 613 a packet. 615 4.2. New IPv6 Destination Options 617 As discussed in general in Section 4.1, the following four new IPv6 618 destination options are defined for Mobile IPv6: 620 Binding Update 622 A Binding Update option is used by a mobile node to notify 623 a correspondent node or the mobile node's home agent of its 624 current binding. The Binding Update sent to the mobile node's 625 home agent to register its primary care-of address is marked 626 as a "home registration". Any packet that includes a Binding 627 Update option MUST be protected by IPsec [13], as defined in 628 Section 4.4, to guard against malicious Binding Updates. The 629 Binding Update option and its specific IPsec requirements are 630 described in detail in Section 5.1. 632 Binding Acknowledgement 634 A Binding Acknowledgement option is used to acknowledge receipt 635 of a Binding Update, if an acknowledgement was requested 636 in the Binding Update. Any packet that includes a Binding 637 Acknowledgement option MUST be protected by IPsec [13], as 638 defined in Section 4.4, to guard against malicious Binding 639 Acknowledgements. The Binding Acknowledgement option and 640 its specific IPsec requirements are described in detail in 641 Section 5.2. 643 Binding Request 645 A Binding Request option is used to request a mobile node to 646 send to the requesting node a Binding Update containing the 647 mobile node's current binding. This option is typically used 648 by a correspondent node to refresh a cached binding for a 649 mobile node, when the cached binding is in active use but the 650 binding's lifetime is close to expiration. No authentication 651 is required for the Binding Request option. The Binding 652 Request option is described in detail in Section 5.3. 654 Home Address 656 A Home Address option is used in a packet sent by a mobile 657 node to inform the recipient of that packet of the mobile 658 node's home address. For packets sent by a mobile node while 659 away from home, the mobile node generally uses one of its 660 care-of addresses as the Source Address in the packet's IPv6 661 header. By including a Home Address option in the packet, the 662 correspondent node receiving the packet is able to substitute 663 the mobile node's home address for this care-of address when 664 processing the packet, thus making the use of the care-of 665 address transparent to the correspondent node. If the IP 666 header of a packet carrying a Home Address option is covered 667 by authentication, then the Home Address option MUST also be 668 covered by this authentication, but no other authentication is 669 required for the Home Address option. The Home Address option 670 is described in detail in Section 5.4. 672 Mobile IPv6 also defines a number of "sub-options" for use within 673 these destination options; if included, any sub-options MUST 674 appear after the fixed portion of the option data specified in this 675 document. The presence of such sub-options will be indicated by the 676 Option Length field within the option. When the Option Length is 677 greater than the length required for the option specified here, the 678 remaining octets are interpreted as sub-options. The encoding and 679 format of defined sub-options are described in Section 5.5. 681 4.3. Alignment Requirements for New Destination Options 683 IPv6 requires that options appearing in a Hop-by-Hop Options 684 header or Destination Options header be aligned in a packet so that 685 multi-octet values within the Option Data field of each option fall 686 on natural boundaries (i.e., fields of width n octets are placed 687 at an integer multiple of n octets from the start of the header, 688 for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar 689 alignment requirements, so that multi-octet values within the 690 Sub-Option Data field of each sub-option fall on natural boundaries. 691 The alignment requirement of an option or sub-option is specified in 692 this document using the standard notation used elsewhere for IPv6 693 alignment requirements [6]. Specifically, the notation xn+y means 694 that the Option Type or Sub-Option Type field must fall at an integer 695 multiple of x octets from the start of the header, plus y octets. 696 For example: 698 2n means any 2-octet offset from the start of the header. 700 8n+2 means any 8-octet offset from the start of the header, 701 plus 2 octets. 703 4.4. IPsec Requirements for New Destination Options 705 Any packet that includes a Binding Update or Binding Acknowledgement 706 option MUST be protected by IPsec [13] to guard against malicious 707 Binding Updates or Acknowledgements. Specifically, any packet that 708 includes a Binding Update or Binding Acknowledgement option MUST 709 utilize IPsec sender authentication, data integrity protection, and 710 replay protection. 712 Currently, Mobile IPv6 requires that this protection covering a 713 Binding Update or Binding Acknowledgement MUST be provided by use 714 of AH [11]. If another Security Association applied to the packet 715 for other reasons requires use of ESP [12], for example to encrypt 716 the transport layer data carried in the packet, this use of ESP 717 is not sufficient to satisfy the authentication requirements of 718 Mobile IPv6; instead, the packet MUST use both AH and ESP. Use of 719 ESP for protecting the Binding Update or Binding Acknowledgement is 720 not currently defined in this document, since ESP does not protect 721 the portion of the packet above the ESP header itself [12]. 723 4.5. New IPv6 ICMP Messages 725 Mobile IPv6 also introduces two new ICMP message types, for use in 726 the dynamic home agent address discovery mechanism. As discussed in 727 general in Section 4.1, the following two new ICMP message types are 728 used: 730 Home Agent Address Discovery Request 732 The ICMP Home Agent Address Discovery Request message is used 733 by a mobile node to initiate the dynamic home agent address 734 discovery mechanism. When attempting a home registration, the 735 mobile node may use this mechanism to discover the address of 736 one or more routers currently operating as home agents on its 737 home link, with which it may register while away from home. 738 The Home Agent Address Discovery Request message is described 739 in detail in Section 5.6. 741 Home Agent Address Discovery Reply 743 The ICMP Home Agent Address Discovery Reply message is used by 744 a home agent to respond to a mobile node using the dynamic home 745 agent address discovery mechanism. When a home agent receives 746 a Home Agent Address Discovery Request message, it replies with 747 a Home Agent Address Discovery Reply message, giving a list 748 of the routers on the mobile node's home link serving as home 749 agents. The Home Agent Address Discovery Reply message is 750 described in detail in Section 5.7. 752 4.6. Conceptual Data Structures 754 This document describes the Mobile IPv6 protocol in terms of the 755 following three conceptual data structures: 757 Binding Cache 759 A cache, maintained by each IPv6 node, of bindings for other 760 nodes. The Binding Cache MAY be implemented in any manner 761 consistent with the external behavior described in this 762 document, for example by being combined with the node's 763 Destination Cache as maintained by Neighbor Discovery [17]. 764 When sending a packet, the Binding Cache is searched before the 765 Neighbor Discovery conceptual Destination Cache [17] (i.e., any 766 Binding Cache entry for this destination SHOULD take precedence 767 over any Destination Cache entry for the same destination). 768 Each Binding Cache entry conceptually contains the following 769 fields: 771 - The home address of the mobile node for which this is the 772 Binding Cache entry. This field is used as the key for 773 searching the Binding Cache for the destination address of 774 a packet being sent. If the destination address of the 775 packet matches the home address in the Binding Cache entry, 776 this entry SHOULD be used in routing that packet. 778 - The care-of address for the mobile node indicated by 779 the home address field in this Binding Cache entry. If 780 the destination address of a packet being routed by a 781 node matches the home address in this entry, the packet 782 SHOULD be routed to this care-of address, as described in 783 Section 8.9, for packets originated by this node, or in 784 Section 9.6, if this node is the mobile node's home agent 785 and the packet was intercepted by it on the home link. 787 - A lifetime value, indicating the remaining lifetime 788 for this Binding Cache entry. The lifetime value is 789 initialized from the Lifetime field in the Binding Update 790 that created or last modified this Binding Cache entry. 791 Once the lifetime on this entry expires, the entry MUST be 792 deleted from the Binding Cache. 794 - A flag indicating whether or not this Binding Cache entry 795 is a "home registration" entry. 797 - A flag indicating whether or not this Binding Cache entry 798 represents a mobile node that should be advertised as a 799 router in proxy Neighbor Advertisements sent by this node 800 on its behalf. This flag is only valid if the Binding 801 Cache entry indicates that this is a "home registration" 802 entry. 804 - The value of the Prefix Length field received in the 805 Binding Update that created or last modified this Binding 806 Cache entry. This field is only valid if the "home 807 registration" flag is set on this Binding Cache entry. 809 - The maximum value of the Sequence Number field received 810 in previous Binding Updates for this mobile node home 811 address. The Sequence Number field is 16 bits long, 812 and all comparisons between Sequence Number values 813 MUST be performed modulo 2**16. For example, using an 814 implementation in the C programming language, a Sequence 815 Number value A is greater than another Sequence Number 816 value B if ((short)((a) - (b)) > 0), if a "short" data type 817 is a 16-bit signed integer. 819 - Recent usage information for this Binding Cache entry, as 820 needed to implement the cache replacement policy in use in 821 the Binding Cache and to assist in determining whether a 822 Binding Request should be sent when the lifetime on this 823 entry nears expiration. 825 - The time at which a Binding Request was last sent for this 826 entry, as needed to implement the rate limiting restriction 827 for sending Binding Requests. 829 An entry in a node's Binding Cache for which the node is 830 serving as a home agent is marked as a "home registration" 831 entry and SHOULD NOT be deleted by the home agent until the 832 expiration of its binding lifetime. Other Binding Cache 833 entries MAY be replaced at any time by any reasonable local 834 cache replacement policy but SHOULD NOT be unnecessarily 835 deleted. Any node's Binding Cache may contain at most one 836 entry for each mobile node home address. The contents of a 837 node's Binding Cache MUST NOT be changed in response to a Home 838 Address option in a received packet. 840 Binding Update List 842 A list, maintained by each mobile node, recording information 843 for each Binding Update sent by this mobile node, for which the 844 Lifetime sent in that Binding Update has not yet expired. The 845 Binding Update List includes all bindings sent by the mobile 846 node: those to correspondent nodes, those to the mobile node's 847 home agent, and those to a home agent on the link on which the 848 mobile node's previous care-of address is located. However, 849 for multiple Binding Updates sent to the same destination 850 address, the Binding Update List contains only the most recent 851 Binding Update (i.e., with the greatest Sequence Number value) 852 sent to that destination. The Binding Update List MAY be 853 implemented in any manner consistent with the external behavior 854 described in this document. Each Binding Update List entry 855 conceptually contains the following fields: 857 - The IP address of the node to which a Binding Update was 858 sent. This node might still have a Binding Cache entry 859 created or updated from this Binding Update, if the Binding 860 Update was successfully received by that node (e.g., not 861 lost by the network) and if that node has not deleted the 862 entry before its expiration (e.g., to reclaim space in its 863 Binding Cache for other entries). 865 - The home address for which that Binding Update was sent. 866 This will be one of the mobile node's home addresses for 867 most Binding Updates (Sections 10.6 and 10.8), but will 868 be the mobile node's previous care-of address for Binding 869 Updates sent to to establish forwarding from by a home 870 agent from this previous care-of address (Section 10.9). 872 - The care-of address sent in that Binding Update. This 873 value is necessary for the mobile node to determine if it 874 has sent a Binding Update giving its new care-of address to 875 this destination after changing its care-of address. 877 - The initial value of the Lifetime field sent in that 878 Binding Update. 880 - The remaining lifetime of that binding. This lifetime is 881 initialized from the Lifetime value sent in the Binding 882 Update and is decremented until it reaches zero, at which 883 time this entry MUST be deleted from the Binding Update 884 List. 886 - The maximum value of the Sequence Number field sent in 887 previous Binding Updates to this destination. The Sequence 888 Number field is 16 bits long, and all comparisons between 889 Sequence Number values MUST be performed modulo 2**16. 890 For example, using an implementation in the C programming 891 language, a Sequence Number value A is greater than another 892 Sequence Number value B if ((short)((a) - (b)) > 0), if a 893 "short" data type is a 16-bit signed integer. 895 - The time at which a Binding Update was last sent to this 896 destination, as needed to implement the rate limiting 897 restriction for sending Binding Updates. 899 - The state of any retransmissions needed for this Binding 900 Update, if the Acknowledge (A) bit was set in this Binding 901 Update. This state includes the time remaining until the 902 next retransmission attempt for the Binding Update, and the 903 current state of the exponential back-off mechanism for 904 retransmissions. 906 - A flag that, when set, indicates that future Binding 907 Updates should not be sent to this destination. The 908 mobile node sets this flag in the Binding Update List 909 entry when it receives an ICMP Parameter Problem, Code 2, 910 error message in response to a Binding Update sent to that 911 destination, as described in Section 10.14. 913 Home Agents List 915 A list, maintained by each home agent and each mobile node, 916 recording information about each home agent from which this 917 node has received a Router Advertisement in which the Home 918 Agent (H) bit is set, for which the remaining lifetime for 919 this list entry (defined below) has not yet expired. The 920 home agents list is thus similar to the Default Router 921 List conceptual data structure maintained by each host for 922 Neighbor Discovery [17], although the Home Agents List MAY be 923 implemented in any manner consistent with the external behavior 924 described in this document. 926 Each home agent maintains a separate Home Agents List for 927 each link on which it is serving as a home agent; this list 928 is used by a home agent in the dynamic home agent address 929 discovery mechanism. Each mobile node, while away from home, 930 also maintains a Home Agents List, to enable it to notify a 931 home agent on its previous link when it moves to a new link; a 932 mobile node MAY maintain a separate Home Agents List for each 933 link to which it is (or has recently) connected, or it MAY 934 maintain a single list for all links. Each Home Agents List 935 entry conceptually contains the following fields: 937 - The link-local IP address of a router on the link, that 938 this node currently believes is operating as a home agent 939 for that link. A new entry is created or an existing 940 entry is updated in the Home Agents List in response to 941 receipt of a valid Router Advertisement in which the Home 942 Agent (H) bit is set. The link-local address of the home 943 agent is learned through the Source Address of the Router 944 Advertisements received from it [17]. 946 - One or more global IP addresses for this home agent, 947 learned through Prefix Information options with the 948 Router Address (R) bit is set, received in Router 949 Advertisements from this link-local address. Global 950 addresses for the router in a Home Agents List entry MUST 951 be deleted once the prefix associated with that address is 952 no longer valid [17]. 954 - The remaining lifetime of this Home Agents List entry. If 955 a Home Agent Information Option is present in a Router 956 Advertisement received from a home agent, the lifetime of 957 the Home Agents List entry representing that home agent 958 is initialized from the Home Agent Lifetime field in the 959 option; otherwise, the lifetime is initialized from the 960 Router Lifetime field in the received Router Advertisement. 961 The Home Agents List entry lifetime is decremented until it 962 reaches zero, at which time this entry MUST be deleted from 963 the Home Agents List. 965 - The preference for this home agent; higher values 966 indicate a more preferable home agent. The preference 967 value is taken from the Home Agent Preference field (a 968 signed, twos-complement integer) in the received Router 969 Advertisement, if the Router Advertisement contains a Home 970 Agent Information Option, and is otherwise set to the 971 default value of 0. A home agent uses this preference in 972 ordering the Home Agents List returned in an ICMP Home 973 Agent Address Discovery message in response to a mobile 974 node's initiation of dynamic home agent address discovery. 975 A mobile node uses this preference in determining which 976 of the home agents on its previous link to notify when it 977 moves to a new link. 979 4.7. Binding Management 981 When a mobile node configures a new care-of address and decides to 982 use this new address as its primary care-of address, the mobile 983 node registers this new binding with its home agent by sending 984 the home agent a Binding Update. The mobile node indicates 985 that an acknowledgement is needed for this Binding Update and 986 continues to periodically retransmit it until acknowledged. The 987 home agent acknowledges the Binding Update by returning a Binding 988 Acknowledgement to the mobile node. 990 When a mobile node receives a packet tunneled to it from its 991 home agent, the mobile node assumes that the original sending 992 correspondent node has no Binding Cache entry for the mobile node, 993 since the correspondent node would otherwise have sent the packet 994 directly to the mobile node using a Routing header. The mobile node 995 thus returns a Binding Update to the correspondent node, allowing 996 it to cache the mobile node's binding for routing future packets to 997 it. Although the mobile node may request an acknowledgement for 998 this Binding Update, it need not, since subsequent packets from the 999 correspondent node will continue to be intercepted and tunneled by 1000 the mobile node's home agent, effectively causing any needed Binding 1001 Update retransmission. 1003 A correspondent node with a Binding Cache entry for a mobile node 1004 may refresh this binding, for example if the binding's lifetime 1005 is near expiration, by sending a Binding Request to the mobile 1006 node. Normally, a correspondent node will only refresh a Binding 1007 Cache entry in this way if it is actively communicating with the 1008 mobile node and has indications, such as an open TCP connection to 1009 the mobile node, that it will continue this communication in the 1010 future. When a mobile node receives a Binding Request, it replies by 1011 returning a Binding Update to the node sending the Binding Request. 1013 A mobile node may use more than one care-of address at the same 1014 time, although only one care-of address may be registered for it at 1015 its home agent as its primary care-of address. The mobile node's 1016 home agent will tunnel all intercepted packets for the mobile node 1017 to its (single) registered primary care-of address, but the mobile 1018 node will accept packets that it receives at any of its current 1019 care-of addresses. Use of more than one care-of address by a mobile 1020 node may be useful, for example, to improve smooth handoff when the 1021 mobile node moves from one wireless link to another. If each of 1022 these wireless links is connected to the Internet through a separate 1023 base station, such that the wireless transmission range from the 1024 two base stations overlap, the mobile node may be able to remain 1025 connected to both links while in the area of overlap. In this case, 1026 the mobile node could acquire a new care-of address on the new link 1027 before moving out of transmission range and disconnecting from the 1028 old link. The mobile node may thus still accept packets at its 1029 old care-of address while it works to update its home agent and 1030 correspondent nodes, notifying them of its new care-of address on the 1031 new link. 1033 Since correspondent nodes cache bindings, it is expected that 1034 correspondent nodes usually will route packets directly to the mobile 1035 node's care-of address, so that the home agent is rarely involved 1036 with packet transmission to the mobile node. This is essential for 1037 scalability and reliability, and for minimizing overall network load. 1038 By caching the care-of address of a mobile node, optimal routing of 1039 packets can be achieved from the correspondent node to the mobile 1040 node. Routing packets directly to the mobile node's care-of address 1041 also eliminates congestion at the mobile node's home agent and home 1042 link. In addition, the impact of any possible failure of the home 1043 agent, the home link, or intervening networks leading to or from the 1044 home link is reduced, since these nodes and links are not involved in 1045 the delivery of most packets to the mobile node. 1047 5. New IPv6 Destination Options and Message Types 1049 5.1. Binding Update Option 1051 The Binding Update destination option is used by a mobile node 1052 to notify other nodes of a new care-of address for itself. As a 1053 destination option, it MAY be included in any existing packet being 1054 sent to this same destination or MAY be sent in a packet by itself; 1055 a packet containing a Binding Update is sent in the same way as any 1056 packet sent by a mobile node (Section 10.1). 1058 The Binding Update option is encoded in type-length-value (TLV) 1059 format as follows: 1061 0 1 2 3 1062 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Option Type | Option Length | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 |A|H|R|D|Reservd| Prefix Length | Sequence Number | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Lifetime | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Sub-Options... 1071 +-+-+-+-+-+-+-+-+-+-+-+- 1073 Option Type 1075 198 = 0xC6 1077 Option Length 1079 8-bit unsigned integer. Length of the option, in octets, 1080 excluding the Option Type and Option Length fields. This field 1081 MUST be set to 8 plus the total length of all sub-options 1082 present, including their Sub-Option Type and Sub-Option Len 1083 fields. 1085 Acknowledge (A) 1087 The Acknowledge (A) bit is set by the sending mobile node to 1088 request a Binding Acknowledgement (Section 5.2) be returned 1089 upon receipt of the Binding Update. 1091 Home Registration (H) 1093 The Home Registration (H) bit is set by the sending mobile node 1094 to request the receiving node to act as this node's home agent. 1095 The destination of the packet carrying this option MUST be that 1096 of a router sharing the same subnet prefix as the home address 1097 of the mobile node in the binding (given by the Home Address 1098 field in the Home Address option in the packet). 1100 Router (R) 1102 The Router (R) bit, when set, indicates that the sending 1103 mobile node is a router. This bit is only valid when the 1104 Home Registration (H) bit is also set, and MUST NOT be set 1105 otherwise. This bit is saved in the home agent's "home 1106 registration" Binding Cache entry for the mobile node, and 1107 is copied into the corresponding bit in all proxy Neighbor 1108 Advertisement messages sent on behalf of this mobile node by 1109 the home agent using this Binding Cache entry. 1111 Duplicate Address Detection (D) 1113 The Duplicate Address Detection (D) bit is set by the sending 1114 mobile node to request the receiving node (the mobile node's 1115 home agent) to perform Duplicate Address Detection [27] on 1116 the mobile node's home link for the home address in this 1117 binding. This bit is only valid when the Home Registration (H) 1118 and Acknowledge (A) bits are also set, and MUST NOT be set 1119 otherwise. If the Duplicate Address Detection performed by 1120 the home agent fails, the Status field in the returned Binding 1121 Acknowledgement will be set to 138 (Duplicate Address Detection 1122 failed). The mobile node SHOULD set the Duplicate Address 1123 Detection (D) bit based on any requirements for Duplicate 1124 Address Detection that would apply to the mobile node if it 1125 were at home [17, 27]. 1127 Reservd 1129 This field is unused. It MUST be initialized to zero by the 1130 sender and MUST be ignored by the receiver. 1132 Prefix Length 1134 The Prefix Length field is valid only for a "home registration" 1135 Binding Update; this field MUST be zero if the Home 1136 Registration (H) bit is not set in the Binding Update. The 1137 Prefix Length field is set by the sending mobile node to the 1138 (nonzero) length of its subnet prefix in its home address 1139 (given in the Home Address option in the packet) to request 1140 its home agent to use the interface identifier in the mobile 1141 node's home address (the remaining low-order bits after the 1142 indicated subnet prefix) to form all other home addresses for 1143 the mobile node on the home link. The home agent becomes the 1144 home agent not only for the individual home address given in 1145 this binding, but also for all other home addresses for this 1146 mobile node formed from this interface identifier. That is, 1147 for each on-link prefix on the home link, the home agent uses 1148 the interface identifier to form other valid addresses for 1149 the mobile node on the home link, and acts as a home agent 1150 also for those addresses. In addition, the home agent forms 1151 the link-local address and site-local address corresponding 1152 to this interface identifier, and defends each for purposes 1153 of Duplicate Address Detection. The home agent also performs 1154 Duplicate Address Detection on each such address as part of 1155 the home registration processing (before returning the Binding 1156 Acknowledgement), if the Duplicate Address Detection (D) bit 1157 is set in the Binding Update. Details of this operation are 1158 described in Section 9.3. 1160 Sequence Number 1162 Used by the receiving node to sequence Binding Updates and by 1163 the sending node to match a returned Binding Acknowledgement 1164 with this Binding Update. Each Binding Update sent by a mobile 1165 node MUST use a Sequence Number greater than the Sequence 1166 Number value sent in the previous Binding Update (if any) to 1167 the same destination address (modulo 2**16, as defined in 1168 Section overview:data). There is no requirement, however, that 1169 the Sequence Number value strictly increase by 1 with each new 1170 Binding Update sent or received. 1172 Lifetime 1174 32-bit unsigned integer. The number of seconds remaining 1175 before the binding MUST be considered expired. A value of all 1176 one bits (0xffffffff) indicates infinity. A value of zero 1177 indicates that the Binding Cache entry for the mobile node MUST 1178 be deleted. 1180 Sub-Options 1182 Additional information, associated with this Binding Update 1183 option, that need not be present in all Binding Updates sent. 1184 This use of sub-options also allows for future extensions to 1185 the format of the Binding Update option to be defined. The 1186 encoding and format of defined sub-options are described in 1187 Section 5.5. The following sub-options are valid in a Binding 1188 Update option: 1190 - Unique Identifier Sub-Option 1192 - Alternate Care-of Address Sub-Option 1194 The alignment requirement [6] for the Binding Update option is 4n+2. 1196 Any packet that includes a Binding Update option MUST also include 1197 a Home Address option. The home address of the mobile node in the 1198 binding given in the Binding Update option is indicated by the Home 1199 Address field in the Home Address option in the packet. 1201 The care-of address for the binding given in the Binding Update 1202 option is normally specified by the Source Address field in the IPv6 1203 header of the packet carrying the Binding Update option. However, a 1204 care-of address different from the Source Address MAY be specified 1205 by including an Alternate Care-of Address sub-option in the Binding 1206 Update option. 1208 Any packet that includes a Binding Update option MUST be protected by 1209 IPsec [13] to guard against malicious Binding Updates. The specific 1210 requirements for this protection are defined in Section 4.4. 1212 If the care-of address for the binding (specified either in an 1213 Alternate Care-of Address sub-option in the Binding Update option, if 1214 present, or in the Source Address field in the packet's IPv6 header) 1215 is equal to the home address of the mobile node, the Binding Update 1216 option indicates that any existing binding for the mobile node MUST 1217 be deleted. Likewise, if the Lifetime field in the Binding Update 1218 option is equal to 0, the Binding Update option indicates that any 1219 existing binding for the mobile node MUST be deleted. In each of 1220 these cases, a Binding Cache entry for the mobile node MUST NOT be 1221 created in response to receiving the Binding Update. 1223 The last Sequence Number value sent to a destination in a Binding 1224 Update is stored by the mobile node in its Binding Update List entry 1225 for that destination; the last Sequence Number value received from 1226 a mobile node in a Binding Update is stored by a correspondent node 1227 in its Binding Cache entry for that mobile node. Thus, the mobile 1228 node's and the correspondent node's knowledge of the last sequence 1229 number expire at the same time. If the sending mobile node has no 1230 Binding Update List entry, the Sequence Number may start at any 1231 value; if the receiving correspondent node has no Binding Cache entry 1232 for the sending mobile node, it MUST accept any Sequence Number value 1233 in a received Binding Update from this mobile node. 1235 The three highest-order bits of the Option Type are encoded to 1236 indicate specific processing of the option [6]. For the Binding 1237 Update option, these three bits are set to 110, indicating that any 1238 IPv6 node processing this option that does not recognize the Option 1239 Type must discard the packet and, only if the packet's Destination 1240 Address was not a multicast address, return an ICMP Parameter 1241 Problem, Code 2, message to the packet's Source Address; and that the 1242 data within the option cannot change en-route to the packet's final 1243 destination. 1245 5.2. Binding Acknowledgement Option 1247 The Binding Acknowledgement destination option is used to acknowledge 1248 receipt of a Binding Update option (Section 5.1). When a node 1249 receives a packet containing a Binding Update option, with this 1250 node being the destination of the packet (only the destination node 1251 processes the option since it is a destination option), this node 1252 MUST return a Binding Acknowledgement to the source of the packet, 1253 if the Acknowledge (A) bit is set in the Binding Update. As a 1254 destination option, this node MAY include the Binding Acknowledgement 1255 in any existing packet being sent to the mobile node or MAY send it 1256 in a packet by itself. A packet containing a Binding Acknowledgement 1257 is sent in the same way as any packet to a mobile node, using a 1258 Routing header to route the packet to the mobile node by way of the 1259 care-of address in the binding (Section 8.9). 1261 The Binding Acknowledgement option is encoded in type-length-value 1262 (TLV) format as follows: 1264 0 1 2 3 1265 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 1266 +-+-+-+-+-+-+-+-+ 1267 | Option Type | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Option Length | Status | Sequence Number | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Lifetime | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Refresh | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Sub-Options... 1276 +-+-+-+-+-+-+-+-+-+-+-+- 1278 Option Type 1280 7 1282 Option Length 1284 8-bit unsigned integer. Length of the option, in octets, 1285 excluding the Option Type and Option Length fields. This field 1286 MUST be set to 11 plus the total length of all sub-options 1287 present, including their Sub-Option Type and Sub-Option Len 1288 fields. 1290 Status 1292 8-bit unsigned integer indicating the disposition of the 1293 Binding Update. Values of the Status field less than 128 1294 indicate that the Binding Update was accepted by the receiving 1295 node. The following such Status values are currently defined: 1297 0 Binding Update accepted 1299 Values of the Status field greater than or equal to 128 1300 indicate that the Binding Update was rejected by the receiving 1301 node. The following such Status values are currently defined: 1303 128 Reason unspecified 1304 130 Administratively prohibited 1305 131 Insufficient resources 1306 132 Home registration not supported 1307 133 Not home subnet 1308 136 Incorrect interface identifier length 1309 137 Not home agent for this mobile node 1310 138 Duplicate Address Detection failed 1312 Up-to-date values of the Status field are to be specified in 1313 the most recent "Assigned Numbers" [26]. 1315 Sequence Number 1317 The Sequence Number in the Binding Acknowledgement is copied 1318 from the Sequence Number field in the Binding Update being 1319 acknowledged, for use by the mobile node in matching this 1320 Acknowledgement with an outstanding Binding Update. 1322 Lifetime 1324 The granted lifetime, in seconds, for which this node will 1325 attempt to retain the entry for this mobile node in its Binding 1326 Cache. If the node sending the Binding Acknowledgement is 1327 serving as the mobile node's home agent, the Lifetime period 1328 also indicates the period for which this node will continue 1329 this service; if the mobile node requires home agent service 1330 from this node beyond this period, the mobile node MUST send a 1331 new Binding Update to it before the expiration of this period 1332 (even if it is not changing its primary care-of address), in 1333 order to extend the lifetime. The value of this field is 1334 undefined if the Status field indicates that the Binding Update 1335 was rejected. 1337 Refresh 1339 The recommended interval, in seconds, at which the mobile 1340 node SHOULD send a new Binding Update to this node in order 1341 to "refresh" the mobile node's binding in this node's Binding 1342 Cache. This refreshing of the binding is useful in case the 1343 node fails and loses its cache state. The Refresh period is 1344 determined by the node sending the Binding Acknowledgement 1345 (the node caching the binding). If this node is serving as 1346 the mobile node's home agent, the Refresh value may be set, 1347 for example, based on whether the node stores its Binding 1348 Cache in volatile storage or in nonvolatile storage. If the 1349 node sending the Binding Acknowledgement is not serving as the 1350 mobile node's home agent, the Refresh period SHOULD be set 1351 equal to the Lifetime period in the Binding Acknowledgement; 1352 even if this node loses this cache entry due to a failure of 1353 the node, packets from it can still reach the mobile node 1354 through the mobile node's home agent, causing a new Binding 1355 Update to this node to allow it to recreate this cache entry. 1356 The value of this field is undefined if the Status field 1357 indicates that the Binding Update was rejected. 1359 Sub-Options 1361 Additional information, associated with this Binding 1362 Acknowledgement option, that need not be present in all Binding 1363 Acknowledgements sent. This use of sub-options also allows for 1364 future extensions to the format of the Binding Acknowledgement 1365 option to be defined. The encoding and format of defined 1366 sub-options are described in Section 5.5. Currently, no valid 1367 sub-options are defined for in a Binding Acknowledgement 1368 option. 1370 The alignment requirement [6] for the Binding Acknowledgement option 1371 is 4n+3. 1373 Any packet that includes a Binding Acknowledgement option MUST 1374 be protected by IPsec [13] to guard against malicious Binding 1375 Acknowledgements. The specific requirements for this protection are 1376 defined in Section 4.4. 1378 If the node returning the Binding Acknowledgement accepted the 1379 Binding Update for which the Acknowledgement is being returned (the 1380 value of the Status field in the Acknowledgement is less than 128), 1381 this node will have an entry for the mobile node in its Binding Cache 1382 and MUST use this entry (which includes the care-of address received 1383 in the Binding Update) in sending the packet containing the Binding 1384 Acknowledgement to the mobile node. The details of sending this 1385 packet to the mobile node are the same as for sending any packet to a 1386 mobile node using a binding, and are described in Section 8.9. The 1387 packet is sent using a Routing header, routing the packet to the 1388 mobile node by way of its care-of address recorded in the Binding 1389 Cache entry. 1391 If the node returning the Binding Acknowledgement instead 1392 rejected the Binding Update (the value of the Status field in the 1393 Acknowledgement is greater than or equal to 128), this node MUST 1394 similarly use a Routing header in sending the packet containing the 1395 Binding Acknowledgement, as described in Section 8.9, but MUST NOT 1396 use its Binding Cache in forming the IP header or Routing header 1397 in this packet. Rather, the care-of address used by this node in 1398 sending the packet containing the Binding Acknowledgement MUST be 1399 copied from the care-of address received in the rejected Binding 1400 Update; this node MUST NOT modify its Binding Cache in response 1401 to receiving this rejected Binding Update and MUST ignore its 1402 Binding Cache in sending the packet in which it returns this Binding 1403 Acknowledgement. The packet is sent using a Routing header, routing 1404 the packet to the home address of the rejected Binding Update by 1405 way of the care-of address indicated in the packet containing the 1406 Binding Update. When sending a Binding Acknowledgement to reject a 1407 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 1408 packet containing no payload (with the Next Header field in the last 1409 extension header in the packet set to indicate "No Next Header" [6]). 1411 The three highest-order bits of the Option Type are encoded to 1412 indicate specific processing of the option [6]. For the Binding 1413 Acknowledgement option, these three bits are set to 000, indicating 1414 that any IPv6 node processing this option that does not recognize the 1415 Option Type must skip over this option and continue processing the 1416 header, and that the data within the option cannot change en-route to 1417 the packet's final destination. 1419 5.3. Binding Request Option 1421 The Binding Request destination option is used to request a mobile 1422 node's binding from the mobile node. As a destination option, it 1423 MAY be included in any existing packet being sent to the mobile 1424 node or MAY be sent in a packet by itself; a packet containing a 1425 Binding Request option is sent in the same way as any packet to a 1426 mobile node (Section 8.9). When a mobile node receives a packet 1427 containing a Binding Request option, it SHOULD return a Binding 1428 Update (Section 5.1) to the source of the Binding Request. 1430 The Binding Request option is encoded in type-length-value (TLV) 1431 format as follows: 1433 0 1 1434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1436 | Option Type | Option Length | Sub-Options... 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1439 Option Type 1441 8 1443 Option Length 1445 8-bit unsigned integer. Length of the option, in octets, 1446 excluding the Option Type and Option Length fields. This field 1447 MUST be set to 0 plus the total length of all sub-options 1448 present, including their Sub-Option Type and Sub-Option Len 1449 fields. 1451 Sub-Options 1453 Additional information, associated with this Binding Request 1454 option, that need not be present in all Binding Requests sent. 1455 This use of sub-options also allows for future extensions to 1456 the format of the Binding Request option to be defined. The 1457 encoding and format of defined sub-options are described in 1458 Section 5.5. The following sub-options are valid in a Binding 1459 Request option: 1461 - Unique Identifier Sub-Option 1463 There is no requirement for alignment [6] of the Binding Request 1464 option. 1466 The three highest-order bits of the Option Type are encoded to 1467 indicate specific processing of the option [6]. For the Binding 1468 Request option, these three bits are set to 000, indicating that any 1469 IPv6 node processing this option that does not recognize the Option 1470 Type must skip over this option and continue processing the header, 1471 and that the data within the option cannot change en-route to the 1472 packet's final destination. 1474 5.4. Home Address Option 1476 The Home Address destination option is used in a packet sent by a 1477 mobile node while away from home, to inform the recipient of that 1478 packet of the mobile node's home address. For packets sent by a 1479 mobile node while away from home, the mobile node generally uses 1480 one of its care-of addresses as the Source Address in the packet's 1481 IPv6 header. By including a Home Address option in the packet, the 1482 correspondent node receiving the packet is able to substitute the 1483 mobile node's home address for this care-of address when processing 1484 the packet, thus making the use of the care-of address transparent to 1485 the correspondent node. 1487 The Home Address option is encoded in type-length-value (TLV) format 1488 as follows: 1490 0 1 2 3 1491 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 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Option Type | Option Length | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | | 1496 + + 1497 | | 1498 + Home Address + 1499 | | 1500 + + 1501 | | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Sub-Options... 1504 +-+-+-+-+-+-+-+-+-+-+-+- 1506 Option Type 1508 201 = 0xC9 1510 Option Length 1512 8-bit unsigned integer. Length of the option, in octets, 1513 excluding the Option Type and Option Length fields. This field 1514 MUST be set to 16 plus the total length of all sub-options 1515 present, including their Sub-Option Type and Sub-Option Len 1516 fields. 1518 Home Address 1520 The home address of the mobile node sending the packet. 1522 Sub-Options 1524 Additional information, associated with this Home Address 1525 option, that need not be present in all Home Address options 1526 sent. This use of sub-options also allows for future 1527 extensions to the format of the Home Address option to be 1528 defined. The encoding and format of defined sub-options are 1529 described in Section 5.5. Currently, no valid sub-options are 1530 defined for use in a Home Address option. 1532 The alignment requirement [6] for the Home Address option is 8n+6. 1534 The inclusion of a Home Address option in a packet affects the 1535 receiving node's processing of only this single packet; no state is 1536 created or modified in the receiving node as a result of receiving a 1537 Home Address option in a packet. In particular, the presence of a 1538 Home Address option in a received packet MUST NOT alter the contents 1539 of the receiver's Binding Cache and MUST NOT cause any changes in the 1540 routing of subsequent packets sent by this receiving node. 1542 No authentication of the Home Address option is required, except that 1543 if the IPv6 header of a packet is covered by authentication, then 1544 that authentication MUST also cover the Home Address option; this 1545 coverage is achieved automatically by the definition of the Option 1546 Type code for the Home Address option, since it indicates that the 1547 data within the option cannot change en-route to the packet's final 1548 destination, and thus the option is included in the authentication 1549 computation. If the packet carries no IP authentication, then the 1550 contents of the Home Address option, as well as the Source Address 1551 field or any other field in the IPv6 header, may have been forged or 1552 altered during transit. 1554 Upon receipt of a packet containing a Home Address option, the 1555 receiving node replaces the Source Address in the IPv6 header with 1556 the Home Address in the Home Address option. By requiring that any 1557 authentication of the IPv6 header also cover the Home Address option, 1558 the security of the Source Address field in the IPv6 header is not 1559 compromised by the presence of a Home Address option. Security 1560 issues related to the Home Address option are discussed further in 1561 Section 13. 1563 A packet MUST NOT contain more than one Home Address option, except 1564 that an encapsulated packet [4] MAY contain a separate Home Address 1565 option associated with each encapsulating IP header. 1567 The three highest-order bits of the Option Type are encoded to 1568 indicate specific processing of the option [6]. For the Home Address 1569 option, these three bits are set to 110, indicating that any IPv6 1570 node processing this option that does not recognize the Option Type 1571 must discard the packet and, only if the packet's Destination Address 1572 was not a multicast address, return an ICMP Parameter Problem, 1573 Code 2, message to the packet's Source Address; and that the data 1574 within the option cannot change en-route to the packet's final 1575 destination. 1577 5.5. Mobile IPv6 Destination Option Sub-Options 1579 In order to allow optional fields that may not be needed in most uses 1580 of any given Mobile IPv6 destination option, and to allow future 1581 extensions to the format of these destination options to be defined, 1582 any of the Mobile IPv6 destination options defined in this document 1583 MAY include one or more sub-options. 1585 Such sub-options are included in the data portion of the destination 1586 option itself, after the fixed portion of the option data specified 1587 for that particular destination option (Sections 5.1 through 5.4). 1588 The presence of such sub-options will be indicated by the Option 1589 Length field. When the Option Length is greater than the standard 1590 length defined for that destination option, the remaining octets are 1591 interpreted as sub-options. 1593 These sub-options are encoded within the remaining space of the 1594 option data for that option, using a type-length-value (TLV) format 1595 as follows: 1597 0 1 2 3 1598 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 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 |Sub-Option Type| Sub-Option Len| Sub-Option Data... 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 Sub-Option Type 1605 8-bit identifier of the type of sub-option. In processing a 1606 Mobile IPv6 destination option containing a sub-option for 1607 which the Sub-Option Type value is not recognized by the 1608 receiver, the receiver SHOULD quietly ignore and skip over the 1609 sub-option, correctly handling any remaining sub-options in the 1610 option. 1612 Sub-Option Length 1614 8-bit unsigned integer. Length of the Sub-Option Data field 1615 of this sub-option, in octets. The Sub-Option Len does not 1616 include the length of the Sub-Option Type and Sub-Option Len 1617 fields. 1619 Sub-Option Data 1621 Variable-length field. Sub-Option-Type-specific data. 1623 As with IPv6 options appearing in a Hop-by-Hop Options header 1624 or Destination Options header [6], individual sub-options within 1625 a Mobile IPv6 destination option may have specific alignment 1626 requirements, to ensure that multi-octet values within Sub-Option 1627 Data fields fall on natural boundaries. The alignment requirement 1628 of each sub-option is specified as part of the definition of each 1629 sub-option below. 1631 Each section above defining the Mobile IPv6 destination options 1632 specifies which of the defined sub-options is valid for that 1633 destination option. In addition, there are two padding sub-options, 1634 Pad1 and PadN (defined below), which are used when necessary to align 1635 subsequent sub-options. The Pad1 and PadN sub-options are valid for 1636 all Mobile IPv6 destination options. Unlike the padding options 1637 used in Hop-by-Hop Options header or Destination Options header [6], 1638 there is no requirement for padding the total size of any Mobile IPv6 1639 destination option to a multiple of 8 octets in length, and the 1640 Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All 1641 Mobile IPv6 sub-options defined in this document MUST be recognized 1642 by all Mobile IPv6 implementations. 1644 Currently, the following sub-option types are defined for use in 1645 Mobile IPv6 destination options: 1647 Pad1 Sub-Option (alignment requirement: none) 1649 0 1650 0 1 2 3 4 5 6 7 1651 +-+-+-+-+-+-+-+-+ 1652 | 0 | 1653 +-+-+-+-+-+-+-+-+ 1655 NOTE! the format of the Pad1 sub-option is a special 1656 case -- it does not have Sub-Option Len and Sub-Option Data 1657 fields. 1659 The Pad1 sub-option is used to insert one octet of padding 1660 into the Sub-Options area of a Mobile IPv6 option. If more 1661 than one octet of padding is required, the PadN sub-option, 1662 described next, should be used, rather than multiple Pad1 1663 sub-options. 1665 PadN Sub-Option (alignment requirement: none) 1667 0 1 1668 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1670 | 1 | Sub-Option Len| Sub-Option Data 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1673 The PadN sub-option is used to insert two or more octets of 1674 padding into the Sub-Options area of a Mobile IPv6 option. 1675 For N octets of padding, the Sub-Option Len field contains 1676 the value N-2, and the Sub-Option Data consists of N-2 1677 zero-valued octets. 1679 Unique Identifier Sub-Option (alignment requirement: 2n) 1681 0 1 2 3 1682 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 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | 2 | 2 | Unique Identifier | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 The Unique Identifier sub-option is valid only in Binding 1688 Request and Binding Update destination options. The Unique 1689 Identifier field contains a 16-bit value that serves to 1690 uniquely identify a Binding Request among those sent by this 1691 Source Address, and to allow the Binding Update to identify 1692 the specific Binding Request to which it responds. This 1693 matching of Binding Updates to Binding Requests is required 1694 in the procedure for renumbering the home subnet while a 1695 mobile node is away from home (Section 9.7). 1697 Alternate Care-of Address Sub-Option (alignment requirement: 8n+6) 1699 0 1 2 3 1700 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 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | 4 | 16 | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | | 1705 + + 1706 | | 1707 + Alternate Care-of Addresses + 1708 | | 1709 + + 1710 | | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 The Alternate Care-of Address sub-option is valid only in 1714 Binding Update destination options. The Alternate Care-of 1715 Address field contains an address to use as the care-of 1716 address for the binding, rather than using the Source 1717 Address of the packet as the care-of address. 1719 5.6. ICMP Home Agent Address Discovery Request Message 1721 The ICMP Home Agent Address Discovery Request message is used by a 1722 mobile node to initiate the dynamic home agent address discovery 1723 mechanism, as described in Sections 9.2 and 10.7. The mobile 1724 node sends a Home Agent Address Discovery Request message to the 1725 "Mobile IPv6 Home-Agents" anycast address for its own home subnet 1726 prefix [10], and one of the home agents there responds to the mobile 1727 node with a Home Agent Address Discovery Reply message giving a list 1728 of the routers on the mobile node's home link serving as home agents. 1730 0 1 2 3 1731 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 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Type | Code | Checksum | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Identifier | | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1737 | | 1738 + Reserved + 1739 | | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | | 1742 + + 1743 | | 1744 + Home Address + 1745 | | 1746 + + 1747 | | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 Type 1752 1754 Code 1756 0 1758 Checksum 1760 The ICMP checksum [5]. 1762 Identifier 1764 An identifier to aid in matching Home Agent Address Discovery 1765 Reply messages to this Home Agent Address Discovery Request 1766 message. 1768 Reserved 1770 This field is unused. It MUST be initialized to zero by the 1771 sender and MUST be ignored by the receiver. 1773 Home Address 1775 The home address of the mobile node sending the Home Agent 1776 Address Discovery Request message. 1778 The Source Address of the Home Agent Address Discovery Request 1779 message packet MUST be one of the mobile node's current care-of 1780 addresses, and the mobile node MUST NOT include a Home Address 1781 option in this packet; the home agent then MUST return the Home 1782 Agent Address Discovery Reply message directly to this care-of 1783 address. These restrictions are necessary, since at the time of 1784 performing this dynamic home agent address discovery, the mobile node 1785 is generally not registered with its home agent; using the mobile 1786 node's care-of address simplifies the return of the Reply message to 1787 the mobile node. 1789 5.7. ICMP Home Agent Address Discovery Reply Message 1791 The ICMP Home Agent Address Discovery Reply message is used by a 1792 home agent to respond to a mobile node using the dynamic home agent 1793 address discovery mechanism, as described in Sections 9.2 and 10.7. 1794 The mobile node sends a Home Agent Address Discovery Request message 1795 to the "Mobile IPv6 Home-Agents" anycast address for its own home 1796 subnet prefix [10], and one of the home agents there responds to the 1797 mobile node with a Home Agent Address Discovery Reply message giving 1798 a list of the routers on the mobile node's home link serving as home 1799 agents. 1801 0 1 2 3 1802 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 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Type | Code | Checksum | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Identifier | | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1808 | | 1809 + Reserved + 1810 | | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | | 1813 + + 1814 . . 1815 . Home Agent Addresses . 1816 . . 1817 + + 1818 | | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 Type 1823 1825 Code 1827 0 1829 Checksum 1831 The ICMP checksum [5]. 1833 Identifier 1835 The identifier from the invoking Home Agent Address Discovery 1836 Request message. 1838 Reserved 1840 This field is unused. It MUST be initialized to zero by the 1841 sender and MUST be ignored by the receiver. 1843 Home Agent Addresses 1845 A list of addresses of home agents on the home link for the 1846 mobile node. The number of addresses present in the list is 1847 indicated by the remaining length of the IPv6 packet carrying 1848 the Home Agent Address Discovery Reply message. 1850 6. Modifications to IPv6 Neighbor Discovery 1852 6.1. Modified Router Advertisement Message Format 1854 Mobile IPv6 modifies the format of the Router Advertisement 1855 message [17] by the addition of a single flag bit to indicate that 1856 the router sending the Advertisement message is serving as a home 1857 agent on this link. The format of the Router Advertisement message 1858 is as follows: 1860 0 1 2 3 1861 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 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Type | Code | Checksum | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Reachable Time | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Retrans Timer | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Options ... 1872 +-+-+-+-+-+-+-+-+-+-+-+- 1874 This format represents the following changes over that originally 1875 specified for Neighbor Discovery [17]: 1877 Home Agent (H) 1879 The Home Agent (H) bit is set in a Router Advertisement to 1880 indicate that the router sending this Router Advertisement is 1881 also functioning as a Mobile IP home agent on this link. 1883 Reserved 1885 Reduced from a 6-bit field to a 5-bit field to account for the 1886 addition of the Home Agent (H) bit. 1888 6.2. Modified Prefix Information Option Format 1890 Mobile IPv6 requires knowledge of a router's global address for two 1891 reasons: 1893 - To allow a home agent (a router) to learn the address of all 1894 other home agents on the link for which it is providing home 1895 agent service, for use in building its Home Agents List as 1896 part of the dynamic home agent address discovery mechanism 1897 (Sections 9.2 and 10.7). 1899 - To allow a mobile node to send a Binding Update to a router on 1900 the link on which its previous care-of address is located, for 1901 purposes of establishing forwarding from this previous care-of 1902 address to its new care-of address (Section 10.9). 1904 However, Neighbor Discovery [17] only advertises a router's 1905 link-local address, by requiring this address to be used as the IP 1906 Source Address of each Router Advertisement. 1908 Mobile IPv6 extends Neighbor Discovery to allow a router to easily 1909 and efficiently advertise its global address, by the addition of a 1910 single flag bit in the format of a Prefix Information option for 1911 use in Router Advertisement messages. The format of the Prefix 1912 Information option is as follows: 1914 0 1 2 3 1915 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 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Type | Length | Prefix Length |L|A|R|Reserved1| 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Valid Lifetime | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | Preferred Lifetime | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Reserved2 | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | | 1926 + + 1927 | | 1928 + Prefix + 1929 | | 1930 + + 1931 | | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 This format represents the following changes over that originally 1935 specified for Neighbor Discovery [17]: 1937 Router Address (R) 1939 1-bit router address flag. When set, indicates that the 1940 Prefix field, in addition to advertising the indicated prefix, 1941 contains a complete IP address assigned to the sending router. 1942 This router IP address has the same scope and conforms to the 1943 same lifetime values as the advertised prefix. This use of 1944 the Prefix field is compatible with its use in advertising 1945 the prefix itself, since prefix advertisement uses only the 1946 leading number Prefix bits specified by the Prefix Length 1947 field. Interpretation of this flag bit is thus independent 1948 of the processing required for the On-Link (L) and Autonomous 1949 Address-Configuration (A) flag bits. 1951 Reserved1 1953 Reduced from a 6-bit field to a 5-bit field to account for the 1954 addition of the Router Address (R) bit. 1956 In a solicited Router Advertisement, a router MUST include at least 1957 one Prefix Information option with the Router Address (R) bit set. 1958 Neighbor Discovery specifies that, if including all options in a 1959 Router Advertisement causes the size of the Advertisement to exceed 1960 the link MTU, multiple Advertisements can be sent, each containing 1961 a subset of the options [17]. In this case, at least one of these 1962 multiple Advertisements being sent instead of a single larger 1963 solicited Advertisement, MUST include a Prefix Information option 1964 with the Router Address (R) bit set. 1966 All routers SHOULD include at least one Prefix Information option 1967 with the Router Address (R) bit set, in each unsolicited multicast 1968 Router Advertisement that they send. If multiple Advertisements 1969 are being sent instead of a single larger unsolicited multicast 1970 Advertisement, at least one of these multiple Advertisements SHOULD 1971 include a Prefix Information option with the Router Address (R) bit 1972 set. 1974 6.3. New Advertisement Interval Option Format 1976 Mobile IPv6 defines a new Advertisement Interval option, used in 1977 Router Advertisement messages to advertise the interval at which the 1978 sending router sends unsolicited multicast Router Advertisements. 1979 The format of the Advertisement Interval option is as follows: 1981 0 1 2 3 1982 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 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | Type | Length | Reserved | 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 | Advertisement Interval | 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 Type 1991 7 1993 Length 1995 8-bit unsigned integer. The length of the option (including 1996 the type and length fields) in units of 8 octets. The value of 1997 this field MUST be 1. 1999 Reserved 2001 This field is unused. It MUST be initialized to zero by the 2002 sender and MUST be ignored by the receiver. 2004 Advertisement Interval 2006 32-bit unsigned integer. The maximum time, in milliseconds, 2007 between successive unsolicited router Router Advertisement 2008 messages sent by this router on this network interface. Using 2009 the conceptual router configuration variables defined by 2010 Neighbor Discovery [17], this field MUST be equal to the value 2011 MaxRtrAdvInterval, expressed in milliseconds. 2013 Routers MAY include this option in their Router Advertisements. A 2014 mobile node receiving a Router Advertisement containing this option 2015 SHOULD utilize the specified Advertisement Interval for that router 2016 in its movement detection algorithm, as described in Section 10.4. 2018 This option MUST be silently ignored for other Neighbor Discovery 2019 messages. 2021 6.4. New Home Agent Information Option Format 2023 Mobile IPv6 defines a new Home Agent Information option, used in 2024 Router Advertisement messages sent by a home agent to advertise 2025 information specific to this router's functionality as a home agent. 2026 The format of the Home Agent Information option is as follows: 2028 0 1 2 3 2029 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 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | Type | Length | Reserved | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | Home Agent Preference | Home Agent Lifetime | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 Type 2038 8 2040 Length 2042 8-bit unsigned integer. The length of the option (including 2043 the type and length fields) in units of 8 octets. The value of 2044 this field MUST be 1. 2046 Reserved 2048 This field is unused. It MUST be initialized to zero by the 2049 sender and MUST be ignored by the receiver. 2051 Home Agent Preference 2053 16-bit signed, twos-complement integer. The preference for 2054 the home agent sending this Router Advertisement, for use in 2055 ordering the addresses returned to a mobile node in the Home 2056 Agent Addresses field of a Home Agent Address Discovery Reply 2057 message. higher values mean more preferable. If this option 2058 is not included in a Router Advertisement in which the Home 2059 Agent (H) bit is set, the preference value for this home agent 2060 SHOULD be considered to be 0. Values greater than 0 indicate a 2061 home agent more preferable than this default value, and values 2062 less than 0 indicate a less preferable home agent. 2064 In addition to the manual configuration of the Home Agent 2065 Preference value as described in Section 7.3, the Home Agent 2066 Preference sent by a home agent could be set dynamically by the 2067 sending home agent, for example based on the number of mobile 2068 nodes it is currently serving or on its remaining resources for 2069 serving additional mobile nodes, but such dynamic settings are 2070 beyond the scope of this document. Any such dynamic setting 2071 of the Home Agent Preference, however, MUST be careful to set 2072 the preference appropriately, relative to the default Home 2073 Agent Preference value of 0 that may be in use by some home 2074 agents on this link (i.e., a home agent not including a Home 2075 Agent Information option in its Router Advertisements will be 2076 considered to have a Home Agent Preference value of 0). 2078 Home Agent Lifetime 2080 16-bit unsigned integer. The lifetime associated with the home 2081 agent in units of seconds. The maximum value corresponds to 2082 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 2083 Lifetime applies only to this router's usefulness as a home 2084 agent; it does not apply to information contained in other 2085 message fields or options. If this option is not included in 2086 a Router Advertisement in which the Home Agent (H) bit is set, 2087 the lifetime for this home agent SHOULD be considered to be the 2088 same as the Router Lifetime specified in the main body of the 2089 Router Advertisement message. 2091 Home agents MAY include this option in their Router Advertisements. 2092 This option MUST NOT be included in a Router Advertisement in which 2093 the Home Agent (H) bit (Section 6.1) is not set. 2095 This option MUST be silently ignored for other Neighbor Discovery 2096 messages. 2098 If both the Home Agent Preference and Home Agent Lifetime are set 2099 to their default values specified above, this option SHOULD NOT be 2100 included in the Router Advertisement messages sent by this home 2101 agent. 2103 6.5. Changes to Sending Router Advertisements 2105 The Neighbor Discovery protocol specification [17] limits routers to 2106 a minimum interval of 3 seconds between sending unsolicited multicast 2107 Router Advertisement messages from any given network interface 2108 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 2110 "Routers generate Router Advertisements frequently enough 2111 that hosts will learn of their presence within a few 2112 minutes, but not frequently enough to rely on an absence 2113 of advertisements to detect router failure; a separate 2114 Neighbor Unreachability Detection algorithm provides failure 2115 detection." 2117 This limitation, however, is not suitable to providing timely 2118 movement detection for mobile nodes. Mobile nodes detect their 2119 own movement by learning the presence of new routers as the mobile 2120 node moves into wireless transmission range of them (or physically 2121 connects to a new wired network), and by learning that previous 2122 routers are no longer reachable. Mobile nodes MUST be able to 2123 quickly detect when they move to a link served by a new router, so 2124 that they can acquire a new care-of address and send Binding Updates 2125 to register this care-of address with their home agent and to notify 2126 correspondent nodes as needed. 2128 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 2129 this limit such that routers MAY send unsolicited multicast Router 2130 Advertisements more frequently. In particular, on network interfaces 2131 where the router is expecting to provide service to visiting mobile 2132 nodes (e.g., wireless network interfaces), or on which it is serving 2133 as a home agent to one or more mobile nodes (who may return home and 2134 need to hear its Advertisements), the home agent SHOULD be configured 2135 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 2136 to allow sending of unsolicited multicast Router Advertisements more 2137 often. Recommended values for these limits are: 2139 - MinRtrAdvInterval 0.5 seconds 2141 - MaxRtrAdvInterval 1.5 seconds 2143 Use of these modified limits MUST be configurable, and specific 2144 knowledge of the type of network interface in use SHOULD be taken 2145 into account in configuring these limits for each network interface. 2147 When sending unsolicited multicast Router Advertisements more 2148 frequently than the standard limit on unsolicited multicast 2149 Advertisement frequency, the sending router need not include all 2150 options in each of these Advertisements, but it SHOULD include at 2151 least one Prefix Information option with the Router Address (R) bit 2152 set (Section 6.2) in each. 2154 6.6. Changes to Sending Router Solicitations 2156 In addition to the limit on routers sending unsolicited multicast 2157 Router Advertisement messages (Section 6.5), Neighbor Discovery 2158 defines limits on nodes sending Router Solicitation messages, such 2159 that a node SHOULD send no more than 3 Router Solicitations, and that 2160 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 2161 However, these limits prevent a mobile node from finding a new 2162 default router (and thus a new care-of address) quickly as it moves 2163 about. 2165 Mobile IPv6 relaxes this limit such that, while a mobile node is away 2166 from home, it MAY send Router Solicitations more frequently. The 2167 following limits for sending Router Solicitations are recommended for 2168 mobile nodes while away from home: 2170 - A mobile node that is not configured with any current care-of 2171 address (e.g., the mobile node has moved since its previous 2172 care-of address was configured), MAY send more than the defined 2173 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 2174 Solicitations. 2176 - The rate at which a mobile node sends Router Solicitations MUST 2177 be limited, although a mobile node MAY send Router Solicitations 2178 more frequently than the defined Neighbor Discovery limit of 2179 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 2180 be configurable, and specific knowledge of the type of network 2181 interface in use SHOULD be taken into account in configuring this 2182 limit for each network interface. A recommended minimum interval 2183 is 1 second. 2185 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 2186 a mobile node MUST reduce the rate at which it sends subsequent 2187 Router Solicitations. Subsequent Router Solicitations SHOULD 2188 be sent using a binary exponential backoff mechanism, doubling 2189 the interval between consecutive Router Solicitations, up to a 2190 maximum interval. The maximum interval MUST be configurable and 2191 SHOULD be chosen appropriately based on the characteristics of 2192 the type of network interface in use. 2194 - While still searching for a new default router and care-of 2195 address, a mobile node MUST NOT increase the rate at which it 2196 sends Router Solicitations unless it has received a positive 2197 indication (such as from lower network layers) that it has moved 2198 to a new link. After successfully acquiring a new care-of 2199 address, the mobile node SHOULD also increase the rate at which 2200 it will send Router Solicitations when it next begins searching 2201 for a new default router and care-of address. 2203 - A mobile node that is currently configured with a care-of 2204 address SHOULD NOT send Router Solicitations, until its movement 2205 detection algorithm (Section 10.4) determines that it has moved 2206 and that its current care-of address might no longer be valid. 2208 7. Requirements for IPv6 Nodes 2210 Mobile IPv6 places some special requirements on the functions 2211 provided by different types of IPv6 nodes. This section summarizes 2212 those requirements, identifying the functionality each requirement 2213 is intended to support. Further details on this functionality is 2214 provided in the following sections. 2216 7.1. Requirements for All IPv6 Hosts and Routers 2218 Since any IPv6 node may at any time be a correspondent node of a 2219 mobile node, either sending a packet to a mobile node or receiving a 2220 packet from a mobile node, the following requirements apply to ALL 2221 IPv6 nodes (whether host or router, whether mobile or stationary): 2223 - Every IPv6 node MUST be able to process a Home Address option 2224 received in any IPv6 packet. 2226 - Every IPv6 node SHOULD be able to process a Binding Update option 2227 received in a packet, and to return a Binding Acknowledgement 2228 option if the Acknowledge (A) bit is set in the received Binding 2229 Update. 2231 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 2232 bindings received in accepted Binding Updates. 2234 7.2. Requirements for All IPv6 Routers 2236 The following requirements apply to all IPv6 routers, even those not 2237 serving as a home agent for Mobile IPv6: 2239 - Every IPv6 router SHOULD be able to send an Advertisement 2240 Interval option in its Router Advertisements, to aid movement 2241 detection by mobile nodes. The use of this option in Router 2242 Advertisements MUST be configurable. 2244 - Every IPv6 router SHOULD be able to support sending unsolicited 2245 multicast Router Advertisements at the faster rate described in 2246 Section 6.5. The use of this faster rate MUST be configurable. 2248 7.3. Requirements for IPv6 Home Agents 2250 In order for a mobile node to operate correctly while away from home, 2251 at least one IPv6 router on the mobile node's home link must function 2252 as a home agent for the mobile node. The following additional 2253 requirements apply to all IPv6 routers capable of serving as a home 2254 agent: 2256 - Every home agent MUST be able to maintain an entry in its Binding 2257 Cache for each mobile node for which it is serving as the home 2258 agent. Each such Binding Cache entry records the mobile node's 2259 binding with its primary care-of address and is marked as a "home 2260 registration". 2262 - Every home agent MUST be able to intercept packets (using proxy 2263 Neighbor Discovery) addressed to a mobile node for which it is 2264 currently serving as the home agent, on that mobile node's home 2265 link, while the mobile node is away from home. 2267 - Every home agent MUST be able to encapsulate such intercepted 2268 packets in order to tunnel them to the primary care-of address 2269 for the mobile node indicated in its binding in the home agent's 2270 Binding Cache. 2272 - Every home agent MUST be able to return a Binding Acknowledgement 2273 option in response to a Binding Update option received with the 2274 Acknowledge (A) bit set. 2276 - Every home agent MUST maintain a separate Home Agents List for 2277 each link on which it is serving as a home agent, as described in 2278 Section 4.6. 2280 - Every home agent MUST be able to accept packets addressed to 2281 the "Mobile IPv6 Home-Agents" anycast address for the subnet 2282 on which it is serving as a home agent [10], and MUST be 2283 able to participate in dynamic home agent address discovery 2284 (Section 9.2). 2286 - Every home agent SHOULD support a configuration mechanism to 2287 allow a system administrator to manually set the value to be sent 2288 by this home agent in the Home Agent Preference field of the Home 2289 Agent Information Option in Router Advertisements that it sends. 2291 7.4. Requirements for IPv6 Mobile Nodes 2293 Finally, the following requirements apply to all IPv6 nodes capable 2294 of functioning as mobile nodes: 2296 - Every IPv6 mobile node MUST be able to perform IPv6 2297 decapsulation [4]. 2299 - Every IPv6 mobile node MUST support sending Binding Update 2300 options, as specified in Sections 10.6, 10.8, and 10.9; and MUST 2301 be able to receive and process Binding Acknowledgement options, 2302 as specified in Section 10.12. 2304 - Every IPv6 mobile node MUST support use of the dynamic home agent 2305 address discovery mechanism, as described in Section 10.7. 2307 - Every IPv6 mobile node MUST maintain a Binding Update List in 2308 which it records the IP address of each other node to which it 2309 has sent a Binding Update, for which the Lifetime sent in that 2310 binding has not yet expired. 2312 - Every IPv6 mobile node MUST support receiving a Binding Request 2313 option, by responding with a Binding Update option. 2315 - Every IPv6 mobile node MUST support sending packets containing a 2316 Home Address option; this option MUST be included in all packets 2317 sent while away from home, if the packet would otherwise have 2318 been sent with the mobile node's home address as the IP Source 2319 Address. 2321 - Every IPv6 mobile node MUST maintain a Home Agents List, as 2322 described in Section 4.6. 2324 8. Correspondent Node Operation 2326 A correspondent node is any node communicating with a mobile node. 2327 The correspondent node, itself, may be stationary or mobile, and may 2328 possibly also be functioning as a home agent for Mobile IPv6. The 2329 procedures in this section thus apply to all IPv6 nodes. 2331 8.1. Receiving Packets from a Mobile Node 2333 Packets sent by a mobile node while away from home generally include 2334 a Home Address option. When any node receives a packet containing 2335 a Home Address option, it MUST process the option in a manner 2336 consistent with copying the Home Address field from the Home Address 2337 option into the IPv6 header, replacing the original value of the 2338 Source Address field there. However, any actual modifications to 2339 the Source Address field in the packet's IPv6 header MUST not be 2340 performed until after all processing of other options contained in 2341 this same Destination Options extension header is completed. 2343 Further processing of such a packet after option processing (e.g., 2344 at the transport layer) thus need not know that the original Source 2345 Address was a care-of address, or that the Home Address option was 2346 used in the packet. Since the sending mobile node uses its home 2347 address at the transport layer when sending such a packet, the use of 2348 the care-of address and Home Address option is transparent to both 2349 the mobile node and the correspondent node above the level of the 2350 Home Address option generation and processing. 2352 8.2. Receiving Binding Updates 2354 Upon receiving a Binding Update option in some packet, the receiving 2355 node MUST validate the Binding Update according to the following 2356 tests: 2358 - The packet meets the specific IPsec requirements for Binding 2359 Updates, defined in Section 4.4. 2361 - The packet MUST contain a valid Home Address option. The home 2362 address for the binding is specified by the Home Address field of 2363 the Home Address option. 2365 - The Option Length field in the Binding Update option is greater 2366 than or equal to the length specified in Section 5.1. 2368 - The Sequence Number field in the Binding Update option is greater 2369 than the Sequence Number received in the previous Binding Update 2370 for this home address, if any. As noted in Section 4.6, this 2371 Sequence Number comparison MUST be performed modulo 2**16. 2373 Any Binding Update not satisfying all of these tests MUST be 2374 silently ignored, and the packet carrying the Binding Update MUST be 2375 discarded. 2377 If the Binding Update is valid according to the tests above, then the 2378 Binding Update is processed further as follows: 2380 - If the Lifetime specified in the Binding Update is nonzero and 2381 the specified Care-of Address is not equal to the home address 2382 for the binding (as given in the Home Address option in the 2383 packet), then this is a request to cache a binding for the 2384 mobile node. If the Home Registration (H) bit is set in the 2385 Binding Update, the Binding Update is processed according to the 2386 procedure specified in Section 9.3; otherwise, it is processed 2387 according to the procedure specified in Section 8.3. 2389 - If the Lifetime specified in the Binding Update is zero or the 2390 specified Care-of Address matches the home address for the 2391 binding, then this is a request to delete the mobile node's 2392 cached binding. If the Home Registration (H) bit is set in the 2393 Binding Update, the Binding Update is processed according to the 2394 procedure specified in Section 9.4; otherwise, it is processed 2395 according to the procedure specified in Section 8.4. 2397 8.3. Requests to Cache a Binding 2399 When a node receives a Binding Update, it MUST validate it and 2400 determine the type of Binding Update according to the steps described 2401 in Section 8.2. This section describes the processing of a valid 2402 Binding Update that requests a node to cache a mobile node's binding, 2403 for which the Home Registration (H) bit is not set in the Binding 2404 Update. 2406 In this case, the receiving node SHOULD create a new entry in its 2407 Binding Cache for this mobile node (or update its existing Binding 2408 Cache entry for this mobile node, if such an entry already exists). 2409 The home address of the mobile node is taken from the Home Address 2410 field in the packet's Home Address option. The new Binding Cache 2411 entry records the association between this home address and the 2412 care-of address for the binding, as specified in either the Care-of 2413 Address field of the Binding Update or in the Source Address field 2414 in the packet's IPv6 header. The lifetime for the Binding Cache 2415 entry is initialized from the Lifetime field specified in the Binding 2416 Update, although this lifetime MAY be reduced by the node caching the 2417 binding; the lifetime for the Binding Cache entry MUST NOT be greater 2418 than the Lifetime value specified in the Binding Update. Any Binding 2419 Cache entry MUST be deleted after the expiration of this lifetime on 2420 the Binding Cache entry. 2422 8.4. Requests to Delete a Binding 2424 When a node receives a Binding Update, it MUST validate it and 2425 determine the type of Binding Update according to the steps described 2426 in Section 8.2. This section describes the processing of a valid 2427 Binding Update that requests a node to delete a mobile node's binding 2428 from its Binding Cache, for which the Home Registration (H) bit is 2429 not set in the Binding Update. 2431 In this case, the receiving node MUST delete any existing entry in 2432 its Binding Cache for this mobile node. The home address of the 2433 mobile node is taken from the Home Address field in the packet's Home 2434 Address option. 2436 8.5. Sending Binding Acknowledgements 2438 When any node receives a packet containing a Binding Update option 2439 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 2440 Acknowledgement option acknowledging receipt of the Binding Update. 2441 If the node accepts the Binding Update and creates or updates an 2442 entry in its Binding Cache for this binding, the Status field in 2443 the Binding Acknowledgement MUST be set to a value less than 128; 2444 if the node rejects the Binding Update and does not create or 2445 update an entry for this binding, the Status field in the Binding 2446 Acknowledgement MUST be set to a value greater than or equal to 128. 2447 Specific values for the Status field are described in Section 5.2 and 2448 in the most recent "Assigned Numbers" [26]. 2450 The packet in which the Binding Acknowledgement is returned MUST meet 2451 the specific IPsec requirements for Binding Acknowledgements, defined 2452 in Section 4.4; and the packet MUST be sent using a Routing header 2453 in the same way as any other packet sent to a mobile node using a 2454 care-of address (even if the binding was rejected), as described 2455 in Section 8.9. The packet is routed first to the care-of address 2456 contained in the Binding Update being acknowledged, and then to the 2457 mobile node's home address. This use of the Routing header ensures 2458 that the Binding Acknowledgement will be routed to the current 2459 location of the node sending the Binding Update, whether the Binding 2460 Update was accepted or rejected. 2462 8.6. Sending Binding Requests 2464 Entries in a node's Binding Cache MUST be deleted when their lifetime 2465 expires. If such an entry is still in active use in sending packets 2466 to a mobile node, the next packet sent to the mobile node will be 2467 routed normally to the mobile node's home link, where it will be 2468 intercepted and tunneled to the mobile node. The mobile node will 2469 then return a Binding Update to the sender, allowing it to create 2470 a new Binding Cache entry for sending future packets to the mobile 2471 node. Communication with the mobile node continues uninterrupted, 2472 but the forwarding of this packet through the mobile node's home 2473 agent creates additional overhead and latency in delivering packets 2474 to the mobile node. 2476 If the sender knows that the Binding Cache entry is still in active 2477 use, it MAY send a Binding Request option to the mobile node in 2478 an attempt to avoid this overhead and latency due to deleting and 2479 recreating the Binding Cache entry. Since a Binding Request is a 2480 destination option, it may, for example, be included in any packet 2481 already being sent to the mobile node, such as a packet that is part 2482 of ongoing TCP communication with the mobile node. When the mobile 2483 node receives a packet from some sender containing a Binding Request 2484 option, it returns a Binding Update option to that sender, giving its 2485 current binding and a new lifetime. 2487 8.7. Cache Replacement Policy 2489 Any entry in a node's Binding Cache MUST be deleted after the 2490 expiration of the Lifetime specified in the Binding Update from 2491 which the entry was created or last updated. Conceptually, a node 2492 maintains a separate timer for each entry in its Binding Cache. When 2493 creating or updating a Binding Cache entry in response to a received 2494 and accepted Binding Update, the node sets the timer for this entry 2495 to the specified Lifetime period. When a Binding Cache entry's timer 2496 expires, the node deletes the entry. 2498 Each node's Binding Cache will, by necessity, have a finite size. 2499 A node MAY use any reasonable local policy for managing the space 2500 within its Binding Cache, except that any entry marked as a "home 2501 registration" (Section 9.3) MUST NOT be deleted from the cache until 2502 the expiration of its lifetime period. When attempting to add a 2503 new "home registration" entry in response to a Binding Update with 2504 the Home Registration (H) bit set, if insufficient space exists (or 2505 can be reclaimed) in the node's Binding Cache, the node MUST reject 2506 the Binding Update and SHOULD return a Binding Acknowledgement to 2507 the sending mobile node, in which the Status field is set to 131 2508 (insufficient resources). When otherwise attempting to add a new 2509 entry to its Binding Cache, a node MAY, if needed, choose to drop any 2510 entry already in its Binding Cache, other than a "home registration" 2511 entry, in order to make space for the new entry. For example, a 2512 "least-recently used" (LRU) strategy for cache entry replacement 2513 among entries not marked as a "home registration" is likely to work 2514 well. 2516 Any binding dropped from a node's Binding Cache due to lack of cache 2517 space will be rediscovered and a new cache entry created, if the 2518 binding is still in active use by the node for sending packets. If 2519 the node sends a packet to a destination for which it has dropped the 2520 entry from its Binding Cache, the packet will be routed normally, 2521 leading to the mobile node's home link. There, the packet will be 2522 intercepted by the mobile node's home agent and tunneled to the 2523 mobile node's current primary care-of address. As when a Binding 2524 Cache entry is initially created, this indirect routing to the mobile 2525 node through its home agent will result in the mobile node sending 2526 a Binding Update to this sending node when it receives the tunneled 2527 packet, allowing it to add an entry again for this destination mobile 2528 node to its Binding Cache. 2530 8.8. Receiving ICMP Error Messages 2532 When a correspondent node sends a packet to a mobile node, if the 2533 correspondent node has a Binding Cache entry for the destination 2534 address of the packet, then the correspondent node uses a Routing 2535 header to deliver the packet to the mobile node through the care-of 2536 address in the binding recorded in the Binding Cache entry. Any ICMP 2537 error message caused by the packet on its way to the mobile node will 2538 be returned normally to the correspondent node. 2540 On the other hand, if the correspondent node has no Binding Cache 2541 entry for the mobile node, the packet will be routed to the mobile 2542 node's home link. There, it will be intercepted by the mobile node's 2543 home agent, encapsulated, and tunneled to the mobile node's primary 2544 care-of address. Any ICMP error message caused by the packet on 2545 its way to the mobile node while in the tunnel, will be returned to 2546 the mobile node's home agent (the source of the tunnel). By the 2547 definition of IPv6 encapsulation [4], this encapsulating node MUST 2548 relay certain ICMP error messages back to the original sender of the 2549 packet, which in this case is the correspondent node. 2551 Likewise, if a packet for a mobile node arrives at the mobile node's 2552 previous link and is intercepted there by a home agent for the mobile 2553 node's previous care-of address as described in Section 10.9 (e.g., 2554 the mobile node moved after the packet was sent), that home agent 2555 will encapsulate and tunnel the packet to the mobile node's new 2556 care-of address. As above, any ICMP error message caused by the 2557 packet while in this tunnel will be returned to that home agent (the 2558 source of the tunnel), which MUST relay certain ICMP error messages 2559 back to the correspondent node [4]. 2561 Thus, in all cases, any meaningful ICMP error messages caused 2562 by packets from a correspondent node to a mobile node will be 2563 returned to the correspondent node. If the correspondent node 2564 receives persistent ICMP Destination Unreachable messages after 2565 sending packets to a mobile node based on an entry in its Binding 2566 Cache, the correspondent node SHOULD delete this Binding Cache 2567 entry. If the correspondent node subsequently transmits another 2568 packet to the mobile node, the packet will be routed to the mobile 2569 node's home link, intercepted by the mobile node's home agent, and 2570 tunneled to the mobile node's primary care-of address using IPv6 2571 encapsulation. The mobile node will then return a Binding Update to 2572 the correspondent node, allowing it to recreate a (correct) Binding 2573 Cache entry for the mobile node. 2575 8.9. Sending Packets to a Mobile Node 2577 Before sending any packet, the sending node SHOULD examine its 2578 Binding Cache for an entry for the destination address to which the 2579 packet is being sent. If the sending node has a Binding Cache entry 2580 for this address, the sending node SHOULD use a Routing header to 2581 route the packet to this mobile node (the destination node) by way 2582 of the care-of address in the binding recorded in that Binding Cache 2583 entry. For example, assuming use of a Type 0 Routing header [6], if 2584 no other use of a Routing header is involved in the routing of this 2585 packet, the mobile node sets the fields in the packet's IPv6 header 2586 and Routing header as follows: 2588 - The Destination Address in the packet's IPv6 header is set to 2589 the mobile node's care-of address copied from the Binding Cache 2590 entry. 2592 - The Routing header is initialized to contain a single route 2593 segment, with an Address of the mobile node's home address (the 2594 original destination address to which the packet was being sent). 2596 Following the definition of a Type 0 Routing header [6], this packet 2597 will be routed to the mobile node's care-of address, where it will 2598 be delivered to the mobile node (the mobile node has associated the 2599 care-of address with its network interface). Normal processing of 2600 the Routing header by the mobile node will then proceed as follows: 2602 - The mobile node swaps the Destination Address in the packet's 2603 IPv6 header and the Address specified in the Routing header. 2604 This results in the packet's IP Destination Address being set to 2605 the mobile node's home address. 2607 - The mobile node then resubmits the packet to its IPv6 module for 2608 further processing, "looping back" the packet inside the mobile 2609 node. Since the mobile node recognizes its own home address as 2610 one of its current IP addresses, the packet is processed further 2611 within the mobile node, in the same way then as if the mobile 2612 node was at home. 2614 If, instead, the sending node has no Binding Cache entry for the 2615 destination address to which the packet is being sent, the sending 2616 node simply sends the packet normally, with no Routing header. If 2617 the destination node is not a mobile node (or is a mobile node that 2618 is currently at home), the packet will be delivered directly to this 2619 node and processed normally by it. If, however, the destination node 2620 is a mobile node that is currently away from home, the packet will 2621 be intercepted by the mobile node's home agent and tunneled (using 2622 IPv6 encapsulation [4]) to the mobile node's current primary care-of 2623 address, as described in Section 9.6. The mobile node will then send 2624 a Binding Update to the sending node, as described in Section 10.8, 2625 allowing the sending node to create a Binding Cache entry for its use 2626 in sending subsequent packets to this mobile node. 2628 9. Home Agent Operation 2630 9.1. Receiving Router Advertisement Messages 2632 For each link on which a router provides service as a home agent, the 2633 router maintains a Home Agents List recording information about all 2634 other home agents on that link. This list is used in the dynamic 2635 home agent address discovery mechanism, described in Section 9.2. 2636 The information for the list is learned through receipt of the 2637 periodic unsolicited multicast Router Advertisements from each other 2638 home agent on the link, in which the Home Agent (H) bit is set, in a 2639 manner similar to the Default Router List conceptual data structure 2640 maintained by each host for Neighbor Discovery [17]. 2642 On receipt of a valid Router Advertisement, as defined in the 2643 processing algorithm specified for Neighbor Discovery [17], the home 2644 agent performs the following steps, in addition to any steps already 2645 required of it by Neighbor Discovery: 2647 - If the Home Agent (H) bit in the Router Advertisement is not set, 2648 skip all of the following steps. There are no special processing 2649 steps required by Mobile IP for this Router Advertisement, since 2650 the Advertisement was not sent by a home agent. 2652 - Otherwise, extract the Source Address from the IP header of the 2653 Router Advertisement. This is the link-local IP address on this 2654 link of the home agent sending this Advertisement [17]. 2656 - Determine from the Router Advertisement the preference for this 2657 home agent. If the Router Advertisement contains a Home Agent 2658 Information Option, then the preference is taken from the Home 2659 Agent Preference field in the option; otherwise, the default 2660 preference of 0 SHOULD be used. 2662 - Determine from the Router Advertisement the lifetime for 2663 this home agent. If the Router Advertisement contains a Home 2664 Agent Information Option, then the lifetime is taken from 2665 the Home Agent Lifetime field in the option; otherwise, the 2666 lifetime specified by the Router Lifetime field in the Router 2667 Advertisement SHOULD be used. 2669 - If the link-local address of the home agent sending this 2670 Advertisement is already present in this home agent's Home 2671 Agents List and the received home agent lifetime value is zero, 2672 immediately delete this entry in the Home Agents List. 2674 - Otherwise, if the link-local address of the home agent sending 2675 this Advertisement is already present in the receiving home 2676 agent's Home Agents List, reset its lifetime and preference to 2677 the values determined above. 2679 - If the link-local address of the home agent sending this 2680 Advertisement, as determined above, is not already present in 2681 the Home Agents List maintained by the receiving home agent, and 2682 the lifetime for the sending home agent, as determined above, 2683 is non-zero, create a new entry in the list, and initialize its 2684 lifetime and preference to the values determined above. 2686 - If the Home Agents List entry for the link-local address of 2687 the home agent sending this Advertisement was not deleted as 2688 described above, determine any global address(es) of the home 2689 agent based on each Prefix Information option received in 2690 this Advertisement in which the Router Address (R) bit is set 2691 (Section 6.2). For each such global address determined from this 2692 Advertisement, add this global address to the list of global 2693 addresses for this home agent in this Home Agents List entry. 2695 A home agent SHOULD maintain an entry in its Home Agents List for 2696 each such valid home agent address until that entry's lifetime 2697 expires, after which time the entry MUST be deleted. 2699 9.2. Dynamic Home Agent Address Discovery 2701 A mobile node, while away from home, MAY use the dynamic home agent 2702 address discovery mechanism to attempt to discover the address of 2703 one or more routers serving as home agents on its home link. This 2704 discovery may be necessary, for example, if some nodes on its home 2705 link have been reconfigured while the mobile node has been away from 2706 home, such that the router that was operating as the mobile node's 2707 home agent has been replaced by a different router serving this role. 2709 As described in Section 10.7, a mobile node attempts dynamic home 2710 agent address discovery by sending an ICMP Home Agent Address 2711 Discovery Request message to the "Mobile IPv6 Home-Agents" anycast 2712 address [10] for its home IP subnet prefix, using its care-of address 2713 as the Source Address of the packet. A home agent receiving such a 2714 Home Agent Address Discovery Request message that is serving this 2715 subnet (the home agent is configured with this anycast address on one 2716 of its network interfaces) SHOULD return an ICMP Home Agent Address 2717 Discovery Reply message to the mobile node (at its care-of address 2718 that was used as the Source Address of the Request message), with the 2719 Source Address of the Reply packet set to one of the global unicast 2720 addresses of the home agent. The Home Agent Addresses field in the 2721 Reply message is constructed as follows: 2723 - The Home Agent Addresses field SHOULD contain one global IP 2724 address for each home agent currently listed in this home 2725 agent's own Home Agents List (Section 4.6). However, if this 2726 home agent's own global IP address would be placed in the list 2727 (as described below) as the first entry in the list, then this 2728 home agent SHOULD NOT include its own address in the Home Agent 2729 Addresses field in the Reply message. Not placing this home 2730 agent's own IP address in the list will cause the receiving 2731 mobile node to consider this home agent as the most preferred 2732 home agent; otherwise, this home agent will be considered to be 2733 preferred in its order given by its place in the list returned. 2735 - The IP addresses in the Home Agent Addresses field SHOULD be 2736 listed in order of decreasing preference value, based either 2737 on the respective advertised preference from a Home Agent 2738 Information option or on the default preference of 0 if no 2739 preference is advertised (or on the configured home agent 2740 preference for this home agent itself). The home agent with 2741 the highest preference SHOULD be listed first in the Home Agent 2742 Addresses field, and the home agent with the lowest preference 2743 SHOULD be listed last. 2745 - Among home agents with equal preference, their IP addresses 2746 in the Home Agent Addresses field SHOULD be listed in an 2747 order randomized with respect to other home agents with equal 2748 preference, each time a Home Agent Address Discovery Reply 2749 message is returned by this home agent. 2751 - For each entry in this home agent's Home Agents List, if more 2752 than one global IP address is associated with this list entry, 2753 then one of these global IP addresses SHOULD be selected to 2754 include in the Home Agent Addresses field in the Reply message. 2755 As described in Section 4.6, one Home Agents List entry, 2756 identified by the home agent's link-local address, exists for 2757 each home agent on the link; associated with that list entry is 2758 one or more global IP addresses for this home agent, learned 2759 through Prefix Information options with the Router Address (R) 2760 bit is set, received in Router Advertisements from this 2761 link-local address. The selected global IP address for each home 2762 agent to include in forming the Home Agent Addresses field in the 2763 Reply message MUST be the global IP address of the respective 2764 home agent sharing a prefix with the mobile node's home address 2765 as indicated in the Home Address option in the Request message; 2766 if no such global IP address is known for some home agent, an 2767 entry for that home agent MUST NOT be included in the Home Agent 2768 Addresses field in the Reply message. 2770 - In order to avoid the possibility of the Reply message packet 2771 being fragmented (or rejected by an intermediate router with an 2772 ICMP Packet Too Big message [5]), if the resulting total packet 2773 size containing the complete list of home agents in the Home 2774 Agent Addresses field would exceed the minimum IPv6 MTU [6], the 2775 home agent SHOULD reduce the number of home agent IP addresses 2776 returned in the packet to the number of addresses that will fit 2777 without exceeding this limit. The home agent addresses returned 2778 in the packet SHOULD be those from the complete list with the 2779 highest preference. 2781 9.3. Primary Care-of Address Registration 2783 When a node receives a Binding Update, it MUST validate it and 2784 determine the type of Binding Update according to the steps described 2785 in Section 8.2. This section describes the processing of a valid 2786 Binding Update that requests the receiving node to serve as its home 2787 agent, registering its primary care-of address. 2789 To begin processing the Binding Update, the home agent MUST perform 2790 the following sequence of tests: 2792 - If the node is not a router that implements home agent 2793 functionality, then the node MUST reject the Binding Update and 2794 SHOULD return a Binding Acknowledgement to the mobile node, in 2795 which the Status field is set to 132 (home registration not 2796 supported). 2798 - Else, if the home address for the binding (the Home Address field 2799 in the packet's Home Address option) is not an on-link IPv6 2800 address with respect to the home agent's current Prefix List, 2801 then the home agent MUST reject the Binding Update and SHOULD 2802 return a Binding Acknowledgement to the mobile node, in which the 2803 Status field is set to 133 (not home subnet). 2805 - Else, if the Prefix Length field is nonzero in the Binding Update 2806 and this length differs from the length of the home agent's own 2807 knowledge of the corresponding subnet prefix on the home link, 2808 then the home agent MUST reject the Binding Update and SHOULD 2809 return a Binding Acknowledgement to the mobile node, in which the 2810 Status field is set to 136 (incorrect subnet prefix length). 2812 - Else, if the home agent chooses to reject the Binding Update for 2813 any other reason (e.g., insufficient resources to serve another 2814 mobile node as a home agent), then the home agent SHOULD return a 2815 Binding Acknowledgement to the mobile node, in which the Status 2816 field is set to an appropriate value to indicate the reason for 2817 the rejection. 2819 - Finally, if the Duplicate Address Detection (D) bit is set in 2820 the Binding Update, this home agent MUST perform Duplicate 2821 Address Detection [27] on the mobile node's home link for the 2822 home address in this binding (before returning the Binding 2823 Acknowledgement). Normal processing for Duplicate Address 2824 Detection specifies that, in certain cases, the node SHOULD 2825 delay sending the initial Neighbor Solication message of 2826 Duplicate Address Detection by a random delay between 0 and 2827 MAX_RTR_SOLICITATION_DELAY [17, 27]; however, in this case, the 2828 home agent SHOULD NOT perform such a delay. If this Duplicate 2829 Address Detection fails, then the home agent MUST reject the 2830 Binding Update and SHOULD return a Binding Acknowledgement to the 2831 mobile node, in which the Status field is set to 138 (Duplicate 2832 Address Detection failed). 2834 If the home agent does not reject the Binding Update as described 2835 above, then it becomes the home agent for the mobile node. The new 2836 home agent (the receiving node) MUST then create a new entry in its 2837 Binding Cache for this mobile node (or update its existing Binding 2838 Cache entry for this mobile node, if such an entry already exists) 2839 The home address of the mobile node is taken from the Home Address 2840 field in the packet's Home Address option. The care-of address for 2841 this Binding Cache entry is taken from the Alternate Care-of Address 2842 sub-option in the Binding Update option, if present, or from the 2843 Source Address field in the packet's IPv6 header, otherwise. 2845 The home agent MUST mark this Binding Cache entry as a "home 2846 registration" to indicate that the node is serving as a home 2847 agent for this binding. Binding Cache entries marked as a "home 2848 registration" MUST be excluded from the normal cache replacement 2849 policy used for the Binding Cache (Section 8.7) and MUST NOT be 2850 removed from the Binding Cache until the expiration of the Lifetime 2851 period. 2853 In addition, the home agent MUST copy the Router (R) bit from the 2854 Binding Update into the corresponding bit in this Binding Cache entry 2855 for this mobile node. 2857 The lifetime for the Binding Cache entry MUST NOT be greater than 2858 the remaining valid lifetime for the subnet prefix in the mobile 2859 node's home address specified with the Binding Update, and MUST NOT 2860 be greater than the Lifetime value specified in the Binding Update. 2861 The remaining valid lifetime for this prefix is determined by the 2862 home agent based on its own Prefix List entry for this prefix [17]. 2863 Furthermore, if the Prefix Length field in the Binding Update is 2864 nonzero, then the lifetime for the Binding Cache entry MUST NOT be 2865 greater than the minimum remaining valid lifetime for all subnet 2866 prefixes on the mobile node's home link. If the value of the 2867 Lifetime field specified by the mobile node in its Binding Update is 2868 greater than this prefix lifetime, the home agent MUST decrease the 2869 binding lifetime to less than or equal to the prefix valid lifetime. 2870 The home agent MAY further decrease the specified lifetime for the 2871 binding, for example based on a local policy implemented by the home 2872 agent. The resulting lifetime is stored by the home agent in the 2873 Binding Cache entry, and this Binding Cache entry MUST be deleted by 2874 the home agent after the expiration of this lifetime. 2876 The Prefix Length in the Binding Update MUST also be saved in the 2877 Binding Cache entry. 2879 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2880 be), then the home agent MUST return a Binding Acknowledgement to the 2881 mobile node, constructed as follows: 2883 - The Status field MUST be set to a value indicating success (the 2884 value MUST be less than 128). The only currently defined success 2885 Status value is 0, indicating simply that the Binding Update was 2886 accepted. 2888 - The Sequence Number field MUST be copied from the Sequence Number 2889 given in the Binding Update. 2891 - The Lifetime field MUST be set to the remaining lifetime for 2892 the binding as set by the home agent in its "home registration" 2893 Binding Cache entry for the mobile node. As described above, 2894 this lifetime MUST NOT be greater than the remaining valid 2895 lifetime for the subnet prefix in the mobile node's home address. 2897 - The Refresh field MUST be set to a value less than or equal to 2898 the Lifetime value being returned in the Binding Update. If the 2899 home agent stores the Binding Cache entry in nonvolatile storage 2900 (that survives the crash or other failure of the home agent), 2901 then the Refresh field SHOULD be set to the same value as the 2902 Lifetime field; otherwise, the home agent MAY set the Refresh 2903 field to a value less than the Lifetime field, to indicate that 2904 the mobile node SHOULD attempt to refresh its home registration 2905 at the indicated shorter interval (although the home agent will 2906 still retain the registration for the Lifetime period, even if 2907 the mobile node does not refresh its registration within the 2908 Refresh period). 2910 In addition, the home agent MUST follow the procedure defined in 2911 Section 9.5 to intercept packets on the mobile node's home link 2912 addressed to the mobile node, while the home agent is serving as the 2913 home agent for this mobile node. 2915 9.4. Primary Care-of Address De-registration 2917 When a node receives a Binding Update, it MUST validate it and 2918 determine the type of Binding Update according to the steps described 2919 in Section 8.2. This section describes the processing of a valid 2920 Binding Update that requests the receiving node to no longer serve as 2921 its home agent, de-registering its primary care-of address. 2923 To begin processing the Binding Update, the home agent MUST perform 2924 the following test: 2926 - If the receiving node has no entry in its Binding Cache for this 2927 mobile node that is marked as a "home registration", then this 2928 node MUST reject the Binding Update and SHOULD return a Binding 2929 Acknowledgement to the mobile node, in which the Status field is 2930 set to 137 (not home agent for this mobile node). 2932 If the home agent does not reject the Binding Update as described 2933 above, then it MUST delete any existing entry in its Binding Cache 2934 for this mobile node. 2936 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2937 be), then the home agent MUST return a Binding Acknowledgement to the 2938 mobile node, constructed as follows: 2940 - The Status field MUST be set to a value indicating success (the 2941 value MUST be less than 128). The only currently defined success 2942 Status value is 0, indicating simply that the Binding Update was 2943 accepted. 2945 - The Sequence Number field MUST be copied from the Sequence Number 2946 given in the Binding Update. 2948 - The Lifetime field MUST be set to zero. 2950 - The Refresh field MUST be set to zero. 2952 In addition, the home agent MUST stop intercepting packets on the 2953 mobile node's home link addressed to the mobile node (Section 9.5). 2955 9.5. Intercepting Packets for a Mobile Node 2957 While a node is serving as the home agent for mobile node (while the 2958 node has an entry in its Binding Cache for this mobile node that is 2959 marked as a "home registration"), this node MUST attempt to intercept 2960 packets on the mobile node's home link addressed to the mobile node, 2961 and MUST tunnel each intercepted packet to the mobile node using 2962 using IPv6 encapsulation [4]. 2964 In order to intercept such packets on the home link, when a node 2965 becomes the home agent for some mobile node (it did not already 2966 have a Binding Cache entry for this mobile node marked as a "home 2967 registration"), then the home agent MUST multicast onto the home link 2968 a "gratuitous" Neighbor Advertisement message [17] on behalf of the 2969 mobile node. Specifically, the home agent performs the following 2970 steps: 2972 - The home agent examines the value of the Prefix Length field 2973 in the new "home registration" Binding Cache entry. If this 2974 value is zero, the following step is carried out only for the 2975 individual home address specified for this binding. If, instead, 2976 this field is nonzero, then the following step is carried out 2977 for each address for the mobile node formed from the interface 2978 identifier in the mobile node's home address in this binding 2979 (the remaining low-order bits in the address after the indicated 2980 subnet prefix), together with each one of the subnet prefixes 2981 currently considered by the home agent to be on-link (including 2982 both the link-local and site-local prefix). 2984 - For each specific IP address for the mobile node determined 2985 in the first step above, the home agent multicasts onto the 2986 home link (to the all-nodes multicast address) a Neighbor 2987 Advertisement message [17] on behalf of the mobile node, to 2988 advertise the home agent's own link-layer address for this IP 2989 address. 2991 All fields in each such Neighbor Advertisement message SHOULD 2992 be set in the same way they would be set by the mobile node 2993 itself if sending this Neighbor Advertisement while at home [17], 2994 with the following exceptions. The Target Address in the 2995 Neighbor Advertisement message MUST be set to this IP address 2996 for the mobile node, and the Advertisement MUST include a Target 2997 Link-layer Address option specifying the home agent's link-layer 2998 address. In addition, the Router (R) bit in the Advertisement 2999 MUST be copied from the corresponding bit in the home agent's 3000 Binding Cache entry for the mobile node. The Solicited Flag (S) 3001 in the Advertisement MUST NOT be set, since it was not solicited 3002 by any Neighbor Solicitation message. The Override Flag (O) in 3003 the Advertisement MUST be set, indicating that the Advertisement 3004 SHOULD override any existing Neighbor Cache entry at any node 3005 receiving it. 3007 Any node on the home link receiving one of the Neighbor Advertisement 3008 messages described above will thus update its Neighbor Cache to 3009 associate the mobile node's address with the home agent's link 3010 layer address, causing it to transmit any future packets for the 3011 mobile node normally destined to this address instead to the mobile 3012 node's home agent. Since multicasts on the local link (such as 3013 Ethernet) are typically not guaranteed to be reliable, the home 3014 agent MAY retransmit this Neighbor Advertisement message up to 3015 MAX_ADVERT_REXMIT times to increase its reliability. It is still 3016 possible that some nodes on the home link will not receive any of 3017 these Neighbor Advertisements, but these nodes will eventually be 3018 able to detect the link-layer address change for the mobile node's 3019 home address, through use of Neighbor Unreachability Detection [17]. 3021 While a node is serving as a home agent for some mobile node (it 3022 still has a "home registration" entry for this mobile node in its 3023 Binding Cache), the home agent uses IPv6 Neighbor Discovery [17] 3024 to intercept unicast packets on the home link addressed the mobile 3025 node's home address. In order to intercept packets in this way, 3026 the home agent MUST act as a proxy for this mobile node to reply to 3027 any received Neighbor Solicitation messages for it. When a home 3028 agent receives a Neighbor Solicitation message, it MUST check if the 3029 Target Address specified in the message matches the home address 3030 of any mobile node for which it has a Binding Cache entry marked 3031 as a "home registration". This check MUST include all possible 3032 home addresses for the mobile node, based on the subnet prefixes 3033 currently considered to be on-link by the home agent (including the 3034 corresponding link-local address and site-local address), if the 3035 Prefix Length in the Binding Cache entry for this mobile node (from 3036 the Binding Update that created this Cache entry) is nonzero. 3038 If such an entry exists in the home agent's Binding Cache, the home 3039 agent MUST reply to the Neighbor Solicitation message with a Neighbor 3040 Advertisement message, giving the home agent's own link-layer address 3041 as the link-layer address for the specified Target Address. In 3042 addition, the Router (R) bit in the Advertisement MUST be copied from 3043 the corresponding bit in the home agent's Binding Cache entry for the 3044 mobile node. Acting as a proxy in this way allows other nodes on 3045 the mobile node's home link to resolve the mobile node's IPv6 home 3046 address, and allows the home agent to to defend these addresses on 3047 the home link for Duplicate Address Detection [17]. 3049 9.6. Tunneling Intercepted Packets to a Mobile Node 3051 For any packet sent to a mobile node from the mobile node's home 3052 agent (for which the home agent is the original sender of the 3053 packet), the home agent is operating as a correspondent node of 3054 the mobile node for this packet and the procedures described in 3055 Section 8.9 apply. The home agent (as a correspondent node) uses a 3056 Routing header to route the packet to the mobile node by way of the 3057 care-of address in the home agent's Binding Cache (the mobile node's 3058 primary care-of address, in this case). 3060 While the mobile node is away from home and this node is acting 3061 as the mobile node's home agent, the home agent intercepts any 3062 packets on the home link addressed to the mobile node's home address 3063 (including addresses formed from other on-link prefixes, if the 3064 Prefix Length field was nonzero in the Binding Update), as described 3065 in Section 9.5. The home agent cannot use a Routing header to 3066 forward these intercepted packets to the mobile node, since it cannot 3067 modify the packet in flight without invalidating any existing IPv6 3068 AH [11] or ESP [12] header present in the packet. 3070 For forwarding each intercepted packet to the mobile node, the 3071 home agent MUST tunnel the packet to the mobile node using IPv6 3072 encapsulation [4]; the tunnel entry point node is the home agent, 3073 and the tunnel exit point node is the primary care-of address as 3074 registered with the home agent (which is an address of the mobile 3075 node itself). When a home agent encapsulates an intercepted packet 3076 for forwarding to the mobile node, the home agent sets the Source 3077 Address in the prepended tunnel IP header to the home agent's own IP 3078 address, and sets the Destination Address in the tunnel IP header 3079 to the mobile node's primary care-of address. When received by the 3080 mobile node (using its primary care-of address), normal processing of 3081 the tunnel header [4] will result in decapsulation and processing of 3082 the original packet by the mobile node. 3084 However, packets addressed to the mobile node's link-local address 3085 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 3086 be discarded, and the home agent SHOULD return an ICMP Destination 3087 Unreachable, Code 3, message to the packet's Source Address (unless 3088 this Source Address is a multicast address). Packets addressed to 3089 the mobile node's site-local address SHOULD be tunneled to the mobile 3090 node by default, but this behavior MUST be configurable to disable 3091 it; currently, the exact definition and semantics of a "site" and a 3092 site-local address are undefined in IPv6, and this default behavior 3093 might change at some point in the future. 3095 Tunneling of multicast packets to a mobile node follows similar 3096 limitations to those defined above for unicast packets addressed to 3097 the mobile node's link-local and site-local addresses. Multicast 3098 packets addressed to a multicast address with link-local scope [9], 3099 to which the mobile node is subscribed, MUST NOT be tunneled 3100 to the mobile node; such packets SHOULD be silently discarded 3101 (after delivering to other local multicast recipients). Multicast 3102 packets addressed to a multicast address with scope larger 3103 than link-local but smaller than global (e.g., site-local and 3104 organization-local) [9], to which the mobile node is subscribed, 3105 SHOULD be tunneled to the mobile node by default, but this behavior 3106 MUST be configurable to disable it; this default behavior might 3107 change at some point in the future as the definition of these scopes 3108 become better defined in IPv6. 3110 9.7. Renumbering the Home Subnet 3112 IPv6 provides mechanisms through Neighbor Discovery [17] and Address 3113 Autoconfiguration [27] to aid in renumbering a subnet, such as when a 3114 site switches to a new network service provider. In renumbering, new 3115 prefixes and addresses can be introduced for the subnet and old ones 3116 can be deprecated and removed. These mechanisms are defined to work 3117 while all nodes using the old prefixes are at home, connected to the 3118 link using these prefixes. Mobile IPv6 extends these mechanisms for 3119 the case in which one or more mobile nodes using the old prefixes are 3120 away from home while the renumbering takes place. 3122 The IPv6 renumbering mechanisms are based on nodes on the link 3123 receiving Prefix Information options in Router Advertisement 3124 messages giving the valid lifetime and preferred lifetime for 3125 different prefixes on the link [17]. Mobile IPv6 arranges to 3126 tunnel certain Router Advertisements giving "important" Prefix 3127 Information options to mobile nodes while away from home. To avoid 3128 the need to tunnel all Router Advertisements from the home link to 3129 a mobile node away from home, those Router Advertisements that are 3130 tunneled to the mobile node are retransmitted until acknowledged. To 3131 avoid possible security attacks from forged Router Advertisements 3132 tunneled to the mobile node, all such tunneled Router Advertisements 3133 must be authenticated to the mobile node by its home agent using 3134 IPsec [13, 11, 12]. 3136 Specifically, a home agent serving some mobile node SHOULD construct 3137 and tunnel to the mobile node a new Router Advertisement when any of 3138 the following conditions occur: 3140 - The preferred or valid lifetime for an existing prefix on the 3141 home link is reduced. 3143 - A new prefix is introduced on the home link. 3145 - The state of the home agent's AdvManagedFlag flag [17] changes 3146 from FALSE to TRUE or from TRUE to FALSE. 3148 The home agent determines these conditions based on its own 3149 configuration as a router and based on the Router Advertisements 3150 that it receives on the home link. The home agent constructs a new 3151 Router Advertisement message containing no options other than the 3152 Prefix Information options describing the prefixes for which one of 3153 the conditions above has occurred since the last Router Advertisement 3154 tunneled to and acknowledged by the mobile node. When multiple 3155 conditions occur at or near the same time, the home agent SHOULD 3156 attempt to combine them into a single Router Advertisement message to 3157 the mobile node. 3159 In tunneling each such Router Advertisement to the mobile node, the 3160 home agent MUST construct the packet as follows: 3162 - The Source Address in the packet's IPv6 header MUST be set to the 3163 home agent's IP address to which the mobile node addressed its 3164 current home registration. 3166 - The packet MUST be protected by IPsec [13, 11, 12] to guard 3167 against malicious Router Advertisements. The IPsec protection 3168 MUST provide sender authentication, data integrity protection, 3169 and replay protection, covering the Router Advertisement. 3171 - The packet MUST include a Binding Request destination option. 3173 - The Binding Request destination option MUST include a Unique 3174 Identifier Sub-Option (Section 5.5), with the unique identifier 3175 in the sub-option data set to a value different than that in 3176 any other Binding Request sent recently by this node. The word 3177 "recently" here means within the maximum likely lifetime of a 3178 packet, including transit time from source to destination and 3179 time spent awaiting reassembly with other fragments of the same 3180 packet, if fragmented. However, it is not required that a source 3181 node know the maximum packet lifetime. Rather, it is assumed 3182 that the requirement can be met by maintaining a simple 16-bit 3183 "wrap-around" counter to generate unique identifiers for Binding 3184 Requests that contain a Unique Identifier Sub-Option, incremented 3185 each time a Binding Request containing a Unique Identifier 3186 Sub-Option is sent. 3188 - The packet MUST be tunneled to the mobile node's primary care-of 3189 address using a Routing header, in the same way as any packet 3190 sent to the mobile node originated by the home agent (rather than 3191 using IPv6 encapsulation, as would be used by the home agent for 3192 intercepted packets). 3194 The home agent SHOULD periodically continue to retransmit this 3195 tunneled packet to the mobile node, until it is acknowledged by 3196 the receipt from the mobile node of a Binding Update matching 3197 the Binding Request in the packet (i.e., with matching Sequence 3198 Number). A Binding Update matches a Binding Request if it specifies 3199 a binding for the mobile node to which the Binding Request was sent 3200 and contains a Unique Identifier Sub-Option matching the unique 3201 identifier sent in the Unique Identifier Sub-Option in the Binding 3202 Request. 3204 If while the home agent is still retransmitting a Router 3205 Advertisement to the mobile node, another condition as described 3206 above occurs on the home link causing another Router Advertisement 3207 to be tunneled to the mobile node, the home agent SHOULD combine any 3208 Prefix Information options in the unacknowledged Router Advertisement 3209 into the new Router Advertisement and then begin retransmitting the 3210 new Router Advertisement rather than the old one. When tunneling 3211 a new Router Advertisement, even if it contains Prefix Information 3212 options sent previously in an unacknowledged tunneled Router 3213 Advertisement, the home agent MUST generate a new unique identifer 3214 for use in the Unique Identifier Sub-Option in the Binding Request 3215 tunneled with the new Router Advertisement. 3217 In addition, as described in Section 9.3, the lifetime returned by a 3218 mobile node's home agent in its Binding Acknowledgement in response 3219 to registration of a new primary care-of address by the mobile node 3220 MUST be no greater than the remaining valid lifetime for the subnet 3221 prefix in the mobile node's home address. Furthermore, as described 3222 in Section 10.8, Binding Updates sent by the mobile node to other 3223 nodes MUST use a lifetime no greater than the remaining lifetime of 3224 its home registration of its primary care-of address. These limits 3225 on a binding lifetimes ensure that no node uses a mobile node's home 3226 address beyond the time that it becomes invalid. The mobile node 3227 SHOULD further limit the lifetimes that it sends on any Binding 3228 Updates to be within the remaining preferred lifetime for the prefix 3229 in its home address. 3231 10. Mobile Node Operation 3233 10.1. Sending Packets While Away from Home 3235 While a mobile node is away from home, it continues to use its home 3236 address as well as also using one or more care-of addresses. When 3237 sending a packet while away from home, a mobile node MAY choose among 3238 these in selecting the address that it will use as the source of the 3239 packet, as follows: 3241 - From the point of view of protocol layers and applications above 3242 Mobile IP (e.g., transport protocols), the mobile node will 3243 generally use its home address as the source of the packet for 3244 most packets, even while away from home, since Mobile IP is 3245 designed to make mobility transparent to such software. Doing 3246 so also makes the node's mobility---and the fact that it is 3247 currently away from home---transparent to the correspondent nodes 3248 with which it communicates. For packets sent that are part of 3249 transport-level connections established while the mobile node 3250 was at home, the mobile node MUST use its home address in this 3251 way. Likewise, for packets sent that are part of transport-level 3252 connections that the mobile node may still be using after moving 3253 to a new location, the mobile node SHOULD use its home address 3254 in this way. When sending such packets, Mobile IP will modify 3255 the packet to move the home address into a Home Address option 3256 and will set the IPv6 header's Source Address field to one of 3257 the mobile node's care-of addresses; these modifications to 3258 the packet are then reversed in the node receiving the packet, 3259 restoring the mobile node's home address to be the packet's 3260 Source Address before processing by higher protocol layers and 3261 applications. 3263 - For short-term communication, particularly for communication that 3264 may easily be retried if it fails, the mobile node MAY choose 3265 to directly use one of its care-of addresses as the source of 3266 the packet, thus not requiring the use of a Home Address option 3267 in the packet. An example of this type of communication might 3268 be DNS queries sent by the mobile node [15, 16]. Using the 3269 mobile node's care-of address as the source for such queries will 3270 generally have a lower overhead than using the mobile node's 3271 home address, since no extra options need be used in either the 3272 query or its reply, and all packets can be routed normally, 3273 directly between their source and destination without relying 3274 on Mobile IP. If the mobile node has no particular knowledge 3275 that the communication being sent fits within this general type 3276 of communication, however, the mobile node SHOULD NOT use its 3277 care-of address as the source of the packet in this way. 3279 For packets sent by a mobile node while it is at home, no special 3280 Mobile IP processing is required for sending this packet. Likewise, 3281 if the mobile node uses any address other than its home address as 3282 the source of a packet sent while away from home (from the point of 3283 view of higher protocol layers or applications, as described above), 3284 no special Mobile IP processing is required for sending that packet. 3285 In each case, the packet is simply addressed and transmitted in the 3286 same way as any normal IPv6 packet. 3288 For each other packet sent by the mobile node (i.e., packets sent 3289 while away from home, using the mobile node's home address as 3290 the source, from the point of view of higher protocol layers and 3291 applications), special Mobile IP processing of the packet is required 3292 for the insertion of the Home Address option. Specifically: 3294 - Construct the packet using the mobile node's home address as the 3295 packet's Source Address, in the same way as if the mobile node 3296 were at home. This preserves the transparency of Mobile IP to 3297 higher protocol layers (e.g., to TCP). 3299 - Insert a Home Address option into the packet, with the Home 3300 Address field copied from the original value of the Source 3301 Address field in the packet. 3303 - Change the Source Address field in the packet's IPv6 header to 3304 one of the mobile node's care-of addresses. This will typically 3305 be the mobile node's current primary care-of address, but MUST 3306 be a care-of address with a subnet prefix that is on-link on the 3307 network interface on which the mobile node will transmit the 3308 packet. 3310 By using the care-of address as the Source Address in the IPv6 3311 header, with the mobile node's home address instead in the Home 3312 Address option, the packet will be able to safely pass through any 3313 router implementing ingress filtering [7]. 3315 10.2. Interaction with Outbound IPsec Processing 3317 As a guidance to implementors, this section sketches the interaction 3318 between outbound Mobile IP processing and outbound IP Security 3319 (IPsec) processing for packets sent by a mobile node while away 3320 from home. Any specific implementation MAY use algorithms and data 3321 structures other than those suggested here, but its processing MUST 3322 be consistent with the effect of the operation described here and 3323 with the relevant IPsec specifications. In the steps described 3324 below, it is assumed that IPsec is being used in transport mode [13] 3325 and that the mobile node is using its home address as the source 3326 for the packet (from the point of view of higher protocol layers or 3327 applications, as described in Section 10.1): 3329 - The packet is created by higher layer protocols and applications 3330 (e.g., by TCP) as if the mobile node were at home and Mobile IP 3331 were not being used. Mobile IP is transparent to such higher 3332 layers. 3334 - As part of outbound packet processing in IP, the packet is 3335 compared against the IPsec Security Policy Database (SPD) to 3336 determine what processing is required for the packet [13]. 3338 - As a special case for Mobile IP, if a Binding Update or 3339 Binding Acknowledgement is being included in the packet, IPsec 3340 authentication, integrity protection, and replay protection MUST 3341 be applied to the packet [13, 11, 12], as defined in Section 4.4. 3342 If the SPD check above has already indicated that authentication 3343 and replay protection are required, this processing is sufficient 3344 for the Mobile IP requirement that all packets containing Binding 3345 Updates or Binding Acknowledgements be authenticated and covered 3346 by replay protection. Otherwise, an implementation can force 3347 the required IPsec processing on this individual packet by, for 3348 example, creating a temporary SPD entry for the handling of this 3349 packet. 3351 - If IPsec processing is required, the packet is either mapped to 3352 an existing Security Association (or SA bundle), or a new SA (or 3353 SA bundle) is created for the packet, according to the procedures 3354 defined for IPsec. 3356 - Since the mobile node is away from home, the mobile node inserts 3357 a Home Address option into the packet, replacing the Source 3358 Address in the packet's IP header with a care-of address suitable 3359 for the link on which the packet is being sent, as described in 3360 Section 10.1. The Destination Options header in which the Home 3361 Address option is inserted MUST appear in the packet before the 3362 AH [11] (or ESP [12]) header, so that the Home Address option is 3363 processed by the destination node before the AH or ESP header is 3364 processed. 3366 - If a Binding Update is being included in the packet, it is 3367 also added to a Destination Options header in the packet. The 3368 Destination Options header in which the Binding Update option is 3369 inserted MAY appear either before or after the AH or ESP header. 3370 If it is inserted before the AH or ESP header, it SHOULD be 3371 placed in the same Destination Options header in which the Home 3372 Address option was inserted. 3374 - Finally, once the packet is fully assembled, the necessary IPsec 3375 authentication (and encryption, if required) processing is 3376 performed on the packet, initializing the Authentication Data in 3377 the AH or ESP header. 3379 In addition, when using any automated key management protocol [13] 3380 (such as IKE [8]) to create any new SA (or SA bundle) while away from 3381 home (whether due to the inclusion of a Binding Update or Binding 3382 Acknowledgement in an outgoing packet, or otherwise), a mobile node 3383 MUST take special care in its processing of the key management 3384 protocol. Otherwise, other nodes with which the mobile node 3385 must communicate as part of the automated key management protocol 3386 processing may be unable to correctly deliver packets to the mobile 3387 node if they and/or the mobile node's home agent do not then have a 3388 current Binding Cache entry for the mobile node. For the default 3389 case of using IKE as the automated key management protocol [8, 13], 3390 such problems can be avoided by the following requirements on the use 3391 of IKE by a mobile node while away from home: 3393 - The mobile node MUST use its care-of address as the Source 3394 Address of all packets it sends as part of the key management 3395 protocol (without use of Mobile IP for these packets, as 3396 suggested in Section 10.1). 3398 - In addition, the mobile node MUST include an ISAKMP 3399 Identification Payload [14] in the IKE exchange, giving the 3400 mobile node's home address as the initiator of the Security 3401 Association [22]. 3403 10.3. Receiving Packets While Away from Home 3405 While away from home, a mobile node will receive packets addressed to 3406 its home address, by one of three methods: 3408 - Packets sent by a correspondent node that does not have a 3409 Binding Cache entry for the mobile node, will be sent by the 3410 correspondent node in the same way as any normal IP packet. Such 3411 packets will then be intercepted by the mobile node's home agent, 3412 encapsulated using IPv6 encapsulation [4], and tunneled to the 3413 mobile node's primary care-of address. 3415 - Packets sent by a correspondent node that has a Binding Cache 3416 entry for the mobile node that contains the mobile node's current 3417 care-of address, will be sent by the correspondent node using 3418 a Routing header. The packet will be addressed to the mobile 3419 node's care-of address, with the final hop in the Routing header 3420 directing the packet to the mobile node's home address; the 3421 processing of this last hop of the Routing header is entirely 3422 internal to the mobile node, since the care-of address and home 3423 address are both addresses within the mobile node. 3425 - Packets sent by a correspondent node that has a Binding Cache 3426 entry for the mobile node that contains an out-of-date care-of 3427 address for the mobile node, will be sent by the correspondent 3428 node using a Routing header, as described above. If the mobile 3429 node sent a Binding Update to a home agent on the link on which 3430 its previous care-of address is located (Section 10.9), and 3431 if this home agent is still serving as a home agent for the 3432 mobile node's previous care-of address, then such a packet will 3433 be intercepted by this home agent, encapsulated using IPv6 3434 encapsulation [4], and tunneled to the mobile node's new care-of 3435 address (registered with this home agent). 3437 For packets received by either the first or last of these three 3438 methods, the mobile node SHOULD send a Binding Update to the original 3439 sender of the packet, as described in Section 10.8, subject to the 3440 rate limiting defined in Section 10.11. The mobile node SHOULD 3441 also process the received packet in the manner defined for IPv6 3442 encapsulation [4], which will result in the encapsulated (inner) 3443 packet being processed normally by upper-layer protocols within the 3444 mobile node, as if it had been addressed (only) to the mobile node's 3445 home address. 3447 For packets received by the second method above (using a Routing 3448 header), the mobile node SHOULD process the received packet in the 3449 manner defined for the type of IPv6 Routing header used [6], which 3450 will result in the packet being processed normally by upper-layer 3451 protocols within the mobile node, as if it had been addressed (only) 3452 to the mobile node's home address. 3454 In addition, the general procedures defined by IPv6 for Routing 3455 headers suggest that a received Routing header MAY be automatically 3456 "reversed" to construct a Routing header for use in any response 3457 packets sent by upper-layer protocols, if the received packet is 3458 authenticated [6]. If this is done for upper-layer protocol response 3459 packets sent by a mobile node while away from home, the mobile 3460 node SHOULD NOT include its own care-of address, which appears in 3461 the Routing header of the received packet, in the reversed route 3462 for the response packet. If the received Routing header contained 3463 no additional hops (other than the mobile node's home address and 3464 care-of address), then any upper-layer protocol response packet 3465 SHOULD NOT include a Routing header. 3467 10.4. Movement Detection 3469 A mobile node MAY use any combination of mechanisms available to it 3470 to detect when it has moved from one link to another. The primary 3471 movement detection mechanism for Mobile IPv6 defined here uses the 3472 facilities of IPv6 Neighbor Discovery, including Router Discovery 3473 and Neighbor Unreachability Detection, although the mobile node MAY 3474 supplement this mechanism with other information available to the 3475 mobile node (e.g., from lower protocol layers). The description 3476 here is based on the conceptual model of the organization and data 3477 structures defined by Neighbor Discovery [17]. 3479 Mobile nodes SHOULD use Router Discovery to discover new routers and 3480 on-link subnet prefixes; a mobile node MAY send Router Solicitation 3481 messages, or MAY wait for unsolicited (periodic) multicast Router 3482 Advertisement messages, as specified for Router Discovery [17]. 3483 Based on received Router Advertisement messages, a mobile node (in 3484 the same way as any other node) maintains an entry in its Default 3485 Router List for each router, and an entry in its Prefix List for each 3486 subnet prefix, that it currently considers to be on-link. Each entry 3487 in these lists has an associated invalidation timer value (extracted 3488 from the Router Advertisement and Prefix Information options) used to 3489 expire the entry when it becomes invalid. 3491 While away from home, a mobile node SHOULD select one router from 3492 its Default Router List to use as its default router, and one subnet 3493 prefix advertised by that router from its Prefix List to use as 3494 the subnet prefix in its primary care-of address. A mobile node 3495 MAY also have associated additional care-of addresses, using other 3496 subnet prefixes from its Prefix List. The method by which a mobile 3497 node selects and forms a care-of address from the available subnet 3498 prefixes is described in Section 10.5. The mobile node registers 3499 its primary care-of address with its home agent, as described in 3500 Section 10.6. 3502 While a mobile node is away from home and using some router as its 3503 default router, it is important for the mobile node to be able to 3504 quickly detect when that router becomes unreachable, so that it can 3505 switch to a new default router and to a new primary care-of address. 3506 Since some links (notably wireless) do not necessarily work equally 3507 well in both directions, it is likewise important for the mobile 3508 node to detect when it becomes unreachable for packets sent from its 3509 default router, so that the mobile node can take steps to ensure that 3510 any correspondent nodes attempting to communicate with it can still 3511 reach it through some other route. 3513 To detect when its default router becomes unreachable, a mobile 3514 node SHOULD use Neighbor Unreachability Detection. As specified in 3515 Neighbor Discovery [17], while the mobile node is actively sending 3516 packets to (or through) its default router, the mobile node can 3517 detect that the router (as its neighbor) is still reachable either 3518 through indications from upper layer protocols on the mobile node 3519 that a connection is making "forward progress" (e.g., receipt of TCP 3520 acknowledgements for new data transmitted), or through receipt of a 3521 Neighbor Advertisement message from its default router in response 3522 to an explicit Neighbor Solicitation messages to it. Note that 3523 although this mechanism detects that the mobile node's default router 3524 has become unreachable to the mobile node only while the mobile node 3525 is actively sending packets to it, this is the only time that this 3526 direction of reachability confirmation is needed. Confirmation 3527 that the mobile node is still reachable from the router is handled 3528 separately, as described below. 3530 For a mobile node to detect when it has become unreachable from its 3531 default router, the mobile node cannot efficiently rely on Neighbor 3532 Unreachability Detection alone, since the network overhead would be 3533 prohibitively high in many cases for a mobile node to continually 3534 probe its default router with Neighbor Solicitation messages even 3535 when it is not otherwise actively sending packets to it. Instead, 3536 a mobile node SHOULD consider receipt of any IPv6 packets from its 3537 current default router as an indication that it is still reachable 3538 from the router. Both packets from the router's IP address and 3539 (IPv6) packets from its link-layer address (e.g., those forwarded but 3540 not originated by the router) SHOULD be considered. 3542 Since the router SHOULD be sending periodic unsolicited multicast 3543 Router Advertisement messages, the mobile node will have frequent 3544 opportunity to check if it is still reachable from its default 3545 router, even in the absence of other packets to it from the router. 3546 If Router Advertisements that the mobile node receives include 3547 an Advertisement Interval option, the mobile node MAY use its 3548 Advertisement Interval field as an indication of the frequency with 3549 which it SHOULD expect to continue to receive future Advertisements 3550 from that router. This field specifies the minimum rate (the maximum 3551 amount of time between successive Advertisements) that the mobile 3552 node SHOULD expect. If this amount of time elapses without the 3553 mobile node receiving any Advertisement from this router, the mobile 3554 node can be sure that at least one Advertisement sent by the router 3555 has been lost. It is thus possible for the mobile node to implement 3556 its own policy for determining the number of Advertisements from 3557 its current default router it is willing to tolerate losing before 3558 deciding to switch to a different router from which it may currently 3559 be correctly receiving Advertisements. 3561 On some types of network interfaces, the mobile node MAY also 3562 supplement this monitoring of Router Advertisements, by setting its 3563 network interface into "promiscuous" receive mode, so that it is able 3564 to receive all packets on the link, including those not link-level 3565 addressed to it (i.e., disabling link-level address filtering). The 3566 mobile node will then be able to detect any packets sent by the 3567 router, in order to to detect reachability from the router. This 3568 use of promiscuous mode may be useful on very low bandwidth (e.g., 3569 wireless) links, but its use MUST be configurable on the mobile node. 3571 If the above means do not provide indication that the mobile node is 3572 still reachable from its current default router (i.e., the mobile 3573 node receives no packets from the router for a period of time), then 3574 the mobile node SHOULD attempt to actively probe the router with 3575 Neighbor Solicitation messages, even if it is not otherwise actively 3576 sending packets to the router. If it receives a solicited Neighbor 3577 Advertisement message in response from the router, then the mobile 3578 node can deduce that it is still reachable. It is expected that the 3579 mobile node will in most cases be able to determine its reachability 3580 from the router by listening for packets from the router as described 3581 above, and thus, such extra Neighbor Solicitation probes should 3582 rarely be necessary. 3584 With some types of networks, it is possible that additional 3585 indications about link-layer mobility can be obtained from 3586 lower-layer protocol or device driver software within the mobile 3587 node. However, a mobile node MUST NOT assume that all link-layer 3588 mobility indications from lower layers indicate a movement of the 3589 mobile node to a new link, such that the mobile node would need to 3590 switch to a new default router and primary care-of address. For 3591 example, movement of a mobile node from one cell to another in many 3592 wireless LANs can be made transparent to the IP level through use of 3593 a link-layer "roaming" protocol, as long as the different wireless 3594 LAN cells all operate as part of the same IP link with the same 3595 subnet prefix. Upon lower-layer indication of link-layer mobility, 3596 the mobile node MAY send Router Solicitation messages to determine if 3597 new routers (and new on-link subnet prefixes) are present on its new 3598 link. 3600 Such lower-layer information might also be useful to a mobile node in 3601 deciding to switch its primary care-of address to one of the other 3602 care-of addresses it has formed from the on-link subnet prefixes 3603 currently available through different routers from which the mobile 3604 node is reachable. For example, a mobile node MAY use signal 3605 strength or signal quality information (with suitable hysteresis) for 3606 its link with the available routers to decide when to switch to a new 3607 primary care-of address using that router rather than its current 3608 default router (and current primary care-of address). Even though 3609 the mobile node's current default router may still be reachable in 3610 terms of Neighbor Unreachability Detection, the mobile node MAY use 3611 such lower-layer information to determine that switching to a new 3612 default router would provide a better connection. 3614 10.5. Forming New Care-of Addresses 3616 After detecting that it has moved from one link to another (i.e., its 3617 current default router has become unreachable and it has discovered 3618 a new default router), a mobile node SHOULD form a new primary 3619 care-of address using one of the on-link subnet prefixes advertised 3620 by the new router. A mobile node MAY form a new primary care-of 3621 address at any time, except that it MUST NOT do so too frequently. 3622 Specifically, a mobile node MUST NOT send a Binding Update about a 3623 new care-of address to its home agent (which is required to register 3624 the new address as its primary care-of address) more often than once 3625 per MAX_UPDATE_RATE seconds. 3627 In addition, after discovering a new on-link subnet prefix, a mobile 3628 node MAY form a new (non-primary) care-of address using that subnet 3629 prefix, even when it has not switched to a new default router. A 3630 mobile node can have only one primary care-of address at a time 3631 (which is registered with its home agent), but it MAY have an 3632 additional care-of address for any or all of the prefixes on its 3633 current link. Furthermore, since a wireless network interface may 3634 actually allow a mobile node to be reachable on more than one link at 3635 a time (i.e., within wireless transmitter range of routers on more 3636 than one separate link), a mobile node MAY have care-of addresses 3637 on more than one link at a time. The use of more than one care-of 3638 address at a time is described in Section 10.17. 3640 As described in Section 4, in order to form a new care-of address, 3641 a mobile node MAY use either stateless [27] or stateful (e.g., 3642 DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to 3643 send packets as part of the method of address autoconfiguration, 3644 it MUST use an IPv6 link-local address rather than its own IPv6 3645 home address as the Source Address in the IPv6 header of each such 3646 autoconfiguration packet. 3648 In some cases, a mobile node may already know a (constant) IPv6 3649 address that has been assigned to it for its use only while 3650 visiting a specific foreign link. For example, a mobile node may be 3651 statically configured with an IPv6 address assigned by the system 3652 administrator of some foreign link, for its use while visiting that 3653 link. If so, rather than using Address Autoconfiguration to form a 3654 new care-of address using this subnet prefix, the mobile node MAY use 3655 its own pre-assigned address as its care-of address on this link. 3657 After forming a new care-of address, a mobile node MAY perform 3658 Duplicate Address Detection [27] on that new address to confirm its 3659 uniqueness. However, doing so represents a tradeoff between safety 3660 (ensuring that the new address is not used if it is a duplicate 3661 address) and overhead (performing Duplicate Address Detection 3662 requires the sending of one or more additional packets over what 3663 may be, for example, a slow wireless link through which the mobile 3664 node is connected). Performing Duplicate Address Detection also 3665 in general would cause a delay before the mobile node could use 3666 the new care-of address, possibly causing the mobile node to be 3667 unable to continue communication with correspondent nodes for some 3668 period of time. For these reasons, a mobile node a mobile node, 3669 after forming a new care-of address, MAY begin using the new care-of 3670 address without performing Duplicate Address Detection. Furthermore, 3671 the mobile node MAY continue using the address without performing 3672 Duplicate Address Detection, although it SHOULD in most cases (e.g., 3673 unless network bandwidth or battery consumption for communication is 3674 of primary concern) begin Duplicate Address Detection asynchronously 3675 when it begins use of the address, allowing the Duplicate Address 3676 Detection procedure to complete in parallel with normal communication 3677 using the address. 3679 In addition, normal processing for Duplicate Address Detection 3680 specifies that, in certain cases, the node SHOULD delay sending the 3681 initial Neighbor Solication message of Duplicate Address Detection 3682 by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27]; 3683 however, in this case, the mobile node SHOULD NOT perform such a 3684 delay in its use of Duplicate Address Detection, unless the mobile 3685 node is intializing after rebooting. 3687 10.6. Sending Binding Updates to the Home Agent 3689 After deciding to change its primary care-of address as described 3690 in Sections 10.4 and 10.5, a mobile node MUST register this care-of 3691 address with its home agent in order to make this its primary care-of 3692 address. To do so, the mobile node sends a packet to its home agent 3693 containing a Binding Update option, with the packet constructed as 3694 follows: 3696 - The Home Registration (H) bit MUST be set in the Binding Update. 3698 - The Acknowledge (A) bit MUST be set in the Binding Update. 3700 - The packet MUST contain a Home Address option, giving the mobile 3701 node's home address for the binding. 3703 - The care-of address for the binding MUST be used as the Source 3704 Address in the packet's IPv6 header, unless an Alternate Care-of 3705 Address sub-option is included in the Binding Update option. 3707 - The Prefix Length field SHOULD be set to the length of the mobile 3708 node's subnet prefix in its home address, to request the mobile 3709 node's home agent to serve as a home agent for all home addresses 3710 for the mobile node based on all on-link subnet prefixes on the 3711 home link. Otherwise, this field MUST be set to zero. 3713 - The value specified in the Lifetime field SHOULD be less than 3714 or equal to the remaining lifetime of the home address and the 3715 care-of address specified for the binding. 3717 The Acknowledge (A) bit in the Binding Update requests the home 3718 agent to return a Binding Acknowledgement in response to this 3719 Binding Update. As described in Section 5.2, the mobile node SHOULD 3720 retransmit this Binding Update to its home agent until it receives 3721 a matching Binding Acknowledgement. Once reaching a retransmission 3722 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 3723 continue to periodically retransmit the Binding Update at this rate 3724 until acknowledged (or until it begins attempting to register a 3725 different primary care-of address). 3727 The Prefix Length field in the Binding Update allows the mobile node 3728 to request its home agent to serve all home addresses for the mobile 3729 node, as indicated by the interface identifier in the mobile node's 3730 home address (the remaining low-order bits after the indicated subnet 3731 prefix), together with each on-link subnet prefix on the home link. 3732 Until the lifetime of this registration expires, the home agent 3733 considers itself the home agent for each such home address of the 3734 mobile node. As the set of on-link subnet prefixes on the home link 3735 changes over time, the home agent changes the set of home addresses 3736 for this mobile node for which it is serving as the home agent. 3738 When sending a Binding Update to its home agent, the mobile node MUST 3739 also create or update the corresponding Binding Update List entry, as 3740 specified in Section 10.8. 3742 If the mobile node has additional home addresses using a different 3743 interface identifier, then the mobile node SHOULD send an additional 3744 packet containing a Binding Update to its home agent to register the 3745 care-of address for each such other home address (or set of home 3746 addresses sharing an interface identifier). These additional Binding 3747 Updates MUST each be sent as a separate packet, since each MUST be 3748 protected by IPsec [13, 11, 12] to authenticate the Binding Update as 3749 coming from the home address being bound, as defined in Section 4.4. 3751 10.7. Dynamic Home Agent Address Discovery 3753 It is possible that when the mobile node needs to send a Binding 3754 Update to its home agent to register its new primary care-of address, 3755 as described in Section 10.6, the mobile node may not know the 3756 address of any router on its home link that can serve as a home agent 3757 for it. For example, some nodes on its home link may have been 3758 reconfigured while the mobile node has been away from home, such that 3759 the router that was operating as the mobile node's home agent has 3760 been replaced by a different router serving this role. 3762 In this case, the mobile node MAY use the dynamic home agent address 3763 discovery mechanism to find the address of a suitable home agent on 3764 its home link. To do so, the mobile node sends an ICMP Home Agent 3765 Address Discovery Request message to the "Mobile IPv6 Home-Agents" 3766 anycast address [10] for its home subnet prefix. This packet MUST 3767 NOT a Home Address option and must be sent using the mobile node's 3768 care-of address as the Source Address in the packet's IP header 3769 (the packet is sent from the care-of address, not using Mobile IP). 3770 As described in Section 9.2, the home agent on its home link that 3771 receives this Request message will return an ICMP Home Agent Address 3772 Discovery Reply message, giving this home agent's own global unicast 3773 IP address along with a list of the global unicast IP address of each 3774 other home agent operating on the home link. 3776 The mobile node, upon receiving this Home Agent Address Discovery 3777 Reply message, MAY then send its home registration Binding Update to 3778 the home agent address given as the IP Source Address of the packet 3779 carrying the Reply message or to any of the unicast IP addresses 3780 listed in the Home Agent Addresses field in the Reply. For example, 3781 if necessary, the mobile node MAY attempt its home registration 3782 with each of these home agents, in turn, by sending each a Binding 3783 Update and waiting for the matching Binding Acknowledgement, until 3784 its registration is accepted by one of these home agents. In trying 3785 each of the returned home agent addresses, the mobile node SHOULD try 3786 each in the order listed in the Home Agent Addresses field in the 3787 received Home Agent Address Discovery Reply message. If the home 3788 agent identified by the Source Address field in the IP header of the 3789 packet carrying the Home Agent Address Discovery Reply message is 3790 not listed in the Home Agent Addresses field in the Reply, it SHOULD 3791 be tried before the first address given in the list; otherwise, it 3792 SHOULD be tried in its listed order. 3794 If the mobile node has a current registration with some home agent 3795 on its home link (the Lifetime for that registration has not yet 3796 expired), then the mobile node MUST attempt any new registration 3797 first with that home agent. If that registration attempt fails 3798 (e.g., times out or is rejected), the mobile node SHOULD then 3799 reattempt this registration with another home agent on its home link. 3800 If the mobile node knows of no other suitable home agent, then it MAY 3801 attempt the dynamic home agent address discovery mechanism described 3802 above. 3804 10.8. Sending Binding Updates to Correspondent Nodes 3806 A mobile node MAY send a Binding Update to any correspondent node at 3807 any time to allow the correspondent node to cache the mobile node's 3808 current care-of address (subject to the rate limiting defined in 3809 Section 10.11). In any Binding Update sent by a mobile node, the 3810 care-of address (either the Source Address in the packet's IPv6 3811 header or the Care-of Address field in the Binding Update) MUST be 3812 set to one of the care-of addresses currently in use by the mobile 3813 node or to the mobile node's home address. 3815 If set to one of the mobile node's current care-of addresses (the 3816 care-of address given MAY differ from the mobile node's primary 3817 care-of address), the Binding Update requests the correspondent node 3818 to create or update an entry for the mobile node in the correspondent 3819 node's Binding Cache to record this care-of address for use in 3820 sending future packets to the mobile node. In this case, the value 3821 specified in the Lifetime field sent in the Binding Update SHOULD be 3822 less than or equal to the remaining lifetime of the home address and 3823 the care-of address specified for the binding. 3825 If, instead, the care-of address is set to the mobile node's home 3826 address, the Binding Update requests the correspondent node to delete 3827 any existing Binding Cache entry that it has for the mobile node. 3828 A mobile node MAY set the care-of address differently for sending 3829 Binding Updates to different correspondent nodes. 3831 When sending any Binding Update, the mobile node MUST record in its 3832 Binding Update List the following fields from the Binding Update: 3834 - The IP address of the node to which the Binding Update was sent. 3836 - The home address for which the Binding Update was sent (the value 3837 in the Home Address option in the packet carrying the Binding 3838 Update). 3840 - The initial lifetime of the binding, initialized from the 3841 Lifetime field sent in the Binding Update. 3843 - The remaining lifetime of the binding, also initialized from 3844 the Lifetime field sent in the Binding Update. This remaining 3845 lifetime value counts down and may also be reduced when the 3846 matching Binding Acknowledgement is received, based on the 3847 Lifetime value specified in that Binding Acknowledgement, as 3848 described in Section 10.12. When the this remaining lifetime 3849 reaches zero, the Binding Update List entry MUST be deleted. 3851 The mobile node MUST retain in its Binding Update List information 3852 about all Binding Updates sent, for which the lifetime of the binding 3853 has not yet expired. However, when sending a Binding Update, if an 3854 entry already exists in the mobile node's Binding Update List for 3855 an earlier Binding Update sent to that same destination node, the 3856 existing Binding Update List entry is updated to reflect the new 3857 Binding Update rather than creating a new Binding Update List entry. 3859 In general, when a mobile node sends a Binding Update to its home 3860 agent to register a new primary care-of address (as described in 3861 Section 10.6), the mobile node will also send a Binding Update to 3862 each other node for which an entry exists in the mobile node's 3863 Binding Update List. Thus, other relevant nodes are generally kept 3864 updated about the mobile node's binding and can send packets directly 3865 to the mobile node using the mobile node's current care-of address. 3867 The mobile node, however, need not send these Binding Updates 3868 immediately after configuring a new care-of address. For example, 3869 since the Binding Update is a destination option and can be included 3870 in any packet sent by a mobile node, the mobile node MAY delay 3871 sending a new Binding Update to any correspondent node for a 3872 short period of time, in hopes that the needed Binding Update 3873 can be included in some packet that the mobile node sends to that 3874 correspondent node for some other reason (for example, as part of 3875 some TCP connection in use). In this case, when sending a packet 3876 to some correspondent node, the mobile node SHOULD check in its 3877 Binding Update List to determine if a new Binding Update to this 3878 correspondent node is needed, and SHOULD include the new Binding 3879 Update in this packet as necessary. 3881 In addition, when a mobile node receives a packet for which the 3882 mobile node can deduce that the original sender of the packet has 3883 no Binding Cache entry for the mobile node, or for which the mobile 3884 node can deduce that the original sender of the packet has an 3885 out-of-date care-of address for the mobile node in its Binding Cache, 3886 the mobile node SHOULD return a Binding Update to the sender giving 3887 its current care-of address (subject to the rate limiting defined 3888 in Section 10.11). In particular, the mobile node SHOULD return a 3889 Binding Update in response to receiving a packet that meets all of 3890 the following tests: 3892 - The packet was tunneled using IPv6 encapsulation. 3894 - The Destination Address in the tunnel (outer) IPv6 header is 3895 equal to any of the mobile node's care-of addresses. 3897 - The Destination Address in the original (inner) IPv6 header 3898 is equal to one of the mobile node's home addresses; or this 3899 Destination Address is equal to one of the mobile node's previous 3900 care-of addresses, if the mobile node has an entry in its Binding 3901 Update List representing an unexpired Binding Update sent to a 3902 home agent on the link on which its previous care-of address is 3903 located (Section 10.9). 3905 - The Source Address in the tunnel (outer) IPv6 header differs from 3906 the Source Address in the original (inner) IPv6 header. 3908 The destination address to which the Binding Update should be sent 3909 in response to receiving a packet meeting all of the above tests is 3910 the Source Address in the original (inner) IPv6 header of the packet. 3911 The home address for which this Binding Update is sent should be the 3912 Destination Address of the original (inner) packet. 3914 Binding Updates sent to correspondent nodes are not generally 3915 required to be acknowledged. However, if the mobile node wants 3916 to be sure that its new care-of address has been entered into a 3917 correspondent node's Binding Cache, the mobile node MAY request an 3918 acknowledgement by setting the Acknowledge (A) bit in the Binding 3919 Update. In this case, however, the mobile node SHOULD NOT continue 3920 to retransmit the Binding Update once the retransmission timeout 3921 period has reached MAX_BINDACK_TIMEOUT. 3923 A mobile node MAY choose to keep its location private from certain 3924 correspondent nodes, and thus need not send new Binding Updates to 3925 those correspondents. A mobile node MAY also send a Binding Update 3926 to such a correspondent node to instruct it to delete any existing 3927 binding for the mobile node from its Binding Cache, as described in 3928 Section 5.1. No other IPv6 nodes are authorized to send Binding 3929 Updates on behalf of a mobile node. 3931 10.9. Establishing Forwarding from a Previous Care-of Address 3933 When a mobile node connects to a new link and forms a new care-of 3934 address, it MAY establish forwarding of packets from a previous 3935 care-of address to this new care-of address. To do so, the mobile 3936 node sends a Binding Update to any home agent on the link on which 3937 the previous care-of address is located, indicating this previous 3938 care-of address as the home address for the binding, and giving its 3939 new care-of address as the binding's care-of address. Such packet 3940 forwarding allows packets destined to the mobile node from nodes that 3941 have not yet learned the mobile node's new care-of address, to be 3942 forwarded to the mobile node rather than being lost once the mobile 3943 node is no longer reachable at this previous care-of address. 3945 In constructing this Binding Update, the mobile node utilizes the 3946 following specific steps: 3948 - The Home Address field in the Home Address option in the packet 3949 carrying the Binding Update MUST be set to the previous care-of 3950 address for which packet forwarding is being established. 3952 - The care-of address for the new binding MUST be set to the new 3953 care-of address to which packets destined to the previous care-of 3954 address are to be forwarded. Normally, this care-of address for 3955 the binding is specified by setting the Source Address of the 3956 packet carrying the Binding Update, to this address. However, 3957 the mobile node MAY instead include an Alternate Care-of Address 3958 sub-option in the Binding Update option, with its Alternate 3959 Care-of Address field set to the care-of address for the binding. 3961 - The Home Registration (H) bit MUST also be set in this Binding 3962 Update, to request this home agent to temporarily act as a home 3963 agent for this previous care-of address. 3965 This home agent will thus tunnel packets for the mobile node (packets 3966 destined to its specified previous care-of address) to its new 3967 care-of address. All of the procedures defined for home agent 3968 operation MUST be followed by this home agent for this registration. 3970 Note that this home agent does not necessarily know (and need not 3971 know) the mobile node's (permanent) home address as part of this 3972 registration. 3974 The packet carrying the Binding Update MUST be addressed to 3975 this home agent's global unicast address. Normally, this global 3976 unicast address is learned by the mobile node based on the Router 3977 Advertisements received by the mobile node (Section 6.2) while 3978 attached to the link on which this previous care-of address and this 3979 home agent are located; the mobile node obtains this home agent 3980 address from its Home Agents List (Section 4.6). Alternatively, 3981 the mobile node MAY use dynamic home agent address discovery 3982 (Section 10.7) to discover the global unicast address of a home agent 3983 on this previous link, but it SHOULD use an address from its Home 3984 Agents List if available for the prefix it used in this previous 3985 care-of address. 3987 As with any packet containing a Binding Update 5.1, the Binding 3988 Update packet to this home agent MUST meet the IPsec requirements for 3989 Binding Updates, defined in Section 4.4. 3991 10.10. Retransmitting Binding Updates 3993 If, after sending a Binding Update in which the Acknowledge (A) 3994 bit is set, a mobile node fails to receive a valid, matching 3995 Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the 3996 mobile node SHOULD retransmit the Binding Update, until a Binding 3997 Acknowledgement is received. Such a retransmitted Binding Update 3998 MUST use a Sequence Number value greater than that used for the 3999 previous transmission of this Binding Update. The retransmissions by 4000 the mobile node MUST use an exponential back-off process, in which 4001 the timeout period is doubled upon each retransmission until either 4002 the node receives a Binding Acknowledgement or the timeout period 4003 reaches the value MAX_BINDACK_TIMEOUT. 4005 10.11. Rate Limiting for Sending Binding Updates 4007 A mobile node MUST NOT send Binding Updates about the same binding to 4008 any individual node more often than once per MAX_UPDATE_RATE seconds. 4009 After sending MAX_FAST_UPDATES consecutive Binding Updates to a 4010 particular node with the same care-of address, the mobile node SHOULD 4011 reduce its rate of sending Binding Updates to that node, to the rate 4012 of SLOW_UPDATE_RATE per second. The mobile node MAY continue to send 4013 Binding Updates at this slower rate indefinitely, in hopes that the 4014 node will eventually be able to process a Binding Update and begin 4015 to route its packets directly to the mobile node at its new care-of 4016 address. 4018 10.12. Receiving Binding Acknowledgements 4020 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 4021 node MUST validate the packet according to the following tests: 4023 - The packet meets the specific IPsec requirements for Binding 4024 Acknowledgements, defined in Section 4.4. 4026 - The Option Length field in the option is greater than or equal to 4027 11 octets. 4029 - The Sequence Number field matches the Sequence Number sent by the 4030 mobile node to this destination address in an outstanding Binding 4031 Update. 4033 Any Binding Acknowledgement not satisfying all of these tests MUST be 4034 silently ignored, although the remainder of the packet (i.e., other 4035 options, extension headers, or payload) SHOULD be processed normally 4036 according to any procedure defined for that part of the packet. 4038 When a mobile node receives a packet carrying a valid Binding 4039 Acknowledgement, the mobile node MUST examine the Status field as 4040 follows: 4042 - If the Status field indicates that the Binding Update was 4043 accepted (the Status field is less than 128), then the mobile 4044 node MUST update the corresponding entry in its Binding Update 4045 List to indicate that the Binding Update has been acknowledged; 4046 the mobile node MUST then stop retransmitting the Binding Update. 4047 In addition, if the value specified in the Lifetime field in the 4048 Binding Acknowledgement is less than the Lifetime value sent 4049 in the Binding Update being acknowledged, then the mobile node 4050 MUST subtract the difference between these two Lifetime values 4051 from the remaining lifetime for the binding as maintained in the 4052 corresponding Binding Update List entry (with a minimum value 4053 for the Binding Update List entry lifetime of 0). That is, if 4054 the Lifetime value sent in the Binding Update was L_update, the 4055 Lifetime value received in the Binding Acknowledgement was L_ack, 4056 and the current remaining lifetime of the Binding Update List 4057 entry is L_remain, then the new value for the remaing lifetime of 4058 the Binding Update List entry should be 4060 max((L_remain - (L_update - L_ack)), 0) 4062 where max(X, Y) is the maximum of X and Y. The effect of this 4063 step is to correctly manage the mobile node's view of the 4064 binding's remaining lifetime (as maintained in the corresponding 4065 Binding Update List entry) so that it correctly counts down from 4066 the Lifetime value given in the Binding Acknowledgement, but with 4067 the timer countdown beginning at the time that the Binding Update 4068 was sent. 4070 - If the Status field indicates that the Binding Update was 4071 rejected (the Status field is greater than or equal to 128), then 4072 the mobile node MUST delete the corresponding Binding Update List 4073 entry (and MUST also stop retransmitting the Binding Update). 4074 Optionally, the mobile node MAY then take steps to correct the 4075 cause of the error and retransmit the Binding Update (with a new 4076 Sequence Number value), subject to the rate limiting restriction 4077 specified in Section 10.11. 4079 10.13. Receiving Binding Requests 4081 When a mobile node receives a packet containing a Binding Request, 4082 it SHOULD return to the sender a packet containing a Binding Update. 4083 The Lifetime field in this Binding Update SHOULD be set to a new 4084 lifetime, extending any current lifetime remaining from a previous 4085 Binding Update sent to this node (as indicated in any existing 4086 Binding Update List entry for this node), except that this lifetime 4087 MUST NOT exceed the remaining lifetime for the mobile node's primary 4088 care-of address registration at its home agent. When sending this 4089 Binding Update, the mobile node MUST update its Binding Update List 4090 in the same way as for any other Binding Update sent by the mobile 4091 node. 4093 Note, however, that the mobile node MAY choose to keep its current 4094 binding private from the sender of the Binding Request. In this 4095 case, the mobile node instead SHOULD returns a Binding Update to the 4096 sender, in which the Lifetime field is set to zero and the care-of 4097 address is set to the mobile node's home address. 4099 If the Binding Request for which the Binding Update is being returned 4100 contains a Unique Identifer Sub-Option, the Binding Update MUST also 4101 include a Unique Identifier Sub-Option. The unique identifier in the 4102 SUb-Option Data field of the Unique Identifier Sub-Option MUST be 4103 copied from the unique identifier carried in the Binding Request. 4105 10.14. Receiving ICMP Error Messages 4107 The Option Type value for a Binding Update option specifies that 4108 any node receiving this option that does not recognize the Option 4109 Type SHOULD return an ICMP Parameter Problem, Code 2, message to 4110 the sender of the packet containing the Binding Update option. If 4111 a node sending a Binding Update receives such an ICMP error message 4112 in response, it SHOULD record in its Binding Update List that future 4113 Binding Updates SHOULD NOT be sent to this destination. 4115 Likewise, although ALL IPv6 nodes (whether host or router, whether 4116 mobile or stationary) MUST implement the ability to correctly process 4117 received packets containing a Home Address option, all Option Type 4118 values in IPv6 include a specification of the behavior that a node 4119 receiving a packet containing this option performs if it does not 4120 implement receipt of that type of option. For the Home Address 4121 option, the Option Type value specifies that any node receiving 4122 this option that does not recognize the Option Type SHOULD return 4123 an ICMP Parameter Problem, Code 2, message to the sender of the 4124 packet containing the Home Address option. If a mobile node receives 4125 such an ICMP error message from some node indicating that it does 4126 not recognize the mobile node's Home Address option, the mobile 4127 node SHOULD log the error and then discard the ICMP message; this 4128 error message indicates that the node to which the original packet 4129 was addressed (the node returning the ICMP error message) does not 4130 correctly implement this required part of the IPv6 protocol. 4132 10.15. Receiving Local Router Advertisement Messages 4134 Each mobile node maintains a Home Agents List recording information 4135 about all home agents from which it receives a Router Advertisement, 4136 for which the home agent lifetime indicated in that Router 4137 Advertisement has not yet expired. This list is used by the mobile 4138 node to enable it to send a Binding Update to the global unicast 4139 address of a home agent on its previous link when it moves to a new 4140 link, as described in Section 10.9. On receipt of a valid Router 4141 Advertisement, as defined in the processing algorithm specified for 4142 Neighbor Discovery [17], the mobile node performs the following 4143 steps, in addition to any steps already required of it by Neighbor 4144 Discovery and by other procedures described in this document: 4146 - If the Home Agent (H) bit in the Router Advertisement is not 4147 set, skip all of the following steps. There are no special 4148 processing steps required by this aspect of Mobile IP for this 4149 Router Advertisement, since the Advertisement was not sent by a 4150 home agent. 4152 - Otherwise, extract the Source Address from the IP header of the 4153 Router Advertisement. This is the link-local IP address on this 4154 link of the home agent sending this Advertisement [17]. 4156 - Determine from the Router Advertisement the preference for this 4157 home agent. If the Router Advertisement contains a Home Agent 4158 Information Option, then the preference is taken from the Home 4159 Agent Preference field in the option; otherwise, the default 4160 preference of 0 SHOULD be used. 4162 - Determine from the Router Advertisement the lifetime for 4163 this home agent. If the Router Advertisement contains a Home 4164 Agent Information Option, then the lifetime is taken from 4165 the Home Agent Lifetime field in the option; otherwise, the 4166 lifetime specified by the Router Lifetime field in the Router 4167 Advertisement SHOULD be used. 4169 - If the link-local address of the home agent sending this 4170 Advertisement is already present in this mobile node's Home 4171 Agents List and the received home agent lifetime value is zero, 4172 immediately delete this entry in the Home Agents List. 4174 - Otherwise, if the link-local address of the home agent sending 4175 this Advertisement is already present in the receiving mobile 4176 node's Home Agents List, reset its lifetime and preference to the 4177 values determined above. 4179 - If the link-local address of the home agent sending this 4180 Advertisement, as determined above, is not already present in the 4181 Home Agents List maintained by the receiving mobile node, and 4182 the lifetime for the sending home agent, as determined above, 4183 is non-zero, create a new entry in the list, and initialize its 4184 lifetime and preference to the values determined above. 4186 - If the Home Agents List entry for the link-local address of 4187 the home agent sending this Advertisement was not deleted as 4188 described above, determine any global address(es) of the home 4189 agent based on each Prefix Information option received in 4190 this Advertisement in which the Router Address (R) bit is set 4191 (Section 6.2). For each such global address determined from this 4192 Advertisement, add this global address to the list of global 4193 addresses for this home agent in this Home Agents List entry. 4195 A mobile node SHOULD maintain an entry in its Home Agents List for 4196 each such valid home agent address until that entry's lifetime 4197 expires, after which time the entry MUST be deleted. 4199 10.16. Receiving Tunneled Router Advertisements 4201 Section 9.7 describes the operation of a home agent to support 4202 renumbering a mobile node's home subnet while the mobile node is 4203 away from home. The home agent tunnels certain Router Advertisement 4204 messages to the mobile node while away from home, giving "important" 4205 Prefix Information options that describe changes in the prefixes in 4206 use on the mobile node's home link. 4208 When a mobile node receives a tunneled Router Advertisement, it MUST 4209 validate it according to the following tests: 4211 - The Source Address of the IP packet carrying the Router 4212 Advertisement is the same as the home agent address to which the 4213 mobile node last sent an accepted "home registration" Binding 4214 Update to register its primary care-of address. 4216 - The packet MUST be protected by IPsec [13, 11, 12] to guard 4217 against malicious Router Advertisements. The IPsec protection 4218 MUST provide sender authentication, data integrity protection, 4219 and replay protection, covering the Router Advertisement. 4221 - The packet contains a Binding Request destination option. 4223 - The Binding Request option contains a Unique Identifier 4224 Sub-Option. 4226 Any received tunneled Router Advertisement not meeting all of these 4227 tests MUST be silently discarded. 4229 If a received tunneled Router Advertisement is not discarded 4230 according to the tests listed above, the mobile node MUST process the 4231 Router Advertisement as if it were connected to its home link [17]. 4232 Such processing may result in the mobile node configuring a new home 4233 address, although due to separation between preferred lifetime and 4234 valid lifetime, such changes should not affect most communication by 4235 the mobile node, in the same way as for nodes that are at home. 4237 In processing the packet containing this Router Advertisement, the 4238 mobile node SHOULD return to the home agent a Binding Update in 4239 response to the Binding Request carried in the packet. The correct 4240 formation of this Binding Update by the mobile node and processing 4241 of it by the home agent will be viewed by the home agent as an 4242 acknowledgement of this Router Advertisement, confirming to it that 4243 this Router Advertisement was received by the mobile node. 4245 In addition, if processing of this Router Advertisement resulted in 4246 the mobile node configuring a new home address, and if the method 4247 used for this new home address configuration would require the mobile 4248 node to perform Duplicate Address Detection [27] for the new address 4249 if the mobile node were located at home, then the mobile node MUST 4250 set the Duplicate Address Detection (D) bit in this Binding Update to 4251 its home agent, to request the home agent to perform this Duplicate 4252 Address Detection on behalf of the mobile node. 4254 10.17. Using Multiple Care-of Addresses 4256 As described in Section 10.5, a mobile node MAY use more than one 4257 care-of address at a time. Particularly in the case of many wireless 4258 networks, a mobile node effectively might be reachable through 4259 multiple links at the same time (e.g., with overlapping wireless 4260 cells), on which different on-link subnet prefixes may exist. A 4261 mobile node SHOULD select a primary care-of address from among those 4262 care-of addresses it has formed using any of these subnet prefixes, 4263 based on the movement detection mechanism in use, as described in 4264 Section 10.4. When the mobile node selects a new primary care-of 4265 address, it MUST register it with its home agent by sending it a 4266 Binding Update with the Home Registration (H) and Acknowledge (A) 4267 bits set, as described in Section 10.6. 4269 To assist with smooth handoffs, a mobile node SHOULD retain 4270 its previous primary care-of address as a (non-primary) care-of 4271 address, and SHOULD still accept packets at this address, even after 4272 registering its new primary care-of address with its home agent. 4273 This is reasonable, since the mobile node could only receive packets 4274 at its previous primary care-of address if it were indeed still 4275 connected to that link. If the previous primary care-of address was 4276 allocated using stateful Address Autoconfiguration [2], the mobile 4277 node may not wish to release the address immediately upon switching 4278 to a new primary care-of address. 4280 10.18. Routing Multicast Packets 4282 A mobile node that is connected to its home link functions in the 4283 same way as any other (stationary) node. Thus, when it is at home, 4284 a mobile node functions identically to other multicast senders and 4285 receivers. This section therefore describes the behavior of a mobile 4286 node that is not on its home link. 4288 In order to receive packets sent to some multicast group, a mobile 4289 node must join that multicast group. One method by which a mobile 4290 node MAY join the group is via a (local) multicast router on the 4291 foreign link being visited. The mobile node SHOULD use its care-of 4292 address sharing a subnet prefix with the multicast router, as 4293 the source IPv6 address of its multicast group membership control 4294 messages. 4296 Alternatively, a mobile node MAY join multicast groups via a 4297 bi-directional tunnel to its home agent. The mobile node tunnels its 4298 multicast group membership control packets to its home agent, and the 4299 home agent forwards multicast packets down the tunnel to the mobile 4300 node. 4302 A mobile node that wishes to send packets to a multicast group 4303 also has two options: (1) send directly on the foreign link being 4304 visited; or (2) send via a tunnel to its home agent. Because 4305 multicast routing in general depends upon the Source Address used in 4306 the IPv6 header of the multicast packet, a mobile node that tunnels a 4307 multicast packet to its home agent MUST use its home address as the 4308 IPv6 Source Address of the inner multicast packet. 4310 10.19. Returning Home 4312 A mobile node detects that it has returned to its home link through 4313 the movement detection algorithm in use (Section 10.4), when the 4314 mobile node detects that its home subnet prefix is again on-link. 4315 The mobile node SHOULD then send a Binding Update to its home agent, 4316 to instruct its home agent to no longer intercept or tunnel packets 4317 for it. In this Binding Update, the mobile node MUST set the care-of 4318 address for the binding (the Source Address field in the packet's 4319 IPv6 header) to the mobile node's own home address. As with other 4320 Binding Updates sent to register with its home agent, the mobile 4321 node MUST set the Acknowledge (A) and Home Registration (H) bits, 4322 and SHOULD retransmit the Binding Update until a matching Binding 4323 Acknowledgement is received. 4325 When sending this Binding Update to its home agent, the mobile 4326 node must be careful in how it uses Neighbor Soliciation [17] (if 4327 needed) to learn the home agent's link-layer address, since the home 4328 agent will be currently configured to defend the mobile node's home 4329 address for Duplicate Address Detection. In particular, a Neighbor 4330 Solicitation from the mobile node using its home address as the 4331 Source Address would be detected by the home agent as a duplicate 4332 address. In many cases, Neighbor Solicitation by the mobile node 4333 for the home agent's address will not be necessary, since the mobile 4334 node may have already learned the home agent's link-layer address, 4335 for example from a Source Link-Layer Address option in the Router 4336 Advertisement from which it learned that its home address was on-link 4337 and that the mobile node had thus returned home. If the mobile node 4338 does Neighbor Solicitation to learn the home agent's link-layer 4339 address, in this special case of the mobile node returning home, the 4340 mobile node MUST set the Source Address of this Neighbor Solicitation 4341 to the unspecified address. 4343 The mobile node then sends its Binding Update using the home agent's 4344 link-layer address, instructing its home agent to no longer serve 4345 as a home agent for it. By processing this Binding Update, the 4346 home agent will cease defending the mobile node's home address for 4347 Duplicate Address Detection and will no longer respond to Neighbor 4348 Solicitations for the mobile node's home address. The mobile node is 4349 then the only node on the link using the mobile node's home address. 4350 In addition, when returning home and configuring its home address 4351 on its network interface on its home link, the mobile node MUST NOT 4352 perform Duplicate Address Detection on its own home address, in order 4353 to avoid confusion or conflict with its home agent's use of the same 4354 address. 4356 After receiving the Binding Acknowledgement for its Binding Update 4357 to its home agent, the mobile node MUST multicast onto the home 4358 link (to the all-nodes multicast address) a Neighbor Advertisement 4359 message [17], to advertise the mobile node's own link-layer address 4360 for its own home address. The Target Address in this Neighbor 4361 Advertisement message MUST be set to the mobile node's home address, 4362 and the Advertisement MUST include a Target Link-layer Address option 4363 specifying the mobile node's link-layer address. The mobile node 4364 MUST multicast such a Neighbor Advertisement message for each of its 4365 home addresses, as defined by the current on-link prefixes, including 4366 its link-local address and site-local address. The Solicited 4367 Flag (S) in these Advertisements MUST NOT be set, since they were 4368 not solicited by any Neighbor Solicitation message. The Override 4369 Flag (O) in these Advertisements MUST be set, indicating that the 4370 Advertisements SHOULD override any existing Neighbor Cache entries at 4371 any node receiving them. 4373 Since multicasts on the local link (such as Ethernet) are typically 4374 not guaranteed to be reliable, the mobile node MAY retransmit these 4375 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 4376 increase their reliability. It is still possible that some nodes on 4377 the home link will not receive any of these Neighbor Advertisements, 4378 but these nodes will eventually be able to recover through use of 4379 Neighbor Unreachability Detection [17]. 4381 11. Protocol Constants 4383 INITIAL_BINDACK_TIMEOUT 1 second 4385 MAX_BINDACK_TIMEOUT 256 seconds 4387 MAX_UPDATE_RATE once per second 4389 SLOW_UPDATE_RATE once per 10 seconds 4391 MAX_FAST_UPDATES 5 transmissions 4393 MAX_ADVERT_REXMIT 3 transmissions 4395 12. IANA Considerations 4397 This document defines four new types of IPv6 destination options, 4398 each of which must be assigned an Option Type value: 4400 - The Binding Update option, described in Section 5.1; 4402 - The Binding Acknowledgement option, described in Section 5.2; 4404 - The Binding Request option, described in Section 5.3; and 4406 - The Home Address option, described in Section 5.4. 4408 In addition, this document defines two ICMP message types, used as 4409 part of the dynamic home agent address discovery mechanism: 4411 - The Home Agent Address Discovery Request message, described in 4412 Section 5.6; and 4414 - The Home Agent Address Discovery Reply message, described in 4415 Section 5.7. 4417 This document also defines two new Neighbor Discovery [17] options, 4418 which must be assigned Option Type values within the option numbering 4419 space for Neighbor Discovery messages: 4421 - The Advertisement Interval option, described in Section 6.3; and 4423 - The Home Agent Information option, described in Section 6.4. 4425 Finally, this document defines a new type of anycast address, which 4426 must be assigned a reserved value for use with any subnet prefix to 4427 define this anycast address on each subnet: 4429 - The "Mobile IPv6 Home-Agents" anycast address [10], used in the 4430 dynamic home agent address discovery mechanism described in 4431 Sections 9.2 and 10.7. 4433 13. Security Considerations 4435 13.1. Binding Updates, Acknowledgements, and Requests 4437 The Binding Update option described in this document will result 4438 in packets addressed to a mobile node being delivered instead to 4439 its care-of address. This ability to change the routing of these 4440 packets could be a significant vulnerability if any packet containing 4441 a Binding Update option was not authenticated. Such use of "remote 4442 redirection", for instance as performed by the Binding Update option, 4443 is widely understood to be a security problem in the current Internet 4444 if not authenticated [1]. 4446 The Binding Acknowledgement option also requires authentication, 4447 since, for example, an attacker could otherwise trick a mobile node 4448 into believing a different outcome from a registration attempt with 4449 its home agent. 4451 No authentication is required for the Binding Request option, since 4452 the use of this option does not modify or create any state in either 4453 the sender or the receiver. The Binding Request option does open 4454 some issues with binding privacy, but those issues can be dealt with 4455 either through existing IPsec encryption mechanisms or through use of 4456 firewalls. 4458 The existing IPsec replay protection mechanisms allow a "replay 4459 protection window" to support receiving packets out of order. 4460 Although appropriate for many forms of communication, Binding Updates 4461 MUST be applied only in the order sent. The Binding Update option 4462 thus includes a Sequence Number field to provide this necessary 4463 sequencing. The use of this Sequence Number together with IPsec 4464 replay protection is similar in many ways, for example, to the the 4465 sequence number in TCP. IPsec provides strong replay protection but 4466 no ordering, and the sequence number provides ordering but need not 4467 worry about replay protection such as through the sequence number 4468 wrapping around. 4470 13.2. Home Address Option 4472 No special authentication of the Home Address option is required, 4473 except that if the IPv6 header of a packet is covered by 4474 authentication, then that authentication MUST also cover the Home 4475 Address option; this coverage is achieved automatically by the 4476 definition of the Option Type code for the Home Address option 4477 (Section 5.4), since it indicates that the option is included in the 4478 authentication computation. Thus, even when authentication is used 4479 in the IPv6 header, the security of the Source Address field in the 4480 IPv6 header is not compromised by the presence of a Home Address 4481 option. Without authentication of the packet, then any field in the 4482 IPv6 header, including the Source Address field, and any other parts 4483 of the packet, including the Home Address option, can be forged or 4484 modified in transit. In this case, the contents of the Home Address 4485 option is no more suspect than any other part of the packet. 4487 The use of the Home Address option allows packets sent by a 4488 mobile node to pass normally through routers implementing ingress 4489 filtering [7]. Since the care-of address used in the Source Address 4490 field of the packet's IPv6 header is topologically correct for the 4491 sending location of the mobile node, ingress filtering can trace the 4492 location of the mobile node in the same way as can be done with any 4493 sender when ingress filtering is in use. 4495 However, if a node receiving a packet that includes a Home Address 4496 option implements the processing of this option by physically 4497 copying the Home Address field from the option into the IPv6 header, 4498 replacing the Source Address field there, then the ability to 4499 trace the true location of the sender is removed once this step 4500 in the processing is performed. This diminishing of the power of 4501 ingress filtering only occurs once the packet has been received at 4502 its ultimate destination, and does not affect the capability of 4503 ingress filtering while the packet is in transit. Furthermore, this 4504 diminishing can be entirely eliminated by appropriate implementation 4505 techniques in the receiving node. For example, the original contents 4506 of the Source Address field (the sending care-of address) could be 4507 saved elsewhere in memory with the packet, until all processing of 4508 the packet is completed. 4510 13.3. General Mobile Computing Issues 4512 The mobile computing environment is potentially very different from 4513 the ordinary computing environment. In many cases, mobile computers 4514 will be connected to the network via wireless links. Such links 4515 are particularly vulnerable to passive eavesdropping, active replay 4516 attacks, and other active attacks. Furthermore, mobile computers 4517 are more susceptible to loss or theft than stationary computers. 4518 Any secrets such as authentication or encryption keys stored on the 4519 mobile computer are thus subject to compromise in ways generally not 4520 common in the non-mobile environment. 4522 Users who have sensitive data that they do not wish others to have 4523 access to SHOULD use additional mechanisms (such as encryption) to 4524 provide privacy protection, but such mechanisms are beyond the scope 4525 of this document. Users concerned about traffic analysis SHOULD 4526 consider appropriate use of link encryption. If stronger location 4527 privacy is desired, the mobile node can create a tunnel to its home 4528 agent. Then, packets destined for correspondent nodes will appear 4529 to emanate from the home subnet, and it may be more difficult to 4530 pinpoint the location of the mobile node. Such mechanisms are all 4531 beyond the scope of this document. 4533 Changes from Previous Version of the Draft 4535 This appendix briefly lists some of the major changes in this 4536 draft relative to the previous version of this same draft, 4537 draft-ietf-mobileip-ipv6-11.txt: 4539 - Moved the definition of IPsec requirements for Binding Updates 4540 and Binding Acknowledgements to Section 4.4), giving this 4541 important information its own specific section with a section 4542 title (IPsec Requirements for Mobile IPv6 Destination Options) 4543 that will be identifiable in the table of contents for this 4544 document. This makes these requirements harder to miss than 4545 where they were defined in Sections 5.1 and 5.2, mixed in with 4546 the definition of the format of these destination options. 4548 - In Section 4.6, added a precise definition of Sequence Number 4549 value comparison modulo 2**16. Also added a reference to this 4550 definition in each other place where Sequence Number comparison 4551 is discussed. 4553 - Added a statement in Section 9.5 to clarify the sending of a 4554 Neighbor Advertisement message by the home agent on behalf of the 4555 mobile node in order to intercept packets addressed to the mobile 4556 node. Except for the specific fields defined there, all fields 4557 in each such Neighbor Advertisement SHOULD be set in the same 4558 way they would be set by the mobile node itself if sending this 4559 Neighbor Advertisement while at home [17]. 4561 - In Section 10.6, specified that the Lifetime in the Binding 4562 Update sent by a mobile node to its home agent SHOULD be less 4563 than or equal to the remaining lifetime of the home address and 4564 the care-of address specified for the binding. 4566 - In Section 10.8, modified the specification that was there 4567 about the correct setting of the Lifetime in the Binding 4568 Update sent by a mobile node to a correspondent node. The 4569 original specification stated that the Lifetime value MUST be no 4570 greater than the remaining lifetime of the mobile node's home 4571 registration of its primary care-of address at its home agent. 4572 However, there should be no necessary relationship between the 4573 remaining lifetime of a home registration and the lifetime of 4574 a binding at a correspondent node. Instead, as with the home 4575 registration Binding Update, the Lifetime in the Binding Update 4576 sent by a mobile node to a correspondent node SHOULD be less than 4577 or equal to the remaining lifetime of the home address and the 4578 care-of address specified for the binding. 4580 - In Section 5.4, added a statement that a packet MUST NOT contain 4581 more than one Home Address option, except that an encapsulated 4582 packet [4] MAY contain a separate Home Address option associated 4583 with each encapsulating IP header. 4585 - In Section 4.6, added a new field in the Binding Update List 4586 entry format to record the initial value of the Lifetime field 4587 sent in that Binding Update. 4589 - In Section 10.12, defined a new step in processing a received 4590 Binding Acknowledgement: if the value specified in the Lifetime 4591 field in the Binding Acknowledgement is less than the Lifetime 4592 value sent in the Binding Update being acknowledged, then the 4593 mobile node MUST subtract the difference between these two 4594 Lifetime values from the remaining lifetime for the binding 4595 as maintained in the corresponding Binding Update List entry. 4596 The effect of this step is to correctly manage the mobile 4597 node's view of the binding's remaining lifetime (as maintained 4598 in the corresponding Binding Update List entry) so that it 4599 correctly counts down from the Lifetime value given in the 4600 Binding Acknowledgement, but with the timer countdown beginning 4601 at the time that the Binding Update was sent. This change also 4602 affected Section 10.8 in sending Binding Updates, to record both 4603 the original lifetime and the remaining lifetime in the Binding 4604 Update List. 4606 - In Sections 5.1 and 9.3, clarified that the Duplicate Address 4607 Detection performed by the home agent if the Duplicate Address 4608 Detection (D) bit is set in the Binding Update, is performed 4609 before returning the Binding Acknowledgement for that Binding 4610 Update. 4612 - In Section 5.1, clarified that the mobile node SHOULD set the 4613 Duplicate Address Detection (D) bit in its home registration 4614 Binding Updates based on any requirements for Duplicate Address 4615 Detection that would apply to the mobile node if it were at 4616 home [17, 27]. 4618 - In Section 9.3, specified that a home agent, when performing 4619 Duplicate Address Detection for a mobile node when the 4620 Duplicate Address Detection (D) bit is set in a received 4621 Binding Update, SHOULD NOT delay sending the initial Neighbor 4622 Solicitation message of Duplicate Address Detection by the random 4623 delay specified for normal processing of Duplicate Address 4624 Detection [17, 27]. 4626 - In Section 10.5, defined special considerations for a mobile 4627 node's use of Duplicate Address Detection upon forming a new 4628 care-of address. In particular, the mobile node MAY begin 4629 using the new care-of address without performing Duplicate 4630 Address Detection, and MAY optionally bypass Duplicate Address 4631 Detection or begin Duplicate Address Detection asynchronously 4632 when it begins use of the address, allowing the Duplicate 4633 Address Detection procedure to complete in parallel with 4634 normal communication using the address. In addition, the 4635 mobile node SHOULD NOT delay sending the initial Neighbor 4636 Solicitation message of Duplicate Address Detection by the random 4637 delay specified for normal processing of Duplicate Address 4638 Detection [17, 27], unless the mobile node is initializing after 4639 rebooting. 4641 - In Section 4.6, added a clarification to the definition of the 4642 Binding Update List, that for multiple Binding Updates sent to 4643 the same destination address, the Binding Update List contains 4644 only the most recent Binding Update (i.e., with the greatest 4645 Sequence Number value) sent to that destination. This was 4646 already noted in previous versions of the draft in the sending of 4647 Binding Updates, as defined in Section update-corresp, but was 4648 not previously stated explicitly in the definition of the Binding 4649 Update List conceptual data structure. 4651 - In Section 9.3, added a specification that the lifetime for the 4652 Binding Cache entry (and thus the Lifetime value returned in the 4653 Binding Acknowledgement) MUST NOT be greater than the Lifetime 4654 value specified in the Binding Update. Also added a similar 4655 specification (and clarification) in Section 8.3 for the Binding 4656 Cache entry in a correspondent node. 4658 - In Section 10.6, added a clarification that, when sending a 4659 Binding Update to its home agent, the mobile node MUST also 4660 create or update the corresponding Binding Update List entry, as 4661 specified in Section 10.8. 4663 Acknowledgements 4665 We would like to thank the members of the Mobile IP and IPng 4666 Working Groups for their comments and suggestions on this work. 4667 We would particularly like to thank (in alphabetical order) 4668 Fred Baker (Cisco), Josh Broch (Carnegie Mellon University), 4669 Rich Draves (Microsoft Research), Francis Dupont (INRIA), Thomas 4670 Eklund (SwithCore), Jun-Ichiro Hagino (IIJ Research Laboratory), 4671 Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), Erik Nordmark 4672 (Sun Microsystems), Simon Nybroe (Ericsson Telebit), David Oran 4673 (Cisco), Basavaraj Patil (Nokia), Ken Powell (Compaq), Phil Roberts 4674 (Motorola), Patrice Romand (Bull S.A.), Tom Soderlund (Nokia 4675 Research), Hesham Soliman (Ericsson), Jim Solomon (RedBack Networks), 4676 Benny Van Houdt (University of Antwerp), Jon-Olov Vatn (KTH), and 4677 Xinhua Zhao (Stanford University) for their detailed reviews of 4678 earlier versions of this document. Their suggestions have helped to 4679 improve both the design and presentation of the protocol. 4681 We would also like to thank the participants in the Mobile IPv6 4682 testing event held at Nancy, France, September 15-17, 1999, for 4683 their valuable feedback as a result of interoperability testing 4684 of four Mobile IPv6 implementations coming from four different 4685 organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC 4686 (FreeBSD), and INRIA (FreeBSD). Finally, we would like to thank the 4687 feedback from the implementors who participated in the Mobile IPv6 4688 interoperability testing at Connectathon 2000 in San Jose, 4689 California, March 6-9, 2000. 4691 References 4693 [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 4694 ACM Computer Communications Review, 19(2), March 1989. 4696 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 4697 Protocol for IPv6 (DHCPv6), February 1999. Work in progress. 4699 [3] Scott Bradner. Key words for use in RFCs to indicate 4700 requirement levels. RFC 2119, March 1997. 4702 [4] Alex Conta and Stephen Deering. Generic packet tunneling in 4703 IPv6 specification. RFC 2473, December 1998. 4705 [5] Alex Conta and Stephen Deering. Internet Control Message 4706 Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6) 4707 specification. RFC 2463, December 1998. 4709 [6] Stephen E. Deering and Robert M. Hinden. Internet Protocol 4710 version 6 (IPv6) specification. RFC 2460, December 1998. 4712 [7] Paul Ferguson and Daniel Senie. Network ingress filtering: 4713 Defeating denial of service attacks which employ IP source 4714 address spoofing. RFC 2267, January 1998. 4716 [8] Dan Harkins and Dave Carrel. The Internet Key Exchange (IKE). 4717 RFC 2409, November 1998. 4719 [9] Robert M. Hinden and Stephen E. Deering. IP Version 6 4720 addressing architecture. RFC 2373, July 1998. 4722 [10] David B. Johnson and Stephen E. Deering. Reserved IPv6 subnet 4723 anycast addresses. RFC 2526, March 1999. 4725 [11] Stephen Kent and Randall Atkinson. IP Authentication header. 4726 RFC 2402, November 1998. 4728 [12] Stephen Kent and Randall Atkinson. IP Encapsulating Security 4729 Payload (ESP). RFC 2406, November 1998. 4731 [13] Stephen Kent and Randall Atkinson. Security architecture for 4732 the Internet Protocol. RFC 2401, November 1998. 4734 [14] Douglas Maughan, Mark Schneider, Mark Schertler, and Jeff 4735 Turner. Internet Security Association and Key Management 4736 Protocol (ISAKMP). RFC 2408, November 1998. 4738 [15] P. Mockapetris. Domain Names -- concepts and facilities. 4739 RFC 1034, November 1987. 4741 [16] P. Mockapetris. Domain Names -- implementation and 4742 specification. RFC 1035, November 1987. 4744 [17] Thomas Narten, Erik Nordmark, and William Allen Simpson. 4745 Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December 4746 1998. 4748 [18] Charles Perkins. IP encapsulation within IP. RFC 2003, October 4749 1996. 4751 [19] Charles Perkins, editor. IP mobility support. RFC 2002, 4752 October 1996. 4754 [20] Charles Perkins. Minimal encapsulation within IP. RFC 2004, 4755 October 1996. 4757 [21] Charles Perkins and David B. Johnson. Route optimization in 4758 Mobile IP, February 1999. Work in progress. 4760 [22] Derrell Piper. The Internet IP security domain of 4761 interpretation for ISAKMP. RFC 2407, November 1998. 4763 [23] David C. Plummer. An Ethernet address resolution protocol: 4764 Or converting network protocol addresses to 48.bit Ethernet 4765 addresses for transmission on Ethernet hardware. RFC 826, 4766 November 1982. 4768 [24] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 4770 [25] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 4771 September 1981. 4773 [26] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 4774 October 1994. See also http://www.iana.org/numbers.html. 4776 [27] Susan Thomson and Thomas Narten. IPv6 stateless address 4777 autoconfiguration. RFC 2462, December 1998. 4779 Chair's Address 4781 The Working Group can be contacted via its current chairs: 4783 Phil Roberts 4784 Motorola 4785 1501 West Shure Drive 4786 Arlington Heights, IL 60004 4788 Phone: +1 847 632-3148 4789 E-mail: qa3445@email.mot.com 4791 Basavaraj Patil 4792 Nokia 4793 6000 Connection Drive 4794 M/S M8-540 4795 Irving, TX 75039 4796 USA 4798 Phone: +1 972 894-6709 4799 Fax: +1 972 894-5349 4800 E-mail: raj.patil@nokia.com 4802 Authors' Addresses 4804 Questions about this document can also be directed to the authors: 4806 David B. Johnson 4807 Carnegie Mellon University 4808 Computer Science Department 4809 5000 Forbes Avenue 4810 Pittsburgh, PA 15213-3891 4811 USA 4813 Phone: +1 412 268-7399 4814 Fax: +1 412 268-5576 4815 E-mail: dbj@cs.cmu.edu 4817 Charles Perkins 4818 Nokia 4819 313 Fairchild Drive 4820 Mountain View, CA 94043 4821 USA 4823 Phone: +1 650 625-2986 4824 Fax: +1 650 691-2170 4825 E-mail: charliep@iprg.nokia.com