idnits 2.17.1 draft-ietf-mobileip-ipv6-13.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 exchanging 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 the same Destination Options extension header is completed. Currently, no other such options are defined. -- 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 (17 November 2000) is 8559 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 Rice University 3 Charles Perkins 4 Nokia 5 17 November 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 Types of 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. Handling Reverse Tunneled Packets from a Mobile Node . . 69 114 9.8. Renumbering the Home Subnet . . . . . . . . . . . . . . . 70 115 9.8.1. Building Aggregate List of Home Network Prefixes 70 116 9.8.2. Sending Changed Prefix Information to the Mobile 117 Node . . . . . . . . . . . . . . . . . . . 71 118 9.8.3. Tunneling Router Advertisements to the Mobile Node 73 119 9.8.4. Lifetimes for Changed Prefixes . . . . . . . . . 74 121 10. Mobile Node Operation 75 122 10.1. Sending Packets While Away from Home . . . . . . . . . . 75 123 10.2. Interaction with Outbound IPsec Processing . . . . . . . 76 124 10.3. Receiving Packets While Away from Home . . . . . . . . . 78 125 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 80 126 10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 82 127 10.6. Sending Binding Updates to the Home Agent . . . . . . . . 84 128 10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 86 129 10.8. Sending Binding Updates to Correspondent Nodes . . . . . 87 130 10.9. Establishing Forwarding from a Previous Care-of Address . 89 131 10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 90 132 10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 91 133 10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 91 134 10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 92 135 10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 93 136 10.15. Receiving Local Router Advertisement Messages . . . . . . 94 137 10.16. Sending Tunneled Router Solicitations . . . . . . . . . . 95 138 10.17. Receiving Tunneled Router Advertisements . . . . . . . . 96 139 10.18. Using Multiple Care-of Addresses . . . . . . . . . . . . 97 140 10.19. Routing Multicast Packets . . . . . . . . . . . . . . . . 97 141 10.20. Returning Home . . . . . . . . . . . . . . . . . . . . . 98 143 11. Protocol Constants 100 145 12. IANA Considerations 101 146 13. Security Considerations 102 147 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 102 148 13.2. Security for the Home Address Option . . . . . . . . . . 102 149 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 103 151 Changes from Previous Version of the Draft 104 153 Acknowledgements 105 155 References 106 157 A. Remote Home Address Configuration 108 159 Chair's Address 109 161 Authors' Addresses 110 162 1. Introduction 164 This document specifies the operation of mobile computers using 165 Internet Protocol Version 6 (IPv6) [6]. Without specific support 166 for mobility in IPv6, packets destined to a mobile node (host or 167 router) would not be able to reach it while the mobile node is away 168 from its home link (the link on which its home IPv6 subnet prefix is 169 in use), since routing is based on the subnet prefix in a packet's 170 destination IP address. In order to continue communication in spite 171 of its movement, a mobile node could change its IP address each time 172 it moves to a new link, but the mobile node would then not be able 173 to maintain transport and higher-layer connections when it changes 174 location. Mobility support in IPv6 is particularly important, as 175 mobile computers are likely to account for a majority or at least a 176 substantial fraction of the population of the Internet during the 177 lifetime of IPv6. 179 The protocol operation defined here, known as Mobile IPv6, allows a 180 mobile node to move from one link to another without changing the 181 mobile node's IP address. A mobile node is always addressable by 182 its "home address", an IP address assigned to the mobile node within 183 its home subnet prefix on its home link. Packets may be routed to 184 the mobile node using this address regardless of the mobile node's 185 current point of attachment to the Internet, and the mobile node may 186 continue to communicate with other nodes (stationary or mobile) after 187 moving to a new link. The movement of a mobile node away from its 188 home link is thus transparent to transport and higher-layer protocols 189 and applications. 191 The Mobile IPv6 protocol is just as suitable for mobility across 192 homogeneous media as for mobility across heterogeneous media. For 193 example, Mobile IPv6 facilitates node movement from one Ethernet 194 segment to another as well as it facilitates node movement from an 195 Ethernet segment to a wireless LAN cell, with the mobile node's IP 196 address remaining unchanged in spite of such movement. 198 One can think of the Mobile IPv6 protocol as solving the 199 network-layer mobility management problem. Some mobility management 200 applications -- for example, handoff among wireless transceivers, 201 each of which covers only a very small geographic area -- have been 202 solved using link-layer techniques. For example, in many current 203 wireless LAN products, link-layer mobility mechanisms allow a 204 "handoff" of a mobile node from one cell to another, reestablishing 205 link-layer connectivity to the node in each new location. Within 206 the natural limitations imposed by link-management solutions, and as 207 long as such handoff occurs only within cells of the mobile node's 208 home link, such link-layer mobility mechanisms MAY offer faster 209 convergence and lower overhead than Mobile IPv6. Extensions to the 210 Mobile IPv6 protocol have been proposed to support a more local, 211 hierarchical form of mobility management, but such extensions are 212 beyond the scope of this document. 214 The protocol specified in this document solves the problem of 215 transparently routing packets to and from mobile nodes while away 216 from home. However, it does not attempt to solve all general 217 problems related to the use of mobile computers or wireless networks. 218 In particular, this protocol does not attempt to solve: 220 - Handling links with partial reachability, such as typical 221 wireless networks. Some aspects of this problem are addressed 222 by the movement detection procedure described in Section 10.4, 223 but no attempt has been made to fully solve this problem in its 224 general form. Most aspects of this problem can be solved by the 225 workaround of restricting such networks to only one router per 226 link, although there are still possible hidden terminal problems 227 when two nodes on the same link (on opposite sides of the router) 228 attempt to communicate directly. 230 - Access control on a link being visited by a mobile node. This 231 is a general problem any time an untrusted node is allowed to 232 connect to any link layer. It is independent of whether the 233 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 234 address on the link. 236 2. Comparison with Mobile IP for IPv4 238 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 239 natural combination of the experiences gained from the development 240 of Mobile IP support in IPv4 (Mobile IPv4) [19, 18, 20], together 241 with the opportunities provided by the design and deployment of a new 242 version of IP itself (IPv6) and the new protocol features offered 243 by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, 244 but the protocol is now fully integrated into IP and provides many 245 improvements over Mobile IPv4. This section summarizes the major 246 differences between Mobile IPv4 and Mobile IPv6: 248 - Support for what is known in Mobile IPv4 as "Route 249 Optimization" [21] is now built in as a fundamental part 250 of the protocol, rather than being added on as an optional 251 set of extensions that may not be supported by all nodes 252 as in Mobile IPv4. This integration of Route Optimization 253 functionality allows direct routing from any correspondent 254 node to any mobile node, without needing to pass through 255 the mobile node's home network and be forwarded by its home 256 agent, and thus eliminates the problem of "triangle routing" 257 present in the base Mobile IPv4 protocol [19]. The Mobile IPv4 258 "registration" functionality and the Mobile IPv4 Route 259 Optimization functionality are performed by a single protocol 260 rather than two separate (and different) protocols. 262 - Support is also integrated into Mobile IPv6 -- and into IPv6 263 itself -- for allowing mobile nodes and Mobile IP to coexist 264 efficiently with routers that perform "ingress filtering" [7]. A 265 mobile node now uses its care-of address as the Source Address in 266 the IP header of packets it sends, allowing the packets to pass 267 normally through ingress filtering routers. The home address 268 of the mobile node is carried in the packet in a Home Address 269 destination option, allowing the use of the care-of address in 270 the packet to be transparent above the IP layer. The ability 271 to correctly process a Home Address option in a received packet 272 is required in all IPv6 nodes, whether mobile nor stationary, 273 whether host or router. 275 - The use of the care-of address as the Source Address in each 276 packet's IP header also simplifies routing of multicast packets 277 sent by a mobile node. With Mobile IPv4, the mobile node 278 had to tunnel multicast packets to its home agent in order to 279 transparently use its home address as the source of the multicast 280 packets. With Mobile IPv6, the use of the Home Address option 281 allows the home address to be used but still be compatible with 282 multicast routing that is based in part on the packet's Source 283 Address. 285 - There is no longer any need to deploy special routers as 286 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 287 mobile nodes make use of IPv6 features, such as Neighbor 288 Discovery [17] and Address Autoconfiguration [27], to operate in 289 any location away from home without any special support required 290 from its local router. 292 - Unlike Mobile IPv4, Mobile IPv6 utilizes IP Security 293 (IPsec) [11, 12, 13] for all security requirements (sender 294 authentication, data integrity protection, and replay protection) 295 for Binding Updates (which serve the role of both registration 296 and Route Optimization in Mobile IPv4). Mobile IPv4 relies 297 on its own security mechanisms for these functions, based on 298 statically configured "mobility security associations". 300 - The movement detection mechanism in Mobile IPv6 provides 301 bidirectional confirmation of a mobile node's ability to 302 communicate with its default router in its current location 303 (packets that the router sends are reaching the mobile node, and 304 packets that the mobile node sends are reaching the router). 305 This confirmation provides a detection of the "black hole" 306 situation that may exist in some wireless environments where the 307 link to the router does not work equally well in both directions, 308 such as when the mobile node has moved out of good wireless 309 transmission range from the router. The mobile node may then 310 attempt to find a new router and begin using a new care-of 311 address if its link to its current router is not working well. 312 In contrast, in Mobile IPv4, only the forward direction (packets 313 from the router are reaching the mobile node) is confirmed, 314 allowing the black hole condition to persist. 316 - Most packets sent to a mobile node while away from home in 317 Mobile IPv6 are sent using an IPv6 Routing header rather than IP 318 encapsulation, whereas Mobile IPv4 must use encapsulation for all 319 packets. The use of a Routing header requires less additional 320 header bytes to be added to the packet, reducing the overhead 321 of Mobile IP packet delivery. To avoid modifying the packet in 322 flight, however, packets intercepted and tunneled by a mobile 323 node's home agent in Mobile IPv6 must still use encapsulation for 324 delivery to the mobile node. 326 - While a mobile node is away from home, its home agent intercepts 327 any packets for the mobile node that arrive at the home network, 328 using IPv6 Neighbor Discovery [17] rather than ARP [23] as is 329 used in Mobile IPv4. The use of Neighbor Discovery improves 330 the robustness of the protocol (e.g., due to the Neighbor 331 Advertisement "override" bit) and simplifies implementation 332 of Mobile IP due to the ability to not be concerned with any 333 particular link layer as is required in ARP. 335 - The use of IPv6 encapsulation (and the Routing header) removes 336 the need in Mobile IPv6 to manage "tunnel soft state", which was 337 required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 338 to the definition of ICMP for IPv6, the use of tunnel soft state 339 is no longer required in IPv6 for correctly relaying ICMP error 340 messages from within the tunnel back to the original sender of 341 the packet. 343 - The dynamic home agent address discovery mechanism in Mobile IPv6 344 uses IPv6 anycast [10] and returns a single reply to the mobile 345 node, rather than the corresponding Mobile IPv4 mechanism that 346 used IPv4 directed broadcast and returned a separate reply from 347 each home agent on the mobile node's home link. The Mobile IPv6 348 mechanism is more efficient and more reliable, since only one 349 packet need be sent back to the mobile node. The mobile node is 350 less likely to lose one of the replies because no "implosion" of 351 replies is required by the protocol. 353 - Mobile IPv6 defines an Advertisement Interval option on 354 Router Advertisements (equivalent to Agent Advertisements in 355 Mobile IPv4), allowing a mobile node to decide for itself how 356 many Router Advertisements (Agent Advertisements) it is willing 357 to miss before declaring its current router unreachable. 359 - The use of IPv6 destination options allows all Mobile IPv6 360 control traffic to be piggybacked on any existing IPv6 packets, 361 whereas in Mobile IPv4 and its Route Optimization extensions, 362 separate UDP packets were required for each control message. 364 3. Terminology 366 3.1. General Terms 368 IP 370 Internet Protocol Version 6 (IPv6). 372 node 374 A device that implements IP. 376 router 378 A node that forwards IP packets not explicitly addressed to 379 itself. 381 host 383 Any node that is not a router. 385 link 387 A communication facility or medium over which nodes can 388 communicate at the link layer, such as an Ethernet (simple or 389 bridged). A link is the layer immediately below IP. 391 interface 393 A node's attachment to a link. 395 subnet prefix 397 A bit string that consists of some number of initial bits of an 398 IP address. 400 interface identifier 402 A number used to identify a node's interface on a link. The 403 interface identifier is the remaining low-order bits in the 404 node's IP address after the subnet prefix. 406 link-layer address 408 A link-layer identifier for an interface, such as IEEE 802 409 addresses on Ethernet links. 411 packet 413 An IP header plus payload. 415 3.2. Mobile IPv6 Terms 417 home address 419 An IP address assigned to a mobile node within its home link. 421 home subnet prefix 423 The IP subnet prefix corresponding to a mobile node's home 424 address. 426 home link 428 The link on which a mobile node's home subnet prefix is 429 defined. Standard IP routing mechanisms will deliver packets 430 destined for a mobile node's home address to its home link. 432 mobile node 434 A node that can change its point of attachment from one link to 435 another, while still being reachable via its home address. 437 movement 439 A change in a mobile node's point of attachment to the Internet 440 such that it is no longer connected to the same link as it was 441 previously. If a mobile node is not currently attached to its 442 home link, the mobile node is said to be "away from home". 444 correspondent node 446 A peer node with which a mobile node is communicating. The 447 correspondent node may be either mobile or stationary. 449 foreign subnet prefix 451 Any IP subnet prefix other than the mobile node's home subnet 452 prefix. 454 foreign link 456 Any link other than the mobile node's home link. 458 home agent 460 A router on a mobile node's home link with which the mobile 461 node has registered its current care-of address. While the 462 mobile node is away from home, the home agent intercepts 463 packets on the home link destined to the mobile node's home 464 address, encapsulates them, and tunnels them to the mobile 465 node's registered care-of address. 467 care-of address 469 An IP address associated with a mobile node while visiting a 470 foreign link; the subnet prefix of this IP address is a foreign 471 subnet prefix. Among the multiple care-of addresses that a 472 mobile node may have at a time (e.g., with different subnet 473 prefixes), the one registered with the mobile node's home agent 474 is called its "primary" care-of address. 476 binding 478 The association of the home address of a mobile node with a 479 care-of address for that mobile node, along with the remaining 480 lifetime of that association. 482 3.3. Specification Language 484 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 485 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 486 document are to be interpreted as described in RFC 2119 [3]. 488 4. Overview of Mobile IPv6 490 4.1. Basic Operation 492 A mobile node is always addressable by its home address, whether it 493 is currently attached to its home link or is away from home. While 494 a mobile node is at home, packets addressed to its home address are 495 routed to it using conventional Internet routing mechanisms in the 496 same way as if the node were never mobile. Since the subnet prefix 497 of a mobile node's home address is the subnet prefix (or one of the 498 subnet prefixes) on the mobile node's home link (it is the mobile 499 node's home subnet prefix), packets addressed to it will be routed to 500 its home link. 502 While a mobile node is attached to some foreign link away from home, 503 it is also addressable by one or more care-of addresses, in addition 504 to its home address. A care-of address is an IP address associated 505 with a mobile node while visiting a particular foreign link. The 506 subnet prefix of a mobile node's care-of address is the subnet prefix 507 (or one of the subnet prefixes) on the foreign link being visited by 508 the mobile node; if the mobile node is connected to this foreign link 509 while using that care-of address, packets addressed to this care-of 510 address will be routed to the mobile node in its location away from 511 home. 513 The association between a mobile node's home address and care-of 514 address is known as a "binding" for the mobile node. A mobile node 515 typically acquires its care-of address through stateless [27] or 516 stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according 517 to the methods of IPv6 Neighbor Discovery [17]. Other methods 518 of acquiring a care-of address are also possible, such as static 519 pre-assignment by the owner or manager of a particular foreign link, 520 but details of such other methods are beyond the scope of this 521 document. 523 While away from home, a mobile node registers one of its care-of 524 addresses with a router on its home link, requesting this router 525 to function as the "home agent" for the mobile node. This binding 526 registration is done by the mobile node sending to the home agent 527 a packet containing a "Binding Update" destination option; the 528 home agent then replies to the mobile node by returning a packet 529 containing a "Binding Acknowledgement" destination option. The 530 care-of address in this binding registered with its home agent is 531 known as the mobile node's "primary care-of address". The mobile 532 node's home agent thereafter uses proxy Neighbor Discovery to 533 intercept any IPv6 packets addressed to the mobile node's home 534 address (or home addresses) on the home link, and tunnels each 535 intercepted packet to the mobile node's primary care-of address. 536 To tunnel each intercepted packet, the home agent encapsulates the 537 packet using IPv6 encapsulation [4], with the outer IPv6 header 538 addressed to the mobile node's primary care-of address. 540 When a mobile node moves from one care-of address to a new care-of 541 address on a new link, it is desirable for packets arriving at the 542 previous care-of address to be tunneled to the mobile node's care-of 543 address. Since the purpose of a Binding Update is to establish 544 exactly this kind of tunneling, it is specified to be used (at 545 least temporarily) for tunnels originating at the mobile node's 546 previous care-of address, in exactly the same way that it is used 547 for establishing tunnels from the mobile node's home address to the 548 mobile node's current care-of address. Section 10.9 describes the 549 use of the Binding Update for this purpose. 551 Section 10.18 discusses the reasons why it may be desirable for 552 a mobile node to use more than one care-of address at the same 553 time. However, a mobile node's primary care-of address is distinct 554 among these in that the home agent maintains only a single care-of 555 address registered for each mobile node, and always tunnels a mobile 556 node's packets intercepted from its home link to this mobile node's 557 registered primary care-of address. The home agent thus need not 558 implement any policy to determine which of possibly many care-of 559 addresses to which to tunnel each intercepted packet. The mobile 560 node alone controls the policy by which it selects the care-of 561 addresses to register with its home agent. 563 It is possible that while a mobile node is away from home, some nodes 564 on its home link may be reconfigured, such that the router that was 565 operating as the mobile node's home agent is replaced by a different 566 router serving this role. In this case, the mobile node may not 567 know the IP address of its own home agent. Mobile IPv6 provides a 568 mechanism, known as "dynamic home agent address discovery", that 569 allows a mobile node to dynamically discover the IP address of a home 570 agent on its home link with which it may register its care-of address 571 while away from home. The mobile node sends an ICMP "Home Agent 572 Address Discovery Request" message to the "Mobile IPv6 Home-Agents" 573 anycast address for its own home subnet prefix [10] and thus reaches 574 one of the (possibly many) routers on its home link currently 575 operating as a home agent. This home agent then returns an ICMP 576 "Home Agent Address Discovery Reply" message to the mobile node, 577 including a list of home agents on the home link. This list of home 578 agents is maintained by each home agent on the home link through use 579 of the Home Agent (H) bit in each home agent's periodic unsolicited 580 multicast Router Advertisements. 582 The Binding Update and Binding Acknowledgement destination options, 583 together with a "Binding Request" destination option, are also used 584 to allow IPv6 nodes communicating with a mobile node, to dynamically 585 learn and cache the mobile node's binding. When sending a packet 586 to any IPv6 destination, a node checks its cached bindings for an 587 entry for the packet's destination address. If a cached binding for 588 this destination address is found, the node uses an IPv6 Routing 589 header [6] (instead of IPv6 encapsulation) to route the packet to 590 the mobile node by way of the care-of address indicated in this 591 binding. If, instead, the sending node has no cached binding for 592 this destination address, the node sends the packet normally (with 593 no Routing header), and the packet is subsequently intercepted and 594 tunneled by the mobile node's home agent as described above. Any 595 node communicating with a mobile node is referred to in this document 596 as a "correspondent node" of the mobile node, and may itself be 597 either a stationary node or a mobile node. 599 Since a Binding Update, Binding Acknowledgement, and Binding Request 600 are each represented in a packet as an IPv6 destination option [6], 601 they may be included in any IPv6 packet. Any of these options can be 602 sent in either of two ways: 604 - the messages can be included within any IPv6 packet carrying any 605 payload such as TCP [25] or UDP [24]. 607 - the messages can be sent as a separate IPv6 packet containing 608 no payload. In this case, the Next Header field in the last 609 extension header in the packet is set to the value 59, to 610 indicate "No Next Header" [6]. 612 Mobile IPv6 also defines one additional IPv6 destination option. 613 When a mobile node sends a packet while away from home, it will 614 generally set the Source Address in the packet's IPv6 header to one 615 of its current care-of addresses, and will also include a "Home 616 Address" destination option in the packet, giving the mobile node's 617 home address. Many routers implement security policies such as 618 "ingress filtering" [7] that do not allow forwarding of packets 619 that have a Source Address which appears topologically incorrect. 620 By using the care-of address as the IPv6 header Source Address, 621 the packet will be able to pass normally through such routers, 622 yet ingress filtering rules will still be able to locate the true 623 topological source of the packet in the same way as packets from 624 non-mobile nodes. By also including the Home Address option in each 625 packet, the sending mobile node can communicate its home address to 626 the correspondent node receiving this packet, allowing the use of 627 the care-of address to be transparent above the Mobile IPv6 support 628 level (e.g., at the transport layer). The inclusion of a Home 629 Address option in a packet affects only the correspondent node's 630 receipt of this single packet; no state is created or modified in the 631 correspondent node as a result of receiving a Home Address option in 632 a packet. 634 4.2. New IPv6 Destination Options 636 As mentioned in Section 4.1, the following four new IPv6 destination 637 options are defined for Mobile IPv6: 639 Binding Update 641 A Binding Update option is used by a mobile node to notify 642 a correspondent node or the mobile node's home agent of its 643 current binding. The Binding Update sent to the mobile node's 644 home agent to register its primary care-of address is marked 645 as a "home registration". Any packet that includes a Binding 646 Update option MUST be protected by IPsec [13], as defined in 647 Section 4.4, to guard against malicious Binding Updates. The 648 Binding Update option and its specific IPsec requirements are 649 described in detail in Section 5.1. 651 Binding Acknowledgement 653 A Binding Acknowledgement option is used to acknowledge receipt 654 of a Binding Update, if an acknowledgement was requested 655 in the Binding Update. Any packet that includes a Binding 656 Acknowledgement option MUST be protected by IPsec [13], as 657 defined in Section 4.4, to guard against malicious Binding 658 Acknowledgements. The Binding Acknowledgement option and 659 its specific IPsec requirements are described in detail in 660 Section 5.2. 662 Binding Request 664 A Binding Request option is used to request a mobile node to 665 send to the requesting node a Binding Update containing the 666 mobile node's current binding. This option is typically used 667 by a correspondent node to refresh a cached binding for a 668 mobile node, when the cached binding is in active use but the 669 binding's lifetime is close to expiration. No authentication 670 is required for the Binding Request option. The Binding 671 Request option is described in detail in Section 5.3. 673 Home Address 675 A Home Address option is used in a packet sent by a mobile 676 node to inform the recipient of that packet of the mobile 677 node's home address. For packets sent by a mobile node while 678 away from home, the mobile node generally uses one of its 679 care-of addresses as the Source Address in the packet's IPv6 680 header. By including a Home Address option in the packet, the 681 correspondent node receiving the packet is able to substitute 682 the mobile node's home address for this care-of address when 683 processing the packet, thus making the use of the care-of 684 address transparent to the correspondent node. If the IP 685 header of a packet carrying a Home Address option is covered 686 by authentication, then the Home Address option MUST also be 687 covered by this authentication, but no other authentication 688 is required for the Home Address option. See sections 10.2 689 and 5.4 for additional details about requirements for the 690 calculation and verification of the authentication data. The 691 Home Address option is described in detail in Section 5.4. 693 Mobile IPv6 also defines a number of "sub-options" for use within 694 these destination options; if included, any sub-options MUST 695 appear after the fixed portion of the option data specified in this 696 document. The presence of such sub-options will be indicated by the 697 Option Length field within the option. When the Option Length is 698 greater than the length required for the option specified here, the 699 remaining octets are interpreted as sub-options. The encoding and 700 format of defined sub-options are described in Section 5.5. 702 4.3. Alignment Requirements for New Destination Options 704 IPv6 requires that options appearing in a Hop-by-Hop Options 705 header or Destination Options header be aligned in a packet so that 706 multi-octet values within the Option Data field of each option fall 707 on natural boundaries (i.e., fields of width n octets are placed 708 at an integer multiple of n octets from the start of the header, 709 for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar 710 alignment requirements, so that multi-octet values within the 711 Sub-Option Data field of each sub-option fall on natural boundaries. 712 The alignment requirement of an option or sub-option is specified in 713 this document using the standard notation used elsewhere for IPv6 714 alignment requirements [6]. Specifically, the notation xn+y means 715 that the Option Type or Sub-Option Type field must fall at an integer 716 multiple of x octets from the start of the header, plus y octets. 717 For example: 719 2n means any 2-octet offset from the start of the header. 721 8n+2 means any 8-octet offset from the start of the header, 722 plus 2 octets. 724 4.4. IPsec Requirements for New Destination Options 726 Any packet that includes a Binding Update or Binding Acknowledgement 727 option MUST be protected by IPsec [13] to guard against malicious 728 Binding Updates or Acknowledgements. Specifically, any packet that 729 includes a Binding Update or Binding Acknowledgement option MUST 730 utilize IPsec sender authentication, data integrity protection, and 731 replay protection. 733 Mobile IPv6 requires that this protection covering a Binding Update 734 or Binding Acknowledgement MUST be provided by use of AH [11]. If 735 another Security Association applied to the packet for other reasons 736 requires use of ESP [12], for example to encrypt the transport layer 737 data carried in the packet, this use of ESP is not sufficient to 738 satisfy the authentication requirements of Mobile IPv6; instead, 739 the packet MUST use both AH and ESP. Use of ESP for protecting the 740 Binding Update or Binding Acknowledgement is not currently defined in 741 this document, since ESP does not protect the portion of the packet 742 above the ESP header itself [12]. 744 4.5. New IPv6 ICMP Messages 746 Mobile IPv6 also introduces two new ICMP message types, for use in 747 the dynamic home agent address discovery mechanism. As discussed in 748 general in Section 4.1, the following two new ICMP message types are 749 used: 751 Home Agent Address Discovery Request 753 The ICMP Home Agent Address Discovery Request message is used 754 by a mobile node to initiate the dynamic home agent address 755 discovery mechanism. When attempting a home registration, the 756 mobile node may use this mechanism to discover the address of 757 one or more routers currently operating as home agents on its 758 home link, with which it may register while away from home. 759 The Home Agent Address Discovery Request message is described 760 in detail in Section 5.6. 762 Home Agent Address Discovery Reply 764 The ICMP Home Agent Address Discovery Reply message is used by 765 a home agent to respond to a mobile node using the dynamic home 766 agent address discovery mechanism. When a home agent receives 767 a Home Agent Address Discovery Request message, it replies with 768 a Home Agent Address Discovery Reply message, giving a list 769 of the routers on the mobile node's home link serving as home 770 agents. The Home Agent Address Discovery Reply message is 771 described in detail in Section 5.7. 773 4.6. Conceptual Data Structures 775 This document describes the Mobile IPv6 protocol in terms of the 776 following three conceptual data structures: 778 Binding Cache 780 A cache, maintained by each IPv6 node, of bindings for other 781 nodes. A separate Binding Cache SHOULD be maintained by each 782 IPv6 node for each of its IPv6 addresses. The Binding Cache 783 MAY be implemented in any manner consistent with the external 784 behavior described in this document, for example by being 785 combined with the node's Destination Cache as maintained by 786 Neighbor Discovery [17]. When sending a packet, the Binding 787 Cache is searched before the Neighbor Discovery conceptual 788 Destination Cache [17] (i.e., any Binding Cache entry for this 789 destination SHOULD take precedence over any Destination Cache 790 entry for the same destination). Each Binding Cache entry 791 conceptually contains the following fields: 793 - The home address of the mobile node for which this is the 794 Binding Cache entry. This field is used as the key for 795 searching the Binding Cache for the destination address of 796 a packet being sent. If the destination address of the 797 packet matches the home address in the Binding Cache entry, 798 this entry SHOULD be used in routing that packet. 800 - The care-of address for the mobile node indicated by 801 the home address field in this Binding Cache entry. If 802 the destination address of a packet being routed by a 803 node matches the home address in this entry, the packet 804 SHOULD be routed to this care-of address, as described in 805 Section 8.9, for packets originated by this node, or in 806 Section 9.6, if this node is the mobile node's home agent 807 and the packet was intercepted by it on the home link. 809 - A lifetime value, indicating the remaining lifetime 810 for this Binding Cache entry. The lifetime value is 811 initialized from the Lifetime field in the Binding Update 812 that created or last modified this Binding Cache entry. 813 Once the lifetime on this entry expires, the entry MUST be 814 deleted from the Binding Cache. 816 - A flag indicating whether or not this Binding Cache entry 817 is a "home registration" entry. 819 - A flag indicating whether or not this Binding Cache entry 820 represents a mobile node that should be advertised as a 821 router in proxy Neighbor Advertisements sent by this node 822 on its behalf. This flag is only valid if the Binding 823 Cache entry indicates that this is a "home registration" 824 entry. 826 - The value of the Prefix Length field received in the 827 Binding Update that created or last modified this Binding 828 Cache entry. This field is only valid if the "home 829 registration" flag is set on this Binding Cache entry. 831 - The maximum value of the Sequence Number field received 832 in previous Binding Updates for this mobile node home 833 address. The Sequence Number field is 16 bits long, 834 and all comparisons between Sequence Number values 835 MUST be performed modulo 2**16. For example, using an 836 implementation in the C programming language, a Sequence 837 Number value A is greater than another Sequence Number 838 value B if ((short)((a) - (b)) > 0), if a "short" data type 839 is a 16-bit signed integer. 841 - Recent usage information for this Binding Cache entry, as 842 needed to implement the cache replacement policy in use in 843 the Binding Cache and to assist in determining whether a 844 Binding Request should be sent when the lifetime on this 845 entry nears expiration. 847 - The time at which a Binding Request was last sent for this 848 entry, as needed to implement the rate limiting restriction 849 for sending Binding Requests. 851 An entry in a node's Binding Cache for which the node is 852 serving as a home agent is marked as a "home registration" 853 entry and SHOULD NOT be deleted by the home agent until the 854 expiration of its binding lifetime. Other Binding Cache 855 entries MAY be replaced at any time by any reasonable local 856 cache replacement policy but SHOULD NOT be unnecessarily 857 deleted. The Binding Cache for any one of a node's IPv6 858 addresses may contain at most one entry for each mobile node 859 home address. The contents of a node's Binding Cache MUST NOT 860 be changed in response to a Home Address option in a received 861 packet. The contents of all of a node's Binding Cache entries, 862 for each of its IPv6 addresses, must be cleared when the node 863 reboots. 865 Binding Update List 867 A list, maintained by each mobile node, recording information 868 for each Binding Update sent by this mobile node, for which the 869 Lifetime sent in that Binding Update has not yet expired. The 870 Binding Update List includes all bindings sent by the mobile 871 node: those to correspondent nodes, those to the mobile node's 872 home agent, and those to a home agent on the link on which the 873 mobile node's previous care-of address is located. However, 874 for multiple Binding Updates sent to the same destination 875 address, the Binding Update List contains only the most recent 876 Binding Update (i.e., with the greatest Sequence Number value) 877 sent to that destination. The Binding Update List MAY be 878 implemented in any manner consistent with the external behavior 879 described in this document. Each Binding Update List entry 880 conceptually contains the following fields: 882 - The IP address of the node to which a Binding Update was 883 sent. This node might still have a Binding Cache entry 884 created or updated from this Binding Update, if the Binding 885 Update was successfully received by that node (e.g., not 886 lost by the network) and if that node has not deleted the 887 entry before its expiration (e.g., to reclaim space in its 888 Binding Cache for other entries). 890 - The home address for which that Binding Update was sent. 891 This will be one of the following: 893 * the mobile node's home addresses for typical Binding 894 Updates (Sections 10.6 and 10.8), or 896 * the mobile node's previous care-of address for Binding 897 Updates sent to establish forwarding from the mobile 898 node's previous care-of address by a home agent from 899 this previous care-of address (Section 10.9). 901 - The care-of address sent in that Binding Update. This 902 value is necessary for the mobile node to determine if it 903 has sent a Binding Update giving its new care-of address to 904 this destination after changing its care-of address. 906 - The initial value of the Lifetime field sent in that 907 Binding Update. 909 - The remaining lifetime of that binding. This lifetime is 910 initialized from the Lifetime value sent in the Binding 911 Update and is decremented until it reaches zero, at which 912 time this entry MUST be deleted from the Binding Update 913 List. 915 - The maximum value of the Sequence Number field sent in 916 previous Binding Updates to this destination. The Sequence 917 Number field is 16 bits long, and all comparisons between 918 Sequence Number values MUST be performed modulo 2**16. 919 For example, using an implementation in the C programming 920 language, a Sequence Number value A is greater than another 921 Sequence Number value B if ((short)((a) - (b)) > 0), if a 922 "short" data type is a 16-bit signed integer. 924 - The time at which a Binding Update was last sent to this 925 destination, as needed to implement the rate limiting 926 restriction for sending Binding Updates. 928 - The state of any retransmissions needed for this Binding 929 Update, if the Acknowledge (A) bit was set in this Binding 930 Update. This state includes the time remaining until the 931 next retransmission attempt for the Binding Update, and the 932 current state of the exponential back-off mechanism for 933 retransmissions. 935 - A flag that, when set, indicates that future Binding 936 Updates should not be sent to this destination. The 937 mobile node sets this flag in the Binding Update List 938 entry when it receives an ICMP Parameter Problem, Code 2, 939 error message in response to a Binding Update sent to that 940 destination, as described in Section 10.14. 942 Home Agents List 944 A list, maintained by each home agent and each mobile node, 945 recording information about each home agent from which this 946 node has received a Router Advertisement in which the Home 947 Agent (H) bit is set, for which the remaining lifetime for 948 this list entry (defined below) has not yet expired. The 949 home agents list is thus similar to the Default Router 950 List conceptual data structure maintained by each host for 951 Neighbor Discovery [17], although the Home Agents List MAY be 952 implemented in any manner consistent with the external behavior 953 described in this document. 955 Each home agent maintains a separate Home Agents List for 956 each link on which it is serving as a home agent; this list 957 is used by a home agent in the dynamic home agent address 958 discovery mechanism. Each mobile node, while away from home, 959 also maintains a Home Agents List, to enable it to notify a 960 home agent on its previous link when it moves to a new link; a 961 mobile node MAY maintain a separate Home Agents List for each 962 link to which it is (or has recently) connected, or it MAY 963 maintain a single list for all links. Each Home Agents List 964 entry conceptually contains the following fields: 966 - The link-local IP address of a router on the link, that 967 this node currently believes is operating as a home agent 968 for that link. A new entry is created or an existing 969 entry is updated in the Home Agents List in response to 970 receipt of a valid Router Advertisement in which the Home 971 Agent (H) bit is set. The link-local address of the home 972 agent is learned through the Source Address of the Router 973 Advertisements received from it [17]. 975 - One or more global IP addresses for this home agent, 976 learned through Prefix Information options with 977 the Router Address (R) bit set, received in Router 978 Advertisements from this link-local address. Global 979 addresses for the router in a Home Agents List entry MUST 980 be deleted once the prefix associated with that address is 981 no longer valid [17]. 983 - The remaining lifetime of this Home Agents List entry. If 984 a Home Agent Information Option is present in a Router 985 Advertisement received from a home agent, the lifetime of 986 the Home Agents List entry representing that home agent 987 is initialized from the Home Agent Lifetime field in the 988 option; otherwise, the lifetime is initialized from the 989 Router Lifetime field in the received Router Advertisement. 990 The Home Agents List entry lifetime is decremented until it 991 reaches zero, at which time this entry MUST be deleted from 992 the Home Agents List. 994 - The preference for this home agent; higher values 995 indicate a more preferable home agent. The preference 996 value is taken from the Home Agent Preference field (a 997 signed, twos-complement integer) in the received Router 998 Advertisement, if the Router Advertisement contains a Home 999 Agent Information Option, and is otherwise set to the 1000 default value of 0. A home agent uses this preference in 1001 ordering the Home Agents List returned in an ICMP Home 1002 Agent Address Discovery message in response to a mobile 1003 node's initiation of dynamic home agent address discovery. 1004 A mobile node uses this preference in determining which 1005 of the home agents on its previous link to notify when it 1006 moves to a new link. 1008 4.7. Binding Management 1010 When a mobile node configures a new care-of address and decides to 1011 use this new address as its primary care-of address, the mobile 1012 node registers this new binding with its home agent by sending 1013 the home agent a Binding Update. The mobile node indicates 1014 that an acknowledgement is needed for this Binding Update and 1015 continues to periodically retransmit it until acknowledged. The 1016 home agent acknowledges the Binding Update by returning a Binding 1017 Acknowledgement to the mobile node. 1019 When a mobile node receives a packet tunneled to it from its 1020 home agent, the mobile node assumes that the original sending 1021 correspondent node has no Binding Cache entry for the mobile node, 1022 since the correspondent node would otherwise have sent the packet 1023 directly to the mobile node using a Routing header. The mobile node 1024 thus returns a Binding Update to the correspondent node, allowing 1025 it to cache the mobile node's binding for routing future packets to 1026 it. Although the mobile node may request an acknowledgement for 1027 this Binding Update, it need not, since subsequent packets from the 1028 correspondent node will continue to be intercepted and tunneled by 1029 the mobile node's home agent, effectively causing any needed Binding 1030 Update retransmission. 1032 A correspondent node with a Binding Cache entry for a mobile node 1033 may refresh this binding, for example if the binding's lifetime 1034 is near expiration, by sending a Binding Request to the mobile 1035 node. Normally, a correspondent node will only refresh a Binding 1036 Cache entry in this way if it is actively communicating with the 1037 mobile node and has indications, such as an open TCP connection to 1038 the mobile node, that it will continue this communication in the 1039 future. When a mobile node receives a Binding Request, it replies by 1040 returning a Binding Update to the node sending the Binding Request. 1042 A mobile node may use more than one care-of address at the same 1043 time, although only one care-of address may be registered for it at 1044 its home agent as its primary care-of address. The mobile node's 1045 home agent will tunnel all intercepted packets for the mobile node 1046 to its (single) registered primary care-of address, but the mobile 1047 node will accept packets that it receives at any of its current 1048 care-of addresses. Use of more than one care-of address by a mobile 1049 node may be useful, for example, to improve smooth handoff when the 1050 mobile node moves from one wireless link to another. If each of 1051 these wireless links is connected to the Internet through a separate 1052 base station, such that the wireless transmission range from the 1053 two base stations overlap, the mobile node may be able to remain 1054 connected to both links while in the area of overlap. In this case, 1055 the mobile node could acquire a new care-of address on the new link 1056 before moving out of transmission range and disconnecting from the 1057 old link. The mobile node may thus still accept packets at its 1058 old care-of address while it works to update its home agent and 1059 correspondent nodes, notifying them of its new care-of address on the 1060 new link. 1062 Since correspondent nodes cache bindings, it is expected that 1063 correspondent nodes usually will route packets directly to the mobile 1064 node's care-of address, so that the home agent is rarely involved 1065 with packet transmission to the mobile node. This is essential for 1066 scalability and reliability, and for minimizing overall network load. 1067 By caching the care-of address of a mobile node, optimal routing of 1068 packets can be achieved from the correspondent node to the mobile 1069 node. Routing packets directly to the mobile node's care-of address 1070 also eliminates congestion at the mobile node's home agent and home 1071 link. In addition, the impact of any possible failure of the home 1072 agent, the home link, or intervening networks leading to or from the 1073 home link is reduced, since these nodes and links are not involved in 1074 the delivery of most packets to the mobile node. 1076 5. New IPv6 Destination Options and Message Types 1078 5.1. Binding Update Option 1080 The Binding Update destination option is used by a mobile node 1081 to notify other nodes of a new care-of address for itself. As a 1082 destination option, it MAY be included in any existing packet being 1083 sent to this same destination or MAY be sent in a packet by itself; 1084 a packet containing a Binding Update is sent in the same way as any 1085 packet sent by a mobile node (Section 10.1). 1087 The Binding Update option is encoded in type-length-value (TLV) 1088 format as follows: 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Option Type | Option Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 |A|H|R|D|Reservd| Prefix Length | Sequence Number | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Lifetime | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Sub-Options... 1100 +-+-+-+-+-+-+-+-+-+-+-+- 1102 Option Type 1104 198 = 0xC6 1106 Option Length 1108 8-bit unsigned integer. Length of the option, in octets, 1109 excluding the Option Type and Option Length fields. This field 1110 MUST be set to 8 plus the total length of all sub-options 1111 present, including their Sub-Option Type and Sub-Option Len 1112 fields. 1114 Acknowledge (A) 1116 The Acknowledge (A) bit is set by the sending mobile node to 1117 request a Binding Acknowledgement (Section 5.2) be returned 1118 upon receipt of the Binding Update. 1120 Home Registration (H) 1122 The Home Registration (H) bit is set by the sending mobile node 1123 to request the receiving node to act as this node's home agent. 1124 The destination of the packet carrying this option MUST be that 1125 of a router sharing the same subnet prefix as the home address 1126 of the mobile node in the binding (given by the Home Address 1127 field in the Home Address option in the packet). 1129 Router (R) 1131 The Router (R) bit, when set, indicates that the sending 1132 mobile node is a router. This bit is only valid when the 1133 Home Registration (H) bit is also set, and MUST NOT be set 1134 otherwise. This bit is saved in the home agent's "home 1135 registration" Binding Cache entry for the mobile node, and 1136 is copied into the corresponding bit in all proxy Neighbor 1137 Advertisement messages sent on behalf of this mobile node by 1138 the home agent using this Binding Cache entry. 1140 Duplicate Address Detection (D) 1142 The Duplicate Address Detection (D) bit is set by the sending 1143 mobile node to request the receiving node (the mobile node's 1144 home agent) to perform Duplicate Address Detection [27] on 1145 the mobile node's home link for the home address in this 1146 binding. This bit is only valid when the Home Registration (H) 1147 and Acknowledge (A) bits are also set, and MUST NOT be set 1148 otherwise. If the Duplicate Address Detection performed by 1149 the home agent fails, the Status field in the returned Binding 1150 Acknowledgement will be set to 138 (Duplicate Address Detection 1151 failed). 1153 Reservd 1155 This field is unused. It MUST be initialized to zero by the 1156 sender and MUST be ignored by the receiver. 1158 Prefix Length 1160 The Prefix Length field is valid only for a "home registration" 1161 Binding Update; this field MUST be zero if the Home 1162 Registration (H) bit is not set in the Binding Update. The 1163 Prefix Length field is set by the sending mobile node to the 1164 (nonzero) length of its subnet prefix in its home address 1165 (given in the Home Address option in the packet) to request 1166 its home agent to use the interface identifier in the mobile 1167 node's home address (the remaining low-order bits after the 1168 indicated subnet prefix) to form all other home addresses for 1169 the mobile node on the home link. The home agent becomes the 1170 home agent not only for the individual home address given in 1171 this binding, but also for all other home addresses for this 1172 mobile node formed from this interface identifier. That is, 1173 for each on-link prefix on the home link, the home agent uses 1174 the interface identifier to form other valid addresses for 1175 the mobile node on the home link, and acts as a home agent 1176 also for those addresses. In addition, the home agent forms 1177 the link-local address and site-local address corresponding 1178 to this interface identifier, and defends each for purposes 1179 of Duplicate Address Detection. The home agent also performs 1180 Duplicate Address Detection on at least one such address as 1181 part of the home registration processing (before returning 1182 the Binding Acknowledgement), if the Duplicate Address 1183 Detection (D) bit is set in the Binding Update; it is not 1184 necessary to perform Duplicate Address Detection individually 1185 on each of these addresses, since address uniqueness here is 1186 determined solely by the interface identifier [27]. Details of 1187 this operation are described in Section 9.3. 1189 Sequence Number 1191 Used by the receiving node to sequence Binding Updates and by 1192 the sending node to match a returned Binding Acknowledgement 1193 with this Binding Update. Each Binding Update sent by a mobile 1194 node MUST use a Sequence Number greater than the Sequence 1195 Number value sent in the previous Binding Update (if any) to 1196 the same destination address (modulo 2**16, as defined in 1197 Section 4.6). There is no requirement, however, that the 1198 Sequence Number value strictly increase by 1 with each new 1199 Binding Update sent or received. 1201 Lifetime 1203 32-bit unsigned integer. The number of seconds remaining 1204 before the binding MUST be considered expired. A value of all 1205 one bits (0xffffffff) indicates infinity. A value is zero 1206 indicates that the Binding Cache entry for the mobile node MUST 1207 be deleted. 1209 Sub-Options 1211 Additional information, associated with this Binding Update 1212 option, that need not be present in all Binding Updates sent. 1213 This use of sub-options also allows for future extensions to 1214 the format of the Binding Update option to be defined. The 1215 encoding and format of defined sub-options are described in 1216 Section 5.5. The following sub-options are valid in a Binding 1217 Update option: 1219 - Unique Identifier Sub-Option 1221 - Alternate Care-of Address Sub-Option 1223 The alignment requirement [6] for the Binding Update option is 4n+2. 1225 Any packet that includes a Binding Update option MUST also include 1226 a Home Address option. The home address of the mobile node in the 1227 binding given in the Binding Update option is that which was received 1228 as the value of the Home Address field in the Home Address option in 1229 the packet. 1231 The care-of address for the binding given in the Binding Update 1232 option is normally that which was received as the value in the Source 1233 Address field in the IPv6 header of the packet carrying the Binding 1234 Update option. However, a care-of address different from the Source 1235 Address MAY be specified by including an Alternate Care-of Address 1236 sub-option in the Binding Update option. 1238 Any packet that includes a Binding Update option MUST be protected by 1239 IPsec [13] to guard against malicious Binding Updates. The specific 1240 requirements for this protection are defined in Section 4.4. 1242 If the care-of address for the binding (specified either in an 1243 Alternate Care-of Address sub-option in the Binding Update option, if 1244 present, or in the Source Address field in the packet's IPv6 header) 1245 is equal to the home address of the mobile node, the Binding Update 1246 option indicates that any existing binding for the mobile node MUST 1247 be deleted. Likewise, if the Lifetime field in the Binding Update 1248 option is equal to 0, the Binding Update option indicates that any 1249 existing binding for the mobile node MUST be deleted. In each of 1250 these cases, a Binding Cache entry for the mobile node MUST NOT be 1251 created in response to receiving the Binding Update. 1253 The last Sequence Number value sent to a destination in a Binding 1254 Update is stored by the mobile node in its Binding Update List entry 1255 for that destination; the last Sequence Number value received from 1256 a mobile node in a Binding Update is stored by a correspondent node 1257 in its Binding Cache entry for that mobile node. Thus, the mobile 1258 node's and the correspondent node's knowledge of the last sequence 1259 number expire at the same time. If the sending mobile node has no 1260 Binding Update List entry, the Sequence Number may start at any 1261 value; if the receiving correspondent node has no Binding Cache entry 1262 for the sending mobile node, it MUST accept any Sequence Number value 1263 in a received Binding Update from this mobile node. 1265 The three highest-order bits of the Option Type are encoded to 1266 indicate specific processing of the option [6]. For the Binding 1267 Update option, these three bits are set to 110, indicating that any 1268 IPv6 node processing this option that does not recognize the Option 1269 Type must discard the packet and, only if the packet's Destination 1270 Address was not a multicast address, return an ICMP Parameter 1271 Problem, Code 2, message to the packet's Source Address; and that the 1272 data within the option cannot change en-route to the packet's final 1273 destination. 1275 5.2. Binding Acknowledgement Option 1277 The Binding Acknowledgement destination option is used to acknowledge 1278 receipt of a Binding Update option (Section 5.1). When a node 1279 receives a packet containing a Binding Update option, with this 1280 node being the destination of the packet (only the destination node 1281 processes the option since it is a destination option), this node 1282 MUST return a Binding Acknowledgement to the source of the packet, 1283 if the Acknowledge (A) bit is set in the Binding Update. As a 1284 destination option, this node MAY include the Binding Acknowledgement 1285 in any existing packet being sent to the mobile node or MAY send it 1286 in a packet by itself. A packet containing a Binding Acknowledgement 1287 is sent in the same way as any packet to a mobile node, using a 1288 Routing header to route the packet to the mobile node by way of the 1289 care-of address in the binding (Section 8.9). 1291 The Binding Acknowledgement option is encoded in type-length-value 1292 (TLV) format as follows: 1294 0 1 2 3 1295 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 1296 +-+-+-+-+-+-+-+-+ 1297 | Option Type | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Option Length | Status | Sequence Number | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Lifetime | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Refresh | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Sub-Options... 1306 +-+-+-+-+-+-+-+-+-+-+-+- 1308 Option Type 1310 7 1312 Option Length 1314 8-bit unsigned integer. Length of the option, in octets, 1315 excluding the Option Type and Option Length fields. This field 1316 MUST be set to 11 plus the total length of all sub-options 1317 present, including their Sub-Option Type and Sub-Option Len 1318 fields. 1320 Status 1322 8-bit unsigned integer indicating the disposition of the 1323 Binding Update. Values of the Status field less than 128 1324 indicate that the Binding Update was accepted by the receiving 1325 node. The following such Status values are currently defined: 1327 0 Binding Update accepted 1329 Values of the Status field greater than or equal to 128 1330 indicate that the Binding Update was rejected by the receiving 1331 node. The following such Status values are currently defined: 1333 128 Reason unspecified 1334 130 Administratively prohibited 1335 131 Insufficient resources 1336 132 Home registration not supported 1337 133 Not home subnet 1338 136 Incorrect interface identifier length 1339 137 Not home agent for this mobile node 1340 138 Duplicate Address Detection failed 1342 Up-to-date values of the Status field are to be specified in 1343 the most recent "Assigned Numbers" [26]. 1345 Sequence Number 1347 The Sequence Number in the Binding Acknowledgement is copied 1348 from the Sequence Number field in the Binding Update being 1349 acknowledged, for use by the mobile node in matching this 1350 Acknowledgement with an outstanding Binding Update. 1352 Lifetime 1354 The granted lifetime, in seconds, for which this node will 1355 attempt to retain the entry for this mobile node in its Binding 1356 Cache. If the node sending the Binding Acknowledgement is 1357 serving as the mobile node's home agent, the Lifetime period 1358 also indicates the period for which this node will continue 1359 this service; if the mobile node requires home agent service 1360 from this node beyond this period, the mobile node MUST send a 1361 new Binding Update to it before the expiration of this period 1362 (even if it is not changing its primary care-of address), in 1363 order to extend the lifetime. The value of this field is 1364 undefined if the Status field indicates that the Binding Update 1365 was rejected. 1367 Refresh 1369 The recommended interval, in seconds, at which the mobile 1370 node SHOULD send a new Binding Update to this node in order 1371 to "refresh" the mobile node's binding in this node's Binding 1372 Cache. This refreshing of the binding is useful in case the 1373 node fails and loses its cache state. The Refresh period is 1374 determined by the node sending the Binding Acknowledgement 1375 (the node caching the binding). If this node is serving as 1376 the mobile node's home agent, the Refresh value may be set, 1377 for example, based on whether the node stores its Binding 1378 Cache in volatile storage or in nonvolatile storage. If the 1379 node sending the Binding Acknowledgement is not serving as the 1380 mobile node's home agent, the Refresh period SHOULD be set 1381 equal to the Lifetime period in the Binding Acknowledgement; 1382 even if this node loses this cache entry due to a failure of 1383 the node, packets from it can still reach the mobile node 1384 through the mobile node's home agent, causing a new Binding 1385 Update to this node to allow it to recreate this cache entry. 1386 The value of this field is undefined if the Status field 1387 indicates that the Binding Update was rejected. 1389 Sub-Options 1391 Additional information, associated with this Binding 1392 Acknowledgement option, that need not be present in all Binding 1393 Acknowledgements sent. This use of sub-options also allows for 1394 future extensions to the format of the Binding Acknowledgement 1395 option to be defined. The encoding and format of defined 1396 sub-options are described in Section 5.5. Currently, no valid 1397 sub-options are defined for a Binding Acknowledgement option. 1399 The alignment requirement [6] for the Binding Acknowledgement option 1400 is 4n+3. 1402 Any packet that includes a Binding Acknowledgement option MUST 1403 be protected by IPsec [13] to guard against malicious Binding 1404 Acknowledgements. The specific requirements for this protection are 1405 defined in Section 4.4. 1407 If the node returning the Binding Acknowledgement accepted the 1408 Binding Update for which the Acknowledgement is being returned (the 1409 value of the Status field in the Acknowledgement is less than 128), 1410 this node will have an entry for the mobile node in its Binding Cache 1411 and MUST use this entry (which includes the care-of address received 1412 in the Binding Update) in sending the packet containing the Binding 1413 Acknowledgement to the mobile node. The details of sending this 1414 packet to the mobile node are the same as for sending any packet to 1415 a mobile node using a binding, as are described in Section 8.9. The 1416 packet is sent using a Routing header, routing the packet to the 1417 mobile node by way of its care-of address recorded in the Binding 1418 Cache entry. 1420 If the node returning the Binding Acknowledgement instead 1421 rejected the Binding Update (the value of the Status field in the 1422 Acknowledgement is greater than or equal to 128), this node MUST 1423 similarly use a Routing header in sending the packet containing the 1424 Binding Acknowledgement, as described in Section 8.9, but MUST NOT 1425 use its Binding Cache in forming the IP header or Routing header 1426 in this packet. Rather, the care-of address used by this node in 1427 sending the packet containing the Binding Acknowledgement MUST be 1428 copied from the care-of address received in the rejected Binding 1429 Update; this node MUST NOT modify its Binding Cache in response 1430 to receiving this rejected Binding Update and MUST ignore its 1431 Binding Cache in sending the packet in which it returns this Binding 1432 Acknowledgement. The packet is sent using a Routing header, routing 1433 the packet to the home address of the rejected Binding Update by 1434 way of the care-of address indicated in the packet containing the 1435 Binding Update. When sending a Binding Acknowledgement to reject a 1436 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 1437 packet containing no payload (with the Next Header field in the last 1438 extension header in the packet set to indicate "No Next Header" [6]). 1440 The three highest-order bits of the Option Type are encoded to 1441 indicate specific processing of the option [6]. For the Binding 1442 Acknowledgement option, these three bits are set to 000, indicating 1443 that any IPv6 node processing this option that does not recognize the 1444 Option Type must skip over this option and continue processing the 1445 header, and that the data within the option cannot change en-route to 1446 the packet's final destination. 1448 5.3. Binding Request Option 1450 The Binding Request destination option is used to request a mobile 1451 node's binding from the mobile node. As a destination option, it 1452 MAY be included in any existing packet being sent to the mobile 1453 node or MAY be sent in a packet by itself; a packet containing a 1454 Binding Request option is sent in the same way as any packet to a 1455 mobile node (Section 8.9). When a mobile node receives a packet 1456 containing a Binding Request option, it SHOULD return a Binding 1457 Update (Section 5.1) to the source of the Binding Request. 1459 The Binding Request option is encoded in type-length-value (TLV) 1460 format as follows: 1462 0 1 1463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1465 | Option Type | Option Length | Sub-Options... 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1468 Option Type 1470 8 1472 Option Length 1474 8-bit unsigned integer. Length of the option, in octets, 1475 excluding the Option Type and Option Length fields. This field 1476 MUST be set to 0 plus the total length of all sub-options 1477 present, including their Sub-Option Type and Sub-Option Len 1478 fields. 1480 Sub-Options 1482 Additional information, associated with this Binding Request 1483 option, that need not be present in all Binding Requests sent. 1484 This use of sub-options also allows for future extensions to 1485 the format of the Binding Request option to be defined. The 1486 encoding and format of defined sub-options are described in 1487 Section 5.5. The following sub-options are valid in a Binding 1488 Request option: 1490 - Unique Identifier Sub-Option 1492 There is no requirement for alignment [6] of the Binding Request 1493 option. 1495 The three highest-order bits of the Option Type are encoded to 1496 indicate specific processing of the option [6]. For the Binding 1497 Request option, these three bits are set to 000, indicating that any 1498 IPv6 node processing this option that does not recognize the Option 1499 Type must skip over this option and continue processing the header, 1500 and that the data within the option cannot change en-route to the 1501 packet's final destination. 1503 5.4. Home Address Option 1505 The Home Address destination option is used in a packet sent by a 1506 mobile node while away from home, to inform the recipient of that 1507 packet of the mobile node's home address. For packets sent by a 1508 mobile node while away from home, the mobile node generally uses 1509 one of its care-of addresses as the Source Address in the packet's 1510 IPv6 header. By including a Home Address option in the packet, the 1511 correspondent node receiving the packet is able to substitute the 1512 mobile node's home address for this care-of address when processing 1513 the packet, thus making the use of the care-of address transparent to 1514 the correspondent node. 1516 The Home Address option is encoded in type-length-value (TLV) format 1517 as follows: 1519 0 1 2 3 1520 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 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Option Type | Option Length | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | | 1525 + + 1526 | | 1527 + Home Address + 1528 | | 1529 + + 1530 | | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Sub-Options... 1533 +-+-+-+-+-+-+-+-+-+-+-+- 1535 Option Type 1537 201 = 0xC9 1539 Option Length 1541 8-bit unsigned integer. Length of the option, in octets, 1542 excluding the Option Type and Option Length fields. This field 1543 MUST be set to 16 plus the total length of all sub-options 1544 present, including their Sub-Option Type and Sub-Option Len 1545 fields. 1547 Home Address 1549 The home address of the mobile node sending the packet. 1551 Sub-Options 1553 Additional information, associated with this Home Address 1554 option, that need not be present in all Home Address options 1555 sent. This use of sub-options also allows for future 1556 extensions to the format of the Home Address option to be 1557 defined. The encoding and format of defined sub-options are 1558 described in Section 5.5. Currently, no valid sub-options are 1559 defined for use in a Home Address option. 1561 The alignment requirement [6] for the Home Address option is 8n+6. 1563 The inclusion of a Home Address option in a packet affects the 1564 receiving node's processing of only this single packet; no state is 1565 created or modified in the receiving node as a result of receiving a 1566 Home Address option in a packet. In particular, the presence of a 1567 Home Address option in a received packet MUST NOT alter the contents 1568 of the receiver's Binding Cache and MUST NOT cause any changes in the 1569 routing of subsequent packets sent by this receiving node. 1571 The Home Address option MUST be placed as follows: 1573 - After the Routing Header, if that header is present 1575 - Before the Fragment Header, if that header is present 1577 - Before the AH Header or ESP Header, if either one of those 1578 headers is present 1580 No authentication of the Home Address option is required, except 1581 that if the IPv6 header of a packet is covered by authentication, 1582 then that authentication MUST also cover the Home Address option; 1583 this coverage is achieved automatically by the definition of the 1584 Option Type code for the Home Address option, since it indicates 1585 that the data within the option cannot change en-route to the 1586 packet's final destination, and thus the option is included in the 1587 authentication computation. By requiring that any authentication of 1588 the IPv6 header also cover the Home Address option, the security of 1589 the Source Address field in the IPv6 header is not compromised by 1590 the presence of a Home Address option. Security issues related to 1591 the Home Address option are discussed further in Section 13. When 1592 attempting to verify authentication data in a packet that contains 1593 a Home Address option, the receiving node MUST make the calculation 1594 as if the care-of address were present in the Home Address option, 1595 and the home address were present in the source IPv6 address field 1596 of the IPv6 header. This conforms with the calculation specified in 1597 section 10.2. 1599 A packet MUST NOT contain more than one Home Address option, except 1600 that an encapsulated packet [4] MAY contain a separate Home Address 1601 option associated with each encapsulating IP header. 1603 The three highest-order bits of the Option Type are encoded to 1604 indicate specific processing of the option [6]. For the Home Address 1605 option, these three bits are set to 110, indicating that any IPv6 1606 node processing this option that does not recognize the Option Type 1607 must discard the packet and, only if the packet's Destination Address 1608 was not a multicast address, return an ICMP Parameter Problem, 1609 Code 2, message to the packet's Source Address; and that the data 1610 within the option cannot change en-route to the packet's final 1611 destination. 1613 5.5. Mobile IPv6 Destination Option Sub-Options 1615 In order to allow optional fields that may not be needed in every 1616 use of any given Mobile IPv6 destination option, and to allow future 1617 extensions to the format of these destination options to be defined, 1618 any of the Mobile IPv6 destination options defined in this document 1619 MAY include one or more sub-options. 1621 Such sub-options are included in the data portion of the destination 1622 option itself, after the fixed portion of the option data specified 1623 for that particular destination option (Sections 5.1 through 5.4). 1624 The presence of such sub-options will be indicated by the Option 1625 Length field. When the Option Length is greater than the standard 1626 length defined for that destination option, the remaining octets are 1627 interpreted as sub-options. 1629 These sub-options are encoded within the remaining space of the 1630 option data for that option, using a type-length-value (TLV) format 1631 as follows: 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 |Sub-Option Type| Sub-Option Len| Sub-Option Data... 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 Sub-Option Type 1641 8-bit identifier of the type of sub-option. When processing 1642 a Mobile IPv6 destination option containing a sub-option for 1643 which the Sub-Option Type value is not recognized by the 1644 receiver, the receiver SHOULD quietly ignore and skip over the 1645 sub-option, correctly handling any remaining sub-options in the 1646 option. 1648 Sub-Option Length 1650 8-bit unsigned integer. Length of the Sub-Option Data field 1651 of this sub-option, in octets. The Sub-Option Len does not 1652 include the length of the Sub-Option Type and Sub-Option Len 1653 fields. 1655 Sub-Option Data 1657 Variable-length field. Sub-Option-Type-specific data. 1659 As with IPv6 options appearing in a Hop-by-Hop Options header 1660 or Destination Options header [6], individual sub-options within 1661 a Mobile IPv6 destination option may have specific alignment 1662 requirements, to ensure that multi-octet values within Sub-Option 1663 Data fields fall on natural boundaries. The alignment requirement 1664 of each sub-option is specified as part of the definition of each 1665 sub-option below. 1667 Each section above defining the Mobile IPv6 destination options 1668 specifies which of the defined sub-options is valid for that 1669 destination option. In addition, there are two padding sub-options, 1670 Pad1 and PadN (defined below), which are used when necessary to align 1671 subsequent sub-options. The Pad1 and PadN sub-options are valid for 1672 all Mobile IPv6 destination options. Unlike the padding options 1673 used in Hop-by-Hop Options header or Destination Options header [6], 1674 there is no requirement for padding the total size of any Mobile IPv6 1675 destination option to a multiple of 8 octets in length, and the 1676 Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All 1677 Mobile IPv6 sub-options defined in this document MUST be recognized 1678 by all Mobile IPv6 implementations. 1680 Currently, the following sub-option types are defined for use in 1681 Mobile IPv6 destination options: 1683 Pad1 Sub-Option (alignment requirement: none) 1685 0 1686 0 1 2 3 4 5 6 7 1687 +-+-+-+-+-+-+-+-+ 1688 | 0 | 1689 +-+-+-+-+-+-+-+-+ 1691 NOTE! the format of the Pad1 sub-option is a special 1692 case -- it does not have Sub-Option Len and Sub-Option Data 1693 fields. 1695 The Pad1 sub-option is used to insert one octet of padding 1696 into the Sub-Options area of a Mobile IPv6 option. If more 1697 than one octet of padding is required, the PadN sub-option, 1698 described next, should be used, rather than multiple Pad1 1699 sub-options. 1701 PadN Sub-Option (alignment requirement: none) 1703 0 1 1704 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1706 | 1 | Sub-Option Len| Sub-Option Data 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1709 The PadN sub-option is used to insert two or more octets of 1710 padding into the Sub-Options area of a Mobile IPv6 option. 1711 For N octets of padding, the Sub-Option Len field contains 1712 the value N-2, and the Sub-Option Data consists of N-2 1713 zero-valued octets. 1715 Unique Identifier Sub-Option (alignment requirement: 2n) 1717 0 1 2 3 1718 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 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | 2 | 2 | Unique Identifier | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 The Unique Identifier sub-option is valid only in Binding 1724 Request and Binding Update destination options. The Unique 1725 Identifier field contains a 16-bit value that serves to 1726 uniquely identify a Binding Request among those sent by this 1727 Source Address, and to allow the Binding Update to identify 1728 the specific Binding Request to which it responds. This 1729 matching of Binding Updates to Binding Requests is required 1730 in the procedure for renumbering the home subnet while a 1731 mobile node is away from home (Section 9.8). 1733 Alternate Care-of Address Sub-Option (alignment requirement: 8n+6) 1735 0 1 2 3 1736 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 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | 4 | 16 | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | | 1741 + + 1742 | | 1743 + Alternate Care-of Address + 1744 | | 1745 + + 1746 | | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 The Alternate Care-of Address sub-option is valid only in 1750 Binding Update destination options. The Alternate Care-of 1751 Address field contains an address to use as the care-of 1752 address for the binding, rather than using the Source 1753 Address of the packet as the care-of address. 1755 5.6. ICMP Home Agent Address Discovery Request Message 1757 The ICMP Home Agent Address Discovery Request message is used by a 1758 mobile node to initiate the dynamic home agent address discovery 1759 mechanism, as described in Sections 9.2 and 10.7. The mobile 1760 node sends a Home Agent Address Discovery Request message to the 1761 "Mobile IPv6 Home-Agents" anycast address for its own home subnet 1762 prefix [10], and one of the home agents there responds to the mobile 1763 node with a Home Agent Address Discovery Reply message giving a list 1764 of the routers on the mobile node's home link serving as home agents. 1766 0 1 2 3 1767 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 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Type | Code | Checksum | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Identifier | | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1773 | | 1774 + Reserved + 1775 | | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | | 1778 + + 1779 | | 1780 + Home Address + 1781 | | 1782 + + 1783 | | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 Type 1788 1790 Code 1792 0 1794 Checksum 1796 The ICMP checksum [5]. 1798 Identifier 1800 An identifier to aid in matching Home Agent Address Discovery 1801 Reply messages to this Home Agent Address Discovery Request 1802 message. 1804 Reserved 1806 This field is unused. It MUST be initialized to zero by the 1807 sender and MUST be ignored by the receiver. 1809 Home Address 1811 The home address of the mobile node sending the Home Agent 1812 Address Discovery Request message. 1814 The Source Address of the Home Agent Address Discovery Request 1815 message packet MUST be one of the mobile node's current care-of 1816 addresses, and the mobile node MUST NOT include a Home Address 1817 option in this packet; the home agent then MUST return the Home 1818 Agent Address Discovery Reply message directly to this care-of 1819 address. These restrictions are necessary, since at the time of 1820 performing this dynamic home agent address discovery, the mobile node 1821 is generally not registered with its home agent; using the mobile 1822 node's care-of address simplifies the return of the Reply message to 1823 the mobile node. 1825 5.7. ICMP Home Agent Address Discovery Reply Message 1827 The ICMP Home Agent Address Discovery Reply message is used by a 1828 home agent to respond to a mobile node using the dynamic home agent 1829 address discovery mechanism, as described in Sections 9.2 and 10.7. 1830 The mobile node sends a Home Agent Address Discovery Request message 1831 to the "Mobile IPv6 Home-Agents" anycast address for its own home 1832 subnet prefix [10], and one of the home agents there responds to the 1833 mobile node with a Home Agent Address Discovery Reply message giving 1834 a list of the routers on the mobile node's home link serving as home 1835 agents. 1837 0 1 2 3 1838 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 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Type | Code | Checksum | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | Identifier | | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1844 | | 1845 + Reserved + 1846 | | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | | 1849 + + 1850 . . 1851 . Home Agent Addresses . 1852 . . 1853 + + 1854 | | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 Type 1859 1861 Code 1863 0 1865 Checksum 1867 The ICMP checksum [5]. 1869 Identifier 1871 The identifier from the invoking Home Agent Address Discovery 1872 Request message. 1874 Reserved 1876 This field is unused. It MUST be initialized to zero by the 1877 sender and MUST be ignored by the receiver. 1879 Home Agent Addresses 1881 A list of addresses of home agents on the home link for the 1882 mobile node. The number of addresses present in the list is 1883 indicated by the remaining length of the IPv6 packet carrying 1884 the Home Agent Address Discovery Reply message. 1886 6. Modifications to IPv6 Neighbor Discovery 1888 6.1. Modified Router Advertisement Message Format 1890 Mobile IPv6 modifies the format of the Router Advertisement 1891 message [17] by the addition of a single flag bit to indicate that 1892 the router sending the Advertisement message is serving as a home 1893 agent on this link. The format of the Router Advertisement message 1894 is as follows: 1896 0 1 2 3 1897 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 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Type | Code | Checksum | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Reachable Time | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Retrans Timer | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Options ... 1908 +-+-+-+-+-+-+-+-+-+-+-+- 1910 This format represents the following changes over that originally 1911 specified for Neighbor Discovery [17]: 1913 Home Agent (H) 1915 The Home Agent (H) bit is set in a Router Advertisement to 1916 indicate that the router sending this Router Advertisement is 1917 also functioning as a Mobile IP home agent on this link. 1919 Reserved 1921 Reduced from a 6-bit field to a 5-bit field to account for the 1922 addition of the Home Agent (H) bit. 1924 6.2. Modified Prefix Information Option Format 1926 Mobile IPv6 requires knowledge of a router's global address for two 1927 reasons: 1929 - To allow a home agent (a router) to learn the address of all 1930 other home agents on the link for which it is providing home 1931 agent service, for use in building its Home Agents List as 1932 part of the dynamic home agent address discovery mechanism 1933 (Sections 9.2 and 10.7). 1935 - To allow a mobile node to send a Binding Update to a router on 1936 the link on which its previous care-of address is located, for 1937 purposes of establishing forwarding from this previous care-of 1938 address to its new care-of address (Section 10.9). 1940 However, Neighbor Discovery [17] only advertises a router's 1941 link-local address, by requiring this address to be used as the IP 1942 Source Address of each Router Advertisement. 1944 Mobile IPv6 extends Neighbor Discovery to allow a router to easily 1945 and efficiently advertise its global address, by the addition of a 1946 single flag bit in the format of a Prefix Information option for 1947 use in Router Advertisement messages. The format of the Prefix 1948 Information option is as follows: 1950 0 1 2 3 1951 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 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Type | Length | Prefix Length |L|A|R|Reserved1| 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | Valid Lifetime | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Preferred Lifetime | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | Reserved2 | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | | 1962 + + 1963 | | 1964 + Prefix + 1965 | | 1966 + + 1967 | | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 This format represents the following changes over that originally 1971 specified for Neighbor Discovery [17]: 1973 Router Address (R) 1975 1-bit router address flag. When set, indicates that the 1976 Prefix field, in addition to advertising the indicated prefix, 1977 contains a complete IP address assigned to the sending router. 1978 This router IP address has the same scope and conforms to the 1979 same lifetime values as the advertised prefix. This use of 1980 the Prefix field is compatible with its use in advertising 1981 the prefix itself, since prefix advertisement uses only the 1982 leading number Prefix bits specified by the Prefix Length 1983 field. Interpretation of this flag bit is thus independent 1984 of the processing required for the On-Link (L) and Autonomous 1985 Address-Configuration (A) flag bits. 1987 Reserved1 1989 Reduced from a 6-bit field to a 5-bit field to account for the 1990 addition of the Router Address (R) bit. 1992 In a solicited Router Advertisement, a router MUST include at least 1993 one Prefix Information option with the Router Address (R) bit set. 1994 Neighbor Discovery specifies that, if including all options in a 1995 Router Advertisement causes the size of the Advertisement to exceed 1996 the link MTU, multiple Advertisements can be sent, each containing 1997 a subset of the options [17]. In this case, at least one of these 1998 multiple Advertisements being sent instead of a single larger 1999 solicited Advertisement, MUST include a Prefix Information option 2000 with the Router Address (R) bit set. 2002 All routers SHOULD include at least one Prefix Information option 2003 with the Router Address (R) bit set, in each unsolicited multicast 2004 Router Advertisement that they send. If multiple Advertisements 2005 are being sent instead of a single larger unsolicited multicast 2006 Advertisement, at least one of these multiple Advertisements SHOULD 2007 include a Prefix Information option with the Router Address (R) bit 2008 set. 2010 6.3. New Advertisement Interval Option Format 2012 Mobile IPv6 defines a new Advertisement Interval option, used in 2013 Router Advertisement messages to advertise the interval at which the 2014 sending router sends unsolicited multicast Router Advertisements. 2015 The format of the Advertisement Interval option is as follows: 2017 0 1 2 3 2018 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 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Type | Length | Reserved | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | Advertisement Interval | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 Type 2027 7 2029 Length 2031 8-bit unsigned integer. The length of the option (including 2032 the type and length fields) in units of 8 octets. The value of 2033 this field MUST be 1. 2035 Reserved 2037 This field is unused. It MUST be initialized to zero by the 2038 sender and MUST be ignored by the receiver. 2040 Advertisement Interval 2042 32-bit unsigned integer. The maximum time, in milliseconds, 2043 between successive unsolicited router Router Advertisement 2044 messages sent by this router on this network interface. Using 2045 the conceptual router configuration variables defined by 2046 Neighbor Discovery [17], this field MUST be equal to the value 2047 MaxRtrAdvInterval, expressed in milliseconds. 2049 Routers MAY include this option in their Router Advertisements. A 2050 mobile node receiving a Router Advertisement containing this option 2051 SHOULD utilize the specified Advertisement Interval for that router 2052 in its movement detection algorithm, as described in Section 10.4. 2054 This option MUST be silently ignored for other Neighbor Discovery 2055 messages. 2057 6.4. New Home Agent Information Option Format 2059 Mobile IPv6 defines a new Home Agent Information option, used in 2060 Router Advertisement messages sent by a home agent to advertise 2061 information specific to this router's functionality as a home agent. 2062 The format of the Home Agent Information option is as follows: 2064 0 1 2 3 2065 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 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | Type | Length | Reserved | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | Home Agent Preference | Home Agent Lifetime | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 Type 2074 8 2076 Length 2078 8-bit unsigned integer. The length of the option (including 2079 the type and length fields) in units of 8 octets. The value of 2080 this field MUST be 1. 2082 Reserved 2084 This field is unused. It MUST be initialized to zero by the 2085 sender and MUST be ignored by the receiver. 2087 Home Agent Preference 2089 16-bit signed, twos-complement integer. The preference for 2090 the home agent sending this Router Advertisement, for use in 2091 ordering the addresses returned to a mobile node in the Home 2092 Agent Addresses field of a Home Agent Address Discovery Reply 2093 message. Higher values mean more preferable. If this option 2094 is not included in a Router Advertisement in which the Home 2095 Agent (H) bit is set, the preference value for this home agent 2096 SHOULD be considered to be 0. Values greater than 0 indicate a 2097 home agent more preferable than this default value, and values 2098 less than 0 indicate a less preferable home agent. 2100 The manual configuration of the Home Agent Preference value 2101 is described in Section 7.3. In addition, the sending home 2102 agent MAY dynamically set the Home Agent Preference value, for 2103 example basing it on the number of mobile nodes it is currently 2104 serving or on its remaining resources for serving additional 2105 mobile nodes; such dynamic settings are beyond the scope of 2106 this document. Any such dynamic setting of the Home Agent 2107 Preference, however, MUST set the preference appropriately, 2108 relative to the default Home Agent Preference value of 0 that 2109 may be in use by some home agents on this link (i.e., a home 2110 agent not including a Home Agent Information option in its 2111 Router Advertisements will be considered to have a Home Agent 2112 Preference value of 0). 2114 Home Agent Lifetime 2116 16-bit unsigned integer. The lifetime associated with the home 2117 agent in units of seconds. The maximum value corresponds to 2118 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 2119 Lifetime applies only to this router's usefulness as a home 2120 agent; it does not apply to information contained in other 2121 message fields or options. If this option is not included in 2122 a Router Advertisement in which the Home Agent (H) bit is set, 2123 the lifetime for this home agent MUST be considered to be the 2124 same as the Router Lifetime specified in the main body of the 2125 Router Advertisement message. 2127 Home agents MAY include this option in their Router Advertisements. 2128 This option MUST NOT be included in a Router Advertisement in which 2129 the Home Agent (H) bit (see Section 6.1) is not set. 2131 This option MUST be silently ignored for other Neighbor Discovery 2132 messages. 2134 If both the Home Agent Preference and Home Agent Lifetime are set 2135 to their default values specified above, this option SHOULD NOT be 2136 included in the Router Advertisement messages sent by this home 2137 agent. 2139 6.5. Changes to Sending Router Advertisements 2141 The Neighbor Discovery protocol specification [17] limits routers to 2142 a minimum interval of 3 seconds between sending unsolicited multicast 2143 Router Advertisement messages from any given network interface 2144 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 2146 "Routers generate Router Advertisements frequently enough 2147 that hosts will learn of their presence within a few 2148 minutes, but not frequently enough to rely on an absence 2149 of advertisements to detect router failure; a separate 2150 Neighbor Unreachability Detection algorithm provides failure 2151 detection." 2153 This limitation, however, is not suitable to providing timely 2154 movement detection for mobile nodes. Mobile nodes detect their 2155 own movement by learning the presence of new routers as the mobile 2156 node moves into wireless transmission range of them (or physically 2157 connects to a new wired network), and by learning that previous 2158 routers are no longer reachable. Mobile nodes MUST be able to 2159 quickly detect when they move to a link served by a new router, so 2160 that they can acquire a new care-of address and send Binding Updates 2161 to register this care-of address with their home agent and to notify 2162 correspondent nodes as needed. 2164 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 2165 this limit such that routers MAY send unsolicited multicast Router 2166 Advertisements more frequently. In particular, on network interfaces 2167 where the router is expecting to provide service to visiting mobile 2168 nodes (e.g., wireless network interfaces), or on which it is serving 2169 as a home agent to one or more mobile nodes (who may return home and 2170 need to hear its Advertisements), the router SHOULD be configured 2171 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 2172 to allow sending of unsolicited multicast Router Advertisements more 2173 often. Recommended values for these limits are: 2175 - MinRtrAdvInterval 0.5 seconds 2177 - MaxRtrAdvInterval 1.5 seconds 2179 Use of these modified limits MUST be configurable, and specific 2180 knowledge of the type of network interface in use SHOULD be taken 2181 into account in configuring these limits for each network interface. 2183 When sending unsolicited multicast Router Advertisements more 2184 frequently than the standard limit on unsolicited multicast 2185 Advertisement frequency, the sending router need not include all 2186 options in each of these Advertisements, but it SHOULD include at 2187 least one Prefix Information option with the Router Address (R) bit 2188 set (Section 6.2) in each. 2190 6.6. Changes to Sending Router Solicitations 2192 In addition to the limit on routers sending unsolicited multicast 2193 Router Advertisement messages (Section 6.5), Neighbor Discovery 2194 defines limits on nodes sending Router Solicitation messages, such 2195 that a node SHOULD send no more than 3 Router Solicitations, and that 2196 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 2197 However, these limits prevent a mobile node from finding a new 2198 default router (and thus a new care-of address) quickly as it moves 2199 about. 2201 Mobile IPv6 relaxes this limit such that, while a mobile node is away 2202 from home, it MAY send Router Solicitations more frequently. The 2203 following limits for sending Router Solicitations are recommended for 2204 mobile nodes while away from home: 2206 - A mobile node that is not configured with any current care-of 2207 address (e.g., the mobile node has moved since its previous 2208 care-of address was configured), MAY send more than the defined 2209 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 2210 Solicitations. 2212 - The rate at which a mobile node sends Router Solicitations MUST 2213 be limited, although a mobile node MAY send Router Solicitations 2214 more frequently than the defined Neighbor Discovery limit of 2215 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 2216 be configurable, and specific knowledge of the type of network 2217 interface in use SHOULD be taken into account in configuring this 2218 limit for each network interface. A recommended minimum interval 2219 is 1 second. 2221 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 2222 a mobile node MUST reduce the rate at which it sends subsequent 2223 Router Solicitations. Subsequent Router Solicitations SHOULD 2224 be sent using a binary exponential backoff mechanism, doubling 2225 the interval between consecutive Router Solicitations, up to a 2226 maximum interval. The maximum interval MUST be configurable and 2227 SHOULD be chosen appropriately based on the characteristics of 2228 the type of network interface in use. 2230 - While still searching for a new default router and care-of 2231 address, a mobile node MUST NOT increase the rate at which it 2232 sends Router Solicitations unless it has received a positive 2233 indication (such as from lower network layers) that it has moved 2234 to a new link. After successfully acquiring a new care-of 2235 address, the mobile node SHOULD also increase the rate at which 2236 it will send Router Solicitations when it next begins searching 2237 for a new default router and care-of address. 2239 - A mobile node that is currently configured with a care-of address 2240 SHOULD NOT send Router Solicitations to the default router 2241 on it current link, until its movement detection algorithm 2242 (Section 10.4) determines that it has moved and that its current 2243 care-of address might no longer be valid. 2245 7. Requirements for Types of IPv6 Nodes 2247 Mobile IPv6 places some special requirements on the functions 2248 provided by different types of IPv6 nodes. This section summarizes 2249 those requirements, identifying the functionality each requirement 2250 is intended to support. Further details on this functionality is 2251 provided in the following sections. 2253 7.1. Requirements for All IPv6 Hosts and Routers 2255 Since any IPv6 node may at any time be a correspondent node of a 2256 mobile node, either sending a packet to a mobile node or receiving a 2257 packet from a mobile node, the following requirements apply to ALL 2258 IPv6 nodes (whether host or router, whether mobile or stationary): 2260 - Every IPv6 node MUST be able to process a Home Address option 2261 received in any IPv6 packet. 2263 - Every IPv6 node SHOULD be able to process a Binding Update option 2264 received in a packet, and to return a Binding Acknowledgement 2265 option if the Acknowledge (A) bit is set in the received Binding 2266 Update. 2268 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 2269 bindings received in accepted Binding Updates. 2271 7.2. Requirements for All IPv6 Routers 2273 The following requirements apply to all IPv6 routers, even those not 2274 serving as a home agent for Mobile IPv6: 2276 - Every IPv6 router SHOULD be able to send an Advertisement 2277 Interval option in its Router Advertisements, to aid movement 2278 detection by mobile nodes. The use of this option in Router 2279 Advertisements MUST be configurable. 2281 - Every IPv6 router SHOULD be able to support sending unsolicited 2282 multicast Router Advertisements at the faster rate described in 2283 Section 6.5. The use of this faster rate MUST be configurable. 2285 7.3. Requirements for IPv6 Home Agents 2287 In order for a mobile node to operate correctly while away from home, 2288 at least one IPv6 router on the mobile node's home link must function 2289 as a home agent for the mobile node. The following additional 2290 requirements apply to all IPv6 routers capable of serving as a home 2291 agent: 2293 - Every home agent MUST be able to maintain an entry in its Binding 2294 Cache for each mobile node for which it is serving as the home 2295 agent. Each such Binding Cache entry records the mobile node's 2296 binding with its primary care-of address and is marked as a "home 2297 registration". 2299 - Every home agent MUST be able to intercept packets (using proxy 2300 Neighbor Discovery) addressed to a mobile node for which it is 2301 currently serving as the home agent, on that mobile node's home 2302 link, while the mobile node is away from home. 2304 - Every home agent MUST be able to encapsulate such intercepted 2305 packets in order to tunnel them to the primary care-of address 2306 for the mobile node indicated in its binding in the home agent's 2307 Binding Cache. 2309 - Every home agent MUST be able to return a Binding Acknowledgement 2310 option in response to a Binding Update option received with the 2311 Acknowledge (A) bit set. 2313 - Every home agent MUST maintain a separate Home Agents List for 2314 each link on which it is serving as a home agent, as described in 2315 Section 4.6. 2317 - Every home agent MUST be able to accept packets addressed to 2318 the "Mobile IPv6 Home-Agents" anycast address for the subnet 2319 on which it is serving as a home agent [10], and MUST be 2320 able to participate in dynamic home agent address discovery 2321 (Section 9.2). 2323 - Every home agent SHOULD support a configuration mechanism to 2324 allow a system administrator to manually set the value to be sent 2325 by this home agent in the Home Agent Preference field of the Home 2326 Agent Information Option in Router Advertisements that it sends. 2328 7.4. Requirements for IPv6 Mobile Nodes 2330 Finally, the following requirements apply to all IPv6 nodes capable 2331 of functioning as mobile nodes: 2333 - Every IPv6 mobile node MUST be able to perform IPv6 2334 decapsulation [4]. 2336 - Every IPv6 mobile node MUST support sending Binding Update 2337 options, as specified in Sections 10.6, 10.8, and 10.9; and MUST 2338 be able to receive and process Binding Acknowledgement options, 2339 as specified in Section 10.12. 2341 - Every IPv6 mobile node MUST support use of the dynamic home agent 2342 address discovery mechanism, as described in Section 10.7. 2344 - Every IPv6 mobile node MUST maintain a Binding Update List in 2345 which it records the IP address of each other node to which it 2346 has sent a Binding Update, for which the Lifetime sent in that 2347 binding has not yet expired. 2349 - Every IPv6 mobile node MUST support receiving a Binding Request 2350 option, by responding with a Binding Update option. 2352 - Every IPv6 mobile node MUST support sending packets containing a 2353 Home Address option; this option MUST be included in all packets 2354 sent while away from home, if the packet would otherwise have 2355 been sent with the mobile node's home address as the IP Source 2356 Address. 2358 - Every IPv6 mobile node MUST maintain a Home Agents List, as 2359 described in Section 4.6. 2361 8. Correspondent Node Operation 2363 A correspondent node is any node communicating with a mobile node. 2364 The correspondent node, itself, may be stationary or mobile, and may 2365 possibly also be functioning as a home agent for Mobile IPv6. The 2366 procedures in this section thus apply to all IPv6 nodes. 2368 8.1. Receiving Packets from a Mobile Node 2370 Packets sent by a mobile node while away from home generally include 2371 a Home Address option. When any node receives a packet containing 2372 a Home Address option, it MUST process the option in a manner 2373 consistent with exchanging the Home Address field from the Home 2374 Address option into the IPv6 header, replacing the original value of 2375 the Source Address field there. However, any actual modifications 2376 to the Source Address field in the packet's IPv6 header MUST not 2377 be performed until after all processing of other options contained 2378 in the same Destination Options extension header is completed. 2379 Currently, no other such options are defined. 2381 Further processing of such a packet after all IPv6 options processing 2382 (e.g., at the transport layer) thus does not need to know that the 2383 original Source Address was a care-of address, or that the Home 2384 Address option was used in the packet. Since the sending mobile 2385 node uses its home address at the transport layer when sending such 2386 a packet, the use of the care-of address and Home Address option is 2387 transparent to both the mobile node and the correspondent node above 2388 the level of the Home Address option generation and processing. 2390 8.2. Receiving Binding Updates 2392 Upon receiving a Binding Update option in some packet, the receiving 2393 node MUST validate the Binding Update according to the following 2394 tests: 2396 - The packet meets the specific IPsec requirements for Binding 2397 Updates, defined in Section 4.4. 2399 - The packet MUST contain a Home Address option. 2401 - The Option Length field in the Binding Update option is greater 2402 than or equal to the length specified in Section 5.1. 2404 - The Sequence Number field in the Binding Update option is greater 2405 than the Sequence Number received in the previous Binding Update 2406 for this home address, if any. As noted in Section 4.6, this 2407 Sequence Number comparison MUST be performed modulo 2**16. 2409 Any Binding Update not satisfying all of these tests MUST be 2410 silently ignored, and the packet carrying the Binding Update MUST be 2411 discarded. 2413 In this section, the care-of address refers to the IPv6 address, 2414 which was originally located in the IPv6 header when the packet was 2415 transmitted by the mobile node. 2417 If the Binding Update is valid according to the tests above, then the 2418 Binding Update is processed further as follows: 2420 - If the Lifetime specified in the Binding Update is nonzero and 2421 the specified Care-of Address is not equal to the home address 2422 for the binding, then this is a request to cache a binding for 2423 the mobile node. If the Home Registration (H) bit is set in the 2424 Binding Update, the Binding Update is processed according to the 2425 procedure specified in Section 9.3; otherwise, it is processed 2426 according to the procedure specified in Section 8.3. 2428 - If the Lifetime specified in the Binding Update is zero or the 2429 specified Care-of Address matches the home address for the 2430 binding, then this is a request to delete the mobile node's 2431 cached binding. If the Home Registration (H) bit is set in the 2432 Binding Update, the Binding Update is processed according to the 2433 procedure specified in Section 9.4; otherwise, it is processed 2434 according to the procedure specified in Section 8.4. 2436 8.3. Requests to Cache a Binding 2438 When a node receives a Binding Update, it MUST validate it and 2439 determine the type of Binding Update according to the steps described 2440 in Section 8.2. This section describes the processing of a valid 2441 Binding Update that requests a node to cache a mobile node's binding, 2442 for which the Home Registration (H) bit is not set in the Binding 2443 Update. 2445 In this case, the receiving node SHOULD create a new entry in its 2446 Binding Cache for this mobile node (or update its existing Binding 2447 Cache entry for this mobile node, if such an entry already exists). 2448 The new Binding Cache entry records the association between this 2449 home address and the care-of address for the binding. The lifetime 2450 for the Binding Cache entry is initialized from the Lifetime field 2451 specified in the Binding Update, although this lifetime MAY be 2452 reduced by the node caching the binding; the lifetime for the Binding 2453 Cache entry MUST NOT be greater than the Lifetime value specified in 2454 the Binding Update. Any Binding Cache entry MUST be deleted after 2455 the expiration of this lifetime in the Binding Cache entry. 2457 8.4. Requests to Delete a Binding 2459 When a node receives a Binding Update, it MUST validate it and 2460 determine the type of Binding Update according to the steps described 2461 in Section 8.2. This section describes the processing of a valid 2462 Binding Update that requests a node to delete a mobile node's binding 2463 from its Binding Cache, for which the Home Registration (H) bit is 2464 not set in the Binding Update. In this case, the receiving node MUST 2465 delete any existing entry in its Binding Cache for this mobile node. 2467 8.5. Sending Binding Acknowledgements 2469 When any node receives a packet containing a Binding Update option 2470 in which the Acknowledge (A) bit is set, it MUST return a Binding 2471 Acknowledgement option acknowledging receipt of the Binding Update. 2472 If the node accepts the Binding Update and creates or updates 2473 an entry in its Binding Cache for this binding, and the `A' bit 2474 was set in the Binding Update, the Status field in the Binding 2475 Acknowledgement MUST be set to a value less than 128; if, on the 2476 other hand the Binding Update is accepted and the `A' bit is not set, 2477 the node SHOULD NOT send a Binding Acknowledgement. If the node 2478 rejects the Binding Update and does not create or update an entry for 2479 this binding, a Binding Acknowledgement MUST be sent even if the `A' 2480 bit was not sent, and the Status field in the Binding Acknowledgement 2481 MUST be set to a value greater than or equal to 128. Specific values 2482 for the Status field are described in Section 5.2 and in the most 2483 recent "Assigned Numbers" [26]. 2485 The packet in which the Binding Acknowledgement is returned MUST meet 2486 the specific IPsec requirements for Binding Acknowledgements, defined 2487 in Section 4.4; and the packet MUST be sent using a Routing header 2488 in the same way as any other packet sent to a mobile node using a 2489 care-of address (even if the binding was rejected), as described in 2490 Section 8.9. 2492 8.6. Sending Binding Requests 2494 Entries in a node's Binding Cache MUST be deleted when their lifetime 2495 expires. If such an entry is still in active use in sending packets 2496 to a mobile node, the next packet sent to the mobile node will be 2497 routed normally to the mobile node's home link, where it will be 2498 intercepted and tunneled to the mobile node. The mobile node will 2499 then return a Binding Update to the sender, allowing it to create 2500 a new Binding Cache entry for sending future packets to the mobile 2501 node. Communication with the mobile node continues uninterrupted, 2502 but the forwarding of this packet through the mobile node's home 2503 agent creates additional overhead and latency in delivering packets 2504 to the mobile node. 2506 If the sender knows that the Binding Cache entry is still in active 2507 use, it MAY send a Binding Request option to the mobile node in 2508 an attempt to avoid this overhead and latency due to deleting and 2509 recreating the Binding Cache entry. Since a Binding Request is a 2510 destination option, it may, for example, be included in any packet 2511 already being sent to the mobile node, such as a packet that is part 2512 of ongoing TCP communication with the mobile node. When the mobile 2513 node receives a packet from some sender containing a Binding Request 2514 option, it returns a Binding Update option to that sender, giving its 2515 current binding and a new lifetime. 2517 8.7. Cache Replacement Policy 2519 Any entry in a node's Binding Cache MUST be deleted after the 2520 expiration of the Lifetime specified in the Binding Update from 2521 which the entry was created or last updated. Conceptually, a node 2522 maintains a separate timer for each entry in its Binding Cache. When 2523 creating or updating a Binding Cache entry in response to a received 2524 and accepted Binding Update, the node sets the timer for this entry 2525 to the specified Lifetime period. When a Binding Cache entry's timer 2526 expires, the node deletes the entry. 2528 Each node's Binding Cache will, by necessity, have a finite size. 2529 A node MAY use any reasonable local policy for managing the space 2530 within its Binding Cache, except that any entry marked as a "home 2531 registration" (Section 9.3) MUST NOT be deleted from the cache until 2532 the expiration of its lifetime period. When attempting to add a new 2533 "home registration" entry in response to a Binding Update with the 2534 Home Registration (H) bit set, if insufficient space exists (and 2535 sufficient space cannot be reclaimed) in the node's Binding Cache, 2536 the node MUST reject the Binding Update and SHOULD return a Binding 2537 Acknowledgement to the sending mobile node, in which the Status field 2538 is set to 131 (insufficient resources). When otherwise attempting to 2539 add a new entry to its Binding Cache, a node MAY, if needed, choose 2540 to drop any entry already in its Binding Cache, other than a "home 2541 registration" entry, in order to make space for the new entry. For 2542 example, a "least-recently used" (LRU) strategy for cache entry 2543 replacement among entries not marked as a "home registration" is 2544 likely to work well. 2546 Any binding dropped from a node's Binding Cache due to lack of cache 2547 space will be rediscovered and a new cache entry created, if the 2548 binding is still in active use by the node for sending packets. If 2549 the node sends a packet to a destination for which it has dropped the 2550 entry from its Binding Cache, the packet will be routed normally, 2551 leading to the mobile node's home link. There, the packet will be 2552 intercepted by the mobile node's home agent and tunneled to the 2553 mobile node's current primary care-of address. As when a Binding 2554 Cache entry is initially created, this indirect routing to the mobile 2555 node through its home agent will result in the mobile node sending 2556 a Binding Update to this sending node when it receives the tunneled 2557 packet, allowing it to add an entry again for this destination mobile 2558 node to its Binding Cache. 2560 8.8. Receiving ICMP Error Messages 2562 When a correspondent node sends a packet to a mobile node, if the 2563 correspondent node has a Binding Cache entry for the destination 2564 address of the packet, then the correspondent node uses a Routing 2565 header to deliver the packet to the mobile node through the care-of 2566 address in the binding recorded in the Binding Cache entry. Any ICMP 2567 error message caused by the packet on its way to the mobile node will 2568 be returned normally to the correspondent node. 2570 On the other hand, if the correspondent node has no Binding Cache 2571 entry for the mobile node, the packet will be routed to the mobile 2572 node's home link. There, it will be intercepted by the mobile node's 2573 home agent, encapsulated, and tunneled to the mobile node's primary 2574 care-of address. Any ICMP error message caused by the packet on 2575 its way to the mobile node while in the tunnel, will be transmitted 2576 to the mobile node's home agent (the source of the tunnel). By the 2577 definition of IPv6 encapsulation [4], this encapsulating node MUST 2578 relay certain ICMP error messages back to the original sender of the 2579 packet, which in this case is the correspondent node. 2581 Likewise, if a packet for a mobile node arrives at the mobile node's 2582 previous link and is intercepted there by a home agent for the mobile 2583 node's previous care-of address as described in Section 10.9 (e.g., 2584 the mobile node moved after the packet was sent), that home agent 2585 will encapsulate and tunnel the packet to the mobile node's new 2586 care-of address. As above, any ICMP error message caused by the 2587 packet while in this tunnel will be returned to that home agent (the 2588 source of the tunnel), which MUST relay certain ICMP error messages 2589 back to the correspondent node [4]. 2591 Thus, in all cases, any meaningful ICMP error messages caused 2592 by packets from a correspondent node to a mobile node will be 2593 returned to the correspondent node. If the correspondent node 2594 receives persistent ICMP Destination Unreachable messages after 2595 sending packets to a mobile node based on an entry in its Binding 2596 Cache, the correspondent node SHOULD delete this Binding Cache 2597 entry. If the correspondent node subsequently transmits another 2598 packet to the mobile node, the packet will be routed to the mobile 2599 node's home link, intercepted by the mobile node's home agent, and 2600 tunneled to the mobile node's primary care-of address using IPv6 2601 encapsulation. The mobile node will then return a Binding Update to 2602 the correspondent node, allowing it to recreate a (correct) Binding 2603 Cache entry for the mobile node. 2605 8.9. Sending Packets to a Mobile Node 2607 Before sending any packet, the sending node SHOULD examine its 2608 Binding Cache for an entry for the destination address to which the 2609 packet is being sent. If the sending node has a Binding Cache entry 2610 for this address, the sending node SHOULD use a Routing header to 2611 route the packet to this mobile node (the destination node) by way 2612 of the care-of address in the binding recorded in that Binding Cache 2613 entry. For example, assuming use of a Type 0 Routing header [6], if 2614 no other use of a Routing header is involved in the routing of this 2615 packet, the mobile node sets the fields in the packet's IPv6 header 2616 and Routing header as follows: 2618 - The Destination Address in the packet's IPv6 header is set to 2619 the mobile node's care-of address copied from the Binding Cache 2620 entry. 2622 - The Routing header is initialized to contain a single route 2623 segment, with an Address of the mobile node's home address (the 2624 original destination address to which the packet was being sent). 2626 Following the definition of a Type 0 Routing header [6], this packet 2627 will be routed to the mobile node's care-of address, where it will 2628 be delivered to the mobile node (the mobile node has associated the 2629 care-of address with its network interface). Normal processing of 2630 the Routing header by the mobile node will then proceed as follows: 2632 - The mobile node swaps the Destination Address in the packet's 2633 IPv6 header and the Address specified in the Routing header. 2634 This results in the packet's IP Destination Address being set to 2635 the mobile node's home address. 2637 - The mobile node then resubmits the packet to its IPv6 module for 2638 further processing, "looping back" the packet inside the mobile 2639 node. Since the mobile node recognizes its own home address as 2640 one of its current IP addresses, the packet is processed further 2641 within the mobile node, in the same way then as if the mobile 2642 node was at home. 2644 If, instead, the sending node has no Binding Cache entry for the 2645 destination address to which the packet is being sent, the sending 2646 node simply sends the packet normally, with no Routing header. If 2647 the destination node is not a mobile node (or is a mobile node that 2648 is currently at home), the packet will be delivered directly to this 2649 node and processed normally by it. If, however, the destination node 2650 is a mobile node that is currently away from home, the packet will 2651 be intercepted by the mobile node's home agent and tunneled (using 2652 IPv6 encapsulation [4]) to the mobile node's current primary care-of 2653 address, as described in Section 9.6. The mobile node will then send 2654 a Binding Update to the sending node, as described in Section 10.8, 2655 allowing the sending node to create a Binding Cache entry for its use 2656 in sending subsequent packets to this mobile node. 2658 9. Home Agent Operation 2660 9.1. Receiving Router Advertisement Messages 2662 For each link on which a router provides service as a home agent, the 2663 router maintains a Home Agents List recording information about all 2664 other home agents on that link. This list is used in the dynamic 2665 home agent address discovery mechanism, described in Section 9.2. 2666 The information for the list is learned through receipt of the 2667 periodic unsolicited multicast Router Advertisements from each other 2668 home agent on the link, in which the Home Agent (H) bit is set, in a 2669 manner similar to the Default Router List conceptual data structure 2670 maintained by each host for Neighbor Discovery [17]. 2672 On receipt of a valid Router Advertisement, as defined in the 2673 processing algorithm specified for Neighbor Discovery [17], the home 2674 agent performs the following steps, in addition to any steps already 2675 required of it by Neighbor Discovery: 2677 - If the Home Agent (H) bit in the Router Advertisement is not set, 2678 skip all of the following steps. There are no special processing 2679 steps required by Mobile IP for this Router Advertisement, since 2680 the Advertisement was not sent by a home agent. 2682 - Otherwise, extract the Source Address from the IP header of the 2683 Router Advertisement. This is the link-local IP address on this 2684 link of the home agent sending this Advertisement [17]. 2686 - Determine from the Router Advertisement the preference for this 2687 home agent. If the Router Advertisement contains a Home Agent 2688 Information Option, then the preference is taken from the Home 2689 Agent Preference field in the option; otherwise, the default 2690 preference of 0 MUST be used. 2692 - Determine from the Router Advertisement the lifetime for 2693 this home agent. If the Router Advertisement contains a Home 2694 Agent Information Option, then the lifetime is taken from 2695 the Home Agent Lifetime field in the option; otherwise, the 2696 lifetime specified by the Router Lifetime field in the Router 2697 Advertisement SHOULD be used. 2699 - If the link-local address of the home agent sending this 2700 Advertisement is already present in this home agent's Home 2701 Agents List and the received home agent lifetime value is zero, 2702 immediately delete this entry in the Home Agents List. 2704 - Otherwise, if the link-local address of the home agent sending 2705 this Advertisement is already present in the receiving home 2706 agent's Home Agents List, reset its lifetime and preference to 2707 the values determined above. 2709 - If the link-local address of the home agent sending this 2710 Advertisement, as determined above, is not already present in 2711 the Home Agents List maintained by the receiving home agent, and 2712 the lifetime for the sending home agent, as determined above, 2713 is non-zero, create a new entry in the list, and initialize its 2714 lifetime and preference to the values determined above. 2716 - If the Home Agents List entry for the link-local address of 2717 the home agent sending this Advertisement was not deleted as 2718 described above, determine any global address(es) of the home 2719 agent based on each Prefix Information option received in 2720 this Advertisement in which the Router Address (R) bit is set 2721 (Section 6.2). For each such global address determined from this 2722 Advertisement, add this global address to the list of global 2723 addresses for this home agent in this Home Agents List entry. 2725 A home agent SHOULD maintain an entry in its Home Agents List for 2726 each such valid home agent address until that entry's lifetime 2727 expires, after which time the entry MUST be deleted. 2729 9.2. Dynamic Home Agent Address Discovery 2731 A mobile node, while away from home, MAY use the dynamic home agent 2732 address discovery mechanism to attempt to discover the address of 2733 one or more routers serving as home agents on its home link. This 2734 discovery may be necessary, for example, if some nodes on its home 2735 link have been reconfigured while the mobile node has been away from 2736 home, such that the router that was operating as the mobile node's 2737 home agent has been replaced by a different router serving this role. 2739 As described in Section 10.7, a mobile node attempts dynamic home 2740 agent address discovery by sending an ICMP Home Agent Address 2741 Discovery Request message to the "Mobile IPv6 Home-Agents" anycast 2742 address [10] for its home IP subnet prefix, using its care-of address 2743 as the Source Address of the packet. A home agent receiving such a 2744 Home Agent Address Discovery Request message that is serving this 2745 subnet (the home agent is configured with this anycast address on one 2746 of its network interfaces) SHOULD return an ICMP Home Agent Address 2747 Discovery Reply message to the mobile node (at its care-of address 2748 that was used as the Source Address of the Request message), with the 2749 Source Address of the Reply packet set to one of the global unicast 2750 addresses of the home agent. The Home Agent Addresses field in the 2751 Reply message is constructed as follows: 2753 - The Home Agent Addresses field SHOULD contain one global IP 2754 address for each home agent currently listed in this home 2755 agent's own Home Agents List (Section 4.6). However, if this 2756 home agent's own global IP address would be placed in the list 2757 (as described below) as the first entry in the list, then this 2758 home agent SHOULD NOT include its own address in the Home Agent 2759 Addresses field in the Reply message. Not placing this home 2760 agent's own IP address in the list will cause the receiving 2761 mobile node to consider this home agent as the most preferred 2762 home agent; otherwise, this home agent will be considered to be 2763 preferred in its order given by its place in the list returned. 2765 - The IP addresses in the Home Agent Addresses field SHOULD be 2766 listed in order of decreasing preference value, based either 2767 on the respective advertised preference from a Home Agent 2768 Information option or on the default preference of 0 if no 2769 preference is advertised (or on the configured home agent 2770 preference for this home agent itself). The home agent with 2771 the highest preference SHOULD be listed first in the Home Agent 2772 Addresses field, and the home agent with the lowest preference 2773 SHOULD be listed last. 2775 - Among home agents with equal preference, their IP addresses 2776 in the Home Agent Addresses field SHOULD be listed in an 2777 order randomized with respect to other home agents with equal 2778 preference, each time a Home Agent Address Discovery Reply 2779 message is returned by this home agent. 2781 - For each entry in this home agent's Home Agents List, if more 2782 than one global IP address is associated with this list entry, 2783 then one of these global IP addresses SHOULD be selected to 2784 include in the Home Agent Addresses field in the Reply message. 2785 As described in Section 4.6, one Home Agents List entry, 2786 identified by the home agent's link-local address, exists for 2787 each home agent on the link; associated with that list entry is 2788 one or more global IP addresses for this home agent, learned 2789 through Prefix Information options with the Router Address (R) 2790 bit is set, received in Router Advertisements from this 2791 link-local address. The selected global IP address for each home 2792 agent to include in forming the Home Agent Addresses field in the 2793 Reply message MUST be the global IP address of the respective 2794 home agent sharing a prefix with the mobile node's home address 2795 as indicated in the Home Address option in the Request message; 2796 if no such global IP address is known for some home agent, an 2797 entry for that home agent MUST NOT be included in the Home Agent 2798 Addresses field in the Reply message. 2800 - In order to avoid the possibility of the Reply message packet 2801 being fragmented (or rejected by an intermediate router with an 2802 ICMP Packet Too Big message [5]), if the resulting total packet 2803 size containing the complete list of home agents in the Home 2804 Agent Addresses field would exceed the minimum IPv6 MTU [6], the 2805 home agent SHOULD reduce the number of home agent IP addresses 2806 returned in the packet to the number of addresses that will fit 2807 without exceeding this limit. The home agent addresses returned 2808 in the packet SHOULD be those from the complete list with the 2809 highest preference. 2811 9.3. Primary Care-of Address Registration 2813 When a node receives a Binding Update, it MUST validate it and 2814 determine the type of Binding Update according to the steps described 2815 in Section 8.2. This section describes the processing of a valid 2816 Binding Update that requests the receiving node to serve as its home 2817 agent, registering its primary care-of address. 2819 To begin processing the Binding Update, the home agent MUST perform 2820 the following sequence of tests: 2822 - If the node is not a router that implements home agent 2823 functionality, then the node MUST reject the Binding Update and 2824 SHOULD return a Binding Acknowledgement to the mobile node, in 2825 which the Status field is set to 132 (home registration not 2826 supported). 2828 - Else, if the home address for the binding (the Home Address field 2829 in the packet's Home Address option) is not an on-link IPv6 2830 address with respect to the home agent's current Prefix List, 2831 then the home agent MUST reject the Binding Update and SHOULD 2832 return a Binding Acknowledgement to the mobile node, in which the 2833 Status field is set to 133 (not home subnet). 2835 - Else, if the Prefix Length field is nonzero in the Binding Update 2836 and this length differs from the length of the home agent's own 2837 knowledge of the corresponding subnet prefix on the home link, 2838 then the home agent MUST reject the Binding Update and SHOULD 2839 return a Binding Acknowledgement to the mobile node, in which the 2840 Status field is set to 136 (incorrect subnet prefix length). 2842 - Else, if the home agent chooses to reject the Binding Update for 2843 any other reason (e.g., insufficient resources to serve another 2844 mobile node as a home agent), then the home agent SHOULD return a 2845 Binding Acknowledgement to the mobile node, in which the Status 2846 field is set to an appropriate value to indicate the reason for 2847 the rejection. 2849 - Finally, if the Duplicate Address Detection (D) bit is set in 2850 the Binding Update, this home agent MUST perform Duplicate 2851 Address Detection [27] on the mobile node's home link for the 2852 home address in this binding (before returning the Binding 2853 Acknowledgement); if the Prefix Length field is nonzero in the 2854 Binding Update, the home agent MAY choose to perform Duplicate 2855 Address Detection for only one of the addresses formed from the 2856 interface identifier for this binding, and if so, the address 2857 used for Duplicate Address Detection SHOULD be the mobile 2858 node's link-local address. Normal processing for Duplicate 2859 Address Detection specifies that, in certain cases, the node 2860 SHOULD delay sending the initial Neighbor Solication message 2861 of Duplicate Address Detection by a random delay between 0 and 2862 MAX_RTR_SOLICITATION_DELAY [17, 27]; however, in this case, the 2863 home agent SHOULD NOT perform such a delay. If this Duplicate 2864 Address Detection fails, then the home agent MUST reject the 2865 Binding Update and SHOULD return a Binding Acknowledgement to the 2866 mobile node, in which the Status field is set to 138 (Duplicate 2867 Address Detection failed). 2869 If the home agent does not reject the Binding Update as described 2870 above, then it becomes the home agent for the mobile node. The new 2871 home agent (the receiving node) MUST then create a new entry in its 2872 Binding Cache for this mobile node (or update its existing Binding 2873 Cache entry for this mobile node, if such an entry already exists) 2874 The home address of the mobile node is taken to be the value which, 2875 when the packet was originally received, was located in the Home 2876 Address field in the packet's Home Address option. The care-of 2877 address for this Binding Cache entry is taken to be the value which, 2878 when the packet was originally received, was located either in the 2879 Alternate Care-of Address sub-option in the Binding Update option, 2880 if present, or from the Source Address field in the packet's IPv6 2881 header, otherwise. 2883 The home agent MUST mark this Binding Cache entry as a "home 2884 registration" to indicate that the node is serving as a home 2885 agent for this binding. Binding Cache entries marked as a "home 2886 registration" MUST be excluded from the normal cache replacement 2887 policy used for the Binding Cache (Section 8.7) and MUST NOT be 2888 removed from the Binding Cache until the expiration of the Lifetime 2889 period. 2891 In addition, the home agent MUST copy the Router (R) bit from the 2892 Binding Update into the corresponding bit in this Binding Cache entry 2893 for this mobile node. 2895 The lifetime for the Binding Cache entry MUST NOT be greater than 2896 the remaining valid lifetime for the subnet prefix in the mobile 2897 node's home address specified with the Binding Update, and MUST NOT 2898 be greater than the Lifetime value specified in the Binding Update. 2899 The remaining valid lifetime for this prefix is determined by the 2900 home agent based on its own Prefix List entry for this prefix [17]. 2901 Furthermore, if the Prefix Length field in the Binding Update is 2902 nonzero, then the lifetime for the Binding Cache entry MUST NOT be 2903 greater than the minimum remaining valid lifetime for all subnet 2904 prefixes on the mobile node's home link. If the value of the 2905 Lifetime field specified by the mobile node in its Binding Update is 2906 greater than this prefix lifetime, the home agent MUST decrease the 2907 binding lifetime to less than or equal to the prefix valid lifetime. 2908 The home agent MAY further decrease the specified lifetime for the 2909 binding, for example based on a local policy implemented by the home 2910 agent. The resulting lifetime is stored by the home agent in the 2911 Binding Cache entry, and this Binding Cache entry MUST be deleted by 2912 the home agent after the expiration of this lifetime. 2914 The Prefix Length in the Binding Update MUST also be saved in the 2915 Binding Cache entry. 2917 The home agent MUST return a Binding Acknowledgement to the mobile 2918 node, constructed as follows: 2920 - The Status field MUST be set to a value indicating success (the 2921 value MUST be less than 128). The only currently defined success 2922 Status value is 0, indicating simply that the Binding Update was 2923 accepted. 2925 - The Sequence Number field MUST be copied from the Sequence Number 2926 given in the Binding Update. 2928 - The Lifetime field MUST be set to the remaining lifetime for 2929 the binding as set by the home agent in its "home registration" 2930 Binding Cache entry for the mobile node. As described above, 2931 this lifetime MUST NOT be greater than the remaining valid 2932 lifetime for the subnet prefix in the mobile node's home address. 2934 - The Refresh field MUST be set to a value less than or equal to 2935 the Lifetime value being returned in the Binding Update. If the 2936 home agent stores the Binding Cache entry in nonvolatile storage 2937 (that survives the crash or other failure of the home agent), 2938 then the Refresh field SHOULD be set to the same value as the 2939 Lifetime field; otherwise, the home agent MAY set the Refresh 2940 field to a value less than the Lifetime field, to indicate that 2941 the mobile node SHOULD attempt to refresh its home registration 2942 at the indicated shorter interval (although the home agent will 2943 still retain the registration for the Lifetime period, even if 2944 the mobile node does not refresh its registration within the 2945 Refresh period). 2947 In addition, the home agent MUST follow the procedure defined in 2948 Section 9.5 to intercept packets on the mobile node's home link 2949 addressed to the mobile node, while the home agent is serving as the 2950 home agent for this mobile node. 2952 9.4. Primary Care-of Address De-registration 2954 When a node receives a Binding Update, it MUST validate it and 2955 determine the type of Binding Update according to the steps described 2956 in Section 8.2. This section describes the processing of a valid 2957 Binding Update that requests the receiving node to no longer serve as 2958 its home agent, de-registering its primary care-of address. 2960 To begin processing the Binding Update, the home agent MUST perform 2961 the following test: 2963 - If the receiving node has no entry in its Binding Cache for this 2964 mobile node that is marked as a "home registration", then this 2965 node MUST reject the Binding Update and SHOULD return a Binding 2966 Acknowledgement to the mobile node, in which the Status field is 2967 set to 137 (not home agent for this mobile node). 2969 If the home agent does not reject the Binding Update as described 2970 above, then it MUST delete any existing entry in its Binding Cache 2971 for this mobile node. 2973 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2974 be), then the home agent MUST return a Binding Acknowledgement to the 2975 mobile node, constructed as follows: 2977 - The Status field MUST be set to a value indicating success (the 2978 value MUST be less than 128). The only currently defined success 2979 Status value is 0, indicating simply that the Binding Update was 2980 accepted. 2982 - The Sequence Number field MUST be copied from the Sequence Number 2983 given in the Binding Update. 2985 - The Lifetime field MUST be set to zero. 2987 - The Refresh field MUST be set to zero. 2989 In addition, the home agent MUST stop intercepting packets on the 2990 mobile node's home link addressed to the mobile node (Section 9.5). 2992 9.5. Intercepting Packets for a Mobile Node 2994 While a node is serving as the home agent for mobile node (while the 2995 node has an entry in its Binding Cache for this mobile node that is 2996 marked as a "home registration"), this node MUST attempt to intercept 2997 packets on the mobile node's home link addressed to the mobile node, 2998 and MUST tunnel each intercepted packet to the mobile node using 2999 using IPv6 encapsulation [4]. 3001 In order to intercept such packets on the home link, when a node 3002 becomes the home agent for some mobile node (it did not already 3003 have a Binding Cache entry for this mobile node marked as a "home 3004 registration"), then the home agent MUST multicast onto the home link 3005 a "gratuitous" Neighbor Advertisement message [17] on behalf of the 3006 mobile node. Specifically, the home agent performs the following 3007 steps: 3009 - The home agent examines the value of the Prefix Length field 3010 in the new "home registration" Binding Cache entry. If this 3011 value is zero, the following step is carried out only for the 3012 individual home address specified for this binding. If, instead, 3013 this field is nonzero, then the following step is carried out 3014 for each address for the mobile node formed from the interface 3015 identifier in the mobile node's home address in this binding 3016 (the remaining low-order bits in the address after the indicated 3017 subnet prefix), together with each one of the subnet prefixes 3018 currently considered by the home agent to be on-link (including 3019 both the link-local and site-local prefix). 3021 - For each specific IP address for the mobile node determined 3022 in the first step above, the home agent multicasts onto the 3023 home link (to the all-nodes multicast address) a Neighbor 3024 Advertisement message [17] on behalf of the mobile node, to 3025 advertise the home agent's own link-layer address for this IP 3026 address. 3028 All fields in each such Neighbor Advertisement message SHOULD be 3029 set in the same way they would be set by the mobile node itself 3030 if sending this Neighbor Advertisement while at home [17], with 3031 the following exceptions: 3033 * The Target Address in the Neighbor Advertisement message MUST 3034 be set to the specific IP address for the mobile node. 3036 * The Advertisement MUST include a Target Link-layer Address 3037 option specifying the home agent's link-layer address. 3039 * The Router (R) bit in the Advertisement MUST be copied from 3040 the corresponding bit in the home agent's Binding Cache entry 3041 for the mobile node. 3043 * The Solicited Flag (S) in the Advertisement MUST NOT be set, 3044 since it was not solicited by any Neighbor Solicitation 3045 message. 3047 * The Override Flag (O) in the Advertisement MUST be set, 3048 indicating that the Advertisement SHOULD override any 3049 existing Neighbor Cache entry at any node receiving it. 3051 Any node on the home link receiving one of the Neighbor Advertisement 3052 messages described above will thus update its Neighbor Cache to 3053 associate the mobile node's address with the home agent's link 3054 layer address, causing it to transmit any future packets for the 3055 mobile node normally destined to this address instead to the mobile 3056 node's home agent. Since multicasts on the local link (such as 3057 Ethernet) are typically not guaranteed to be reliable, the home 3058 agent MAY retransmit this Neighbor Advertisement message up to 3059 MAX_ADVERT_REXMIT times to increase its reliability. It is still 3060 possible that some nodes on the home link will not receive any of 3061 these Neighbor Advertisements, but these nodes will eventually be 3062 able to detect the link-layer address change for the mobile node's 3063 home address, through use of Neighbor Unreachability Detection [17]. 3065 While a node is serving as a home agent for some mobile node (it 3066 still has a "home registration" entry for this mobile node in its 3067 Binding Cache), the home agent uses IPv6 Neighbor Discovery [17] 3068 to intercept unicast packets on the home link addressed the mobile 3069 node's home address. In order to intercept packets in this way, 3070 the home agent MUST act as a proxy for this mobile node to reply to 3071 any received Neighbor Solicitation messages for it. When a home 3072 agent receives a Neighbor Solicitation message, it MUST check if the 3073 Target Address specified in the message matches the home address 3074 of any mobile node for which it has a Binding Cache entry marked 3075 as a "home registration". This check MUST include all possible 3076 home addresses for the mobile node, based on the subnet prefixes 3077 currently considered to be on-link by the home agent (including the 3078 corresponding link-local address and site-local address), if the 3079 Prefix Length in the Binding Cache entry for this mobile node (from 3080 the Binding Update that created this Cache entry) is nonzero. 3082 If such an entry exists in the home agent's Binding Cache, the home 3083 agent MUST reply to the Neighbor Solicitation message with a Neighbor 3084 Advertisement message, giving the home agent's own link-layer address 3085 as the link-layer address for the specified Target Address. In 3086 addition, the Router (R) bit in the Advertisement MUST be copied from 3087 the corresponding bit in the home agent's Binding Cache entry for the 3088 mobile node. Acting as a proxy in this way allows other nodes on 3089 the mobile node's home link to resolve the mobile node's IPv6 home 3090 address, and allows the home agent to defend these addresses on the 3091 home link for Duplicate Address Detection [17]. 3093 9.6. Tunneling Intercepted Packets to a Mobile Node 3095 For any packet sent to a mobile node from the mobile node's home 3096 agent (for which the home agent is the original sender of the 3097 packet), the home agent is operating as a correspondent node of 3098 the mobile node for this packet and the procedures described in 3099 Section 8.9 apply. The home agent (as a correspondent node) uses a 3100 Routing header to route the packet to the mobile node by way of the 3101 care-of address in the home agent's Binding Cache (the mobile node's 3102 primary care-of address, in this case). 3104 While the mobile node is away from home and this node is acting 3105 as the mobile node's home agent, the home agent intercepts any 3106 packets on the home link addressed to the mobile node's home address 3107 (including addresses formed from other on-link prefixes, if the 3108 Prefix Length field was nonzero in the Binding Update), as described 3109 in Section 9.5. The home agent cannot use a Routing header to 3110 forward these intercepted packets to the mobile node, since it cannot 3111 modify the packet in flight without invalidating any existing IPv6 3112 AH [11] or ESP [12] header present in the packet. 3114 For forwarding each intercepted packet to the mobile node, the 3115 home agent MUST tunnel the packet to the mobile node using IPv6 3116 encapsulation [4]; the tunnel entry point node is the home agent, 3117 and the tunnel exit point node is the primary care-of address as 3118 registered with the home agent (which is an address of the mobile 3119 node itself). When a home agent encapsulates an intercepted packet 3120 for forwarding to the mobile node, the home agent sets the Source 3121 Address in the prepended tunnel IP header to the home agent's own IP 3122 address, and sets the Destination Address in the tunnel IP header 3123 to the mobile node's primary care-of address. When received by the 3124 mobile node (using its primary care-of address), normal processing of 3125 the tunnel header [4] will result in decapsulation and processing of 3126 the original packet by the mobile node. 3128 However, packets addressed to the mobile node's link-local address 3129 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 3130 be discarded, and the home agent SHOULD return an ICMP Destination 3131 Unreachable, Code 3, message to the packet's Source Address (unless 3132 this Source Address is a multicast address). Packets addressed to 3133 the mobile node's site-local address SHOULD be tunneled to the mobile 3134 node by default, but this behavior MUST be configurable to disable 3135 it; currently, the exact definition and semantics of a "site" and a 3136 site-local address are undefined in IPv6, and this default behavior 3137 might change at some point in the future. 3139 Tunneling of multicast packets to a mobile node follows similar 3140 limitations to those defined above for unicast packets addressed to 3141 the mobile node's link-local and site-local addresses. Multicast 3142 packets addressed to a multicast address with link-local scope [9], 3143 to which the mobile node is subscribed, MUST NOT be tunneled 3144 to the mobile node; such packets SHOULD be silently discarded 3145 (after delivering to other local multicast recipients). Multicast 3146 packets addressed to a multicast address with scope larger 3147 than link-local but smaller than global (e.g., site-local and 3148 organization-local) [9], to which the mobile node is subscribed, 3149 SHOULD be tunneled to the mobile node by default, but this behavior 3150 MUST be configurable to disable it; this default behavior might 3151 change at some point in the future as the definition of these scopes 3152 become better defined in IPv6. 3154 9.7. Handling Reverse Tunneled Packets from a Mobile Node 3156 A home agent MUST support decapsulating reverse tunneled packets 3157 sent to it from a mobile node. Such reverse tunneled packets MAY be 3158 discarded unless accompanied by a valid AH. This support for reverse 3159 tunneling allows mobile nodes to defeat certain kinds of traffic 3160 analysis. Requiring AH on reverse tunneled packets allows the home 3161 agent to protect the home network against unwarranted intrusions by 3162 malicious nodes masquerading as a mobile node with a home address on 3163 the network served by the home agent. 3165 9.8. Renumbering the Home Subnet 3167 IPv6 provides mechanisms through Neighbor Discovery [17] and Address 3168 Autoconfiguration [27] to aid in renumbering a subnet, such as when a 3169 site switches to a new network service provider. In renumbering, new 3170 prefixes and addresses can be introduced for the subnet and old ones 3171 can be deprecated and removed. These mechanisms are defined to work 3172 while all nodes using the old prefixes are at home, connected to the 3173 link using these prefixes. Mobile IPv6 extends these mechanisms for 3174 the case in which one or more mobile nodes using the old prefixes are 3175 away from home while the renumbering takes place. 3177 The IPv6 renumbering mechanisms are based on nodes on the link 3178 receiving Prefix Information options in Router Advertisement 3179 messages giving the valid lifetime and preferred lifetime for 3180 different prefixes on the link [17]. Mobile IPv6 arranges to 3181 tunnel certain Router Advertisements giving "important" Prefix 3182 Information options to mobile nodes while away from home. To avoid 3183 the need to tunnel all Router Advertisements from the home link to 3184 a mobile node away from home, those Router Advertisements that are 3185 tunneled to the mobile node are retransmitted until acknowledged. To 3186 avoid possible security attacks from forged Router Advertisements 3187 tunneled to the mobile node, all such tunneled Router Advertisements 3188 must be authenticated to the mobile node by its home agent using 3189 IPsec [13, 11, 12]. 3191 9.8.1. Building Aggregate List of Home Network Prefixes 3193 A mobile node on a remote network SHOULD autoconfigure the same 3194 set of home addresses it would autoconfigure if it were attached 3195 to the home network. To support this, the home agent monitors 3196 prefixes advertised by other routers on the home subnet and passes 3197 the aggregate list of home subnet prefixes on to the mobile node in 3198 Router Advertisements. 3200 The home agent SHOULD construct the aggregate list of home subnet 3201 prefixes as follows: 3203 - Copy prefix information defined in the home agent's AdvPrefixList 3204 on the home subnet's interfaces to the aggregate list. Also 3205 apply any changes made to the AdvPrefixList on the home agent to 3206 the aggregate list. 3208 - Check valid prefixes received in Router Advertisements 3209 from the home network for consistency with the home agent's 3210 AdvPrefixList, as specified in section 6.2.7 of RFC 2461 3211 (Neighbor Discovery [17]). Do not update the aggregate list with 3212 any information from received prefixes that fail this check. 3214 - Add valid prefixes received in Router Advertisements from the 3215 home network that are not yet in the aggregate list to the 3216 aggregate list along with the value of their L and A flags. 3217 Clear the R flag and zero the interface-id portion of the prefix 3218 field to prevent mobile nodes from treating another router's 3219 interface address as belonging to the home agent. Treat the 3220 lifetimes of these prefixes as "deprecating". 3222 - Do not perform consistency checks on valid prefixes received in 3223 Router Advertisements on the home network that do not exist in 3224 the home agent's AdvPrefixList. Instead, if the prefixes already 3225 exist in the aggregate list, update the prefix lifetime fields in 3226 the aggregate list according to the rules specified for hosts in 3227 section 6.3.4 of RFC 2461 (Neighbor Discovery [17]) and section 3228 5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [27]). 3230 - If the L or A flag is set on valid prefixes received in a Router 3231 Advertisement, and that prefix already exists in the aggregate 3232 list, set the corresponding flag in the aggregate list. Ignore 3233 the received L or A flag if it is clear. 3235 - Ignore the R flag and interface id portion of any prefix received 3236 in a Router Advertisement. 3238 - Delete prefixes from the aggregate list when their valid 3239 lifetimes expire. 3241 The home agent uses the information in the aggregate list to 3242 construct Router Advertisements, possibly including Binding 3243 Acknowledgement or Binding Request destination options, for delivery 3244 to a mobile node for which it is maintaining a current binding. 3246 9.8.2. Sending Changed Prefix Information to the Mobile Node 3248 A home agent serving some mobile node MUST schedule the delivery of 3249 new prefix information to the mobile node when any of the following 3250 conditions occur: 3252 - A valid or preferred lifetime of a prefix in the aggregate list 3253 of prefixes changes. 3255 - The state of the flags for a prefix in the aggregate list 3256 changes. 3258 - A new prefix is introduced on the home link. 3260 - The mobile node requests the information with a Router 3261 Solicitation (see section 10.16). 3263 The home agent determines these conditions based on its own 3264 configuration as a router and based on the Router Advertisements that 3265 it receives on the home link. 3267 The home agent uses the following algorithm to determine when to send 3268 prefix information to the mobile node. 3270 - If a mobile node sends a solicitation, answer with everything. 3272 - If a prefix changes state in a way that causes a mobile node's 3273 address to go deprecated, send an advertisement right away. 3275 - For any existing previx, if the mobile node's binding expires 3276 before the advertised Preferred Lifetime, do not schedule the 3277 advertisement. The mobile node will get the revised information 3278 in its next Binding Acknowledgement. 3280 - If a prefix is added, or if it changes in any way that does not 3281 cause the mobile node's address to go deprecated, ensure that a 3282 transmission is scheduled at time RAND_ADV_DELAY in the future. 3284 - If a prefix advertisement is scheduled, and a Binding Update 3285 arrives, perform that advertisement and include the information 3286 in a Router Advertisement that has the Binding Acknowledgement as 3287 a Destination Option. Remove the future scheduled advertisement. 3289 The home agent uses the following algorithm to compute 3290 RAND_ADV_DELAY, the offset from the current time for the 3291 scheduled transmission. 3293 If there is a transmission already scheduled, then 3295 if the current RAND_ADV_DELAY would cause another 3296 transmission BEFORE the Preferred Lifetime of the 3297 mobile node's home address derived from the prefix whose 3298 advertisement information has changed, then 3300 add the new information to be transmitted to the 3301 existing scheduled transmission -- return. 3303 otherwise, 3305 continue with the following computation, and add the 3306 data from the existing scheduled transmission to the 3307 newly scheduled transmission, deleting the previously 3308 scheduled transmission event. 3310 If the mobile node's binding expires after the Preferred Lifetime, 3311 then compute 3312 MAX_SCHEDULE_DELAY == 3313 min (MAX_PFX_ADV_DELAY, Preferred Lifetime) 3315 for the newly advertised Preferred Lifetime. 3316 Then compute RAND_ADV_DELAY = 3317 MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) 3319 9.8.3. Tunneling Router Advertisements to the Mobile Node 3321 When tunneling a Router Advertisement to the mobile node, the home 3322 agent MUST construct the packet as follows: 3324 - The Source Address in the packet's IPv6 header MUST be set to the 3325 home agent's IP address to which the mobile node addressed its 3326 current home registration. 3328 - The packet MUST be protected by IPsec [13, 11, 12] to guard 3329 against malicious Router Advertisements. The IPsec protection 3330 MUST provide sender authentication, data integrity protection, 3331 and replay protection, covering the Router Advertisement. 3333 - The packet MUST include a Binding Request destination option. 3335 - The Binding Request destination option MUST include a Unique 3336 Identifier Sub-Option (Section 5.5), with the unique identifier 3337 in the sub-option data set to a value different than that in 3338 any other Binding Request sent recently by this node. The word 3339 "recently" here means within the maximum likely lifetime of a 3340 packet, including transit time from source to destination and 3341 time spent awaiting reassembly with other fragments of the same 3342 packet, if fragmented. However, it is not required that a source 3343 node know the maximum packet lifetime. Rather, it is assumed 3344 that the requirement can be met by maintaining a simple 16-bit 3345 "wrap-around" counter to generate unique identifiers for Binding 3346 Requests that contain a Unique Identifier Sub-Option, incremented 3347 each time a Binding Request containing a Unique Identifier 3348 Sub-Option is sent. 3350 - The packet MUST be tunneled to the mobile node's primary care-of 3351 address using a Routing header, in the same way as any packet 3352 sent to the mobile node originated by the home agent (rather than 3353 using IPv6 encapsulation, as would be used by the home agent for 3354 intercepted packets). 3356 The home agent SHOULD periodically continue to retransmit this 3357 tunneled packet to the mobile node, until it is acknowledged by 3358 the receipt from the mobile node of a Binding Update matching 3359 the Binding Request in the packet (i.e., with matching Sequence 3360 Number). A Binding Update matches a Binding Request if it specifies 3361 a binding for the mobile node to which the Binding Request was sent 3362 and contains a Unique Identifier Sub-Option matching the unique 3363 identifier sent in the Unique Identifier Sub-Option in the Binding 3364 Request. 3366 If while the home agent is still retransmitting a Router 3367 Advertisement to the mobile node, another condition as described 3368 above occurs on the home link causing another Router Advertisement 3369 to be tunneled to the mobile node, the home agent SHOULD combine any 3370 Prefix Information options in the unacknowledged Router Advertisement 3371 into the new Router Advertisement and then begin retransmitting the 3372 new Router Advertisement rather than the old one. When tunneling 3373 a new Router Advertisement, even if it contains Prefix Information 3374 options sent previously in an unacknowledged tunneled Router 3375 Advertisement, the home agent MUST generate a new unique identifer 3376 for use in the Unique Identifier Sub-Option in the Binding Request 3377 tunneled with the new Router Advertisement. 3379 Whenever a mobile node has a valid binding on a network other than 3380 its home network, the home agent MUST tunnel a router advertisement 3381 with all prefixes in the aggregate list to the mobile node at least 3382 once per HomeRtrAdvInterval seconds, and upon receipt of a valid 3383 Router Solicitation from the mobile node. 3385 9.8.4. Lifetimes for Changed Prefixes 3387 In addition, as described in Section 9.3, the lifetime returned by a 3388 mobile node's home agent in its Binding Acknowledgement in response 3389 to registration of a new primary care-of address by the mobile node 3390 MUST be no greater than the remaining valid lifetime for the subnet 3391 prefix in the mobile node's home address. Furthermore, as described 3392 in Section 10.8, Binding Updates sent by the mobile node to other 3393 nodes MUST use a lifetime no greater than the remaining lifetime of 3394 its home registration of its primary care-of address. These limits 3395 on the binding lifetime serve to prohibit use of a mobile node's home 3396 address after it becomes invalid. The mobile node SHOULD further 3397 limit the lifetimes that it sends on any Binding Updates to be within 3398 the remaining preferred lifetime for the prefix in its home address. 3400 10. Mobile Node Operation 3402 10.1. Sending Packets While Away from Home 3404 While a mobile node is away from home, it continues to use its home 3405 address as well as also using one or more care-of addresses. When 3406 sending a packet while away from home, a mobile node MAY choose among 3407 these in selecting the address that it will use as the source of the 3408 packet, as follows: 3410 - From the point of view of protocol layers and applications above 3411 Mobile IP (e.g., transport protocols), the mobile node will 3412 generally use its home address as the source of the packet for 3413 most packets, even while away from home, since Mobile IP is 3414 designed to make mobility transparent to such software. Doing 3415 so also makes the node's mobility---and the fact that it is 3416 currently away from home---transparent to the correspondent nodes 3417 with which it communicates. For packets sent that are part of 3418 transport-level connections established while the mobile node 3419 was at home, the mobile node MUST use its home address in this 3420 way. Likewise, for packets sent that are part of transport-level 3421 connections that the mobile node may still be using after moving 3422 to a new location, the mobile node SHOULD use its home address 3423 in this way. When sending such packets, Mobile IP will modify 3424 the packet to move the home address into a Home Address option 3425 and will set the IPv6 header's Source Address field to one of 3426 the mobile node's care-of addresses; these modifications to 3427 the packet are then reversed in the node receiving the packet, 3428 restoring the mobile node's home address to be the packet's 3429 Source Address before processing by higher protocol layers and 3430 applications. 3432 - For short-term communication, particularly for communication that 3433 may easily be retried if it fails, the mobile node MAY choose 3434 to directly use one of its care-of addresses as the source of 3435 the packet, thus not requiring the use of a Home Address option 3436 in the packet. An example of this type of communication might 3437 be DNS queries sent by the mobile node [15, 16]. Using the 3438 mobile node's care-of address as the source for such queries will 3439 generally have a lower overhead than using the mobile node's 3440 home address, since no extra options need be used in either the 3441 query or its reply, and all packets can be routed normally, 3442 directly between their source and destination without relying 3443 on Mobile IP. If the mobile node has no particular knowledge 3444 that the communication being sent fits within this general type 3445 of communication, however, the mobile node SHOULD NOT use its 3446 care-of address as the source of the packet in this way. 3448 For packets sent by a mobile node while it is at home, no special 3449 Mobile IP processing is required for sending this packet. Likewise, 3450 if the mobile node uses any address other than its home address as 3451 the source of a packet sent while away from home (from the point of 3452 view of higher protocol layers or applications, as described above), 3453 no special Mobile IP processing is required for sending that packet. 3454 In each case, the packet is simply addressed and transmitted in the 3455 same way as any normal IPv6 packet. 3457 For each other packet sent by the mobile node (i.e., packets sent 3458 while away from home, using the mobile node's home address as 3459 the source, from the point of view of higher protocol layers and 3460 applications), special Mobile IP processing of the packet is required 3461 for the insertion of the Home Address option. Specifically: 3463 - Construct the packet using the mobile node's home address as the 3464 packet's Source Address, in the same way as if the mobile node 3465 were at home. This preserves the transparency of Mobile IP to 3466 higher protocol layers (e.g., to TCP). 3468 - Insert a Home Address option into the packet, with the Home 3469 Address field copied from the original value of the Source 3470 Address field in the packet. 3472 - Change the Source Address field in the packet's IPv6 header to 3473 one of the mobile node's care-of addresses. This will typically 3474 be the mobile node's current primary care-of address, but MUST 3475 be a care-of address with a subnet prefix that is on-link on the 3476 network interface on which the mobile node will transmit the 3477 packet. 3479 By using the care-of address as the Source Address in the IPv6 3480 header, with the mobile node's home address instead in the Home 3481 Address option, the packet will be able to safely pass through any 3482 router implementing ingress filtering [7]. 3484 10.2. Interaction with Outbound IPsec Processing 3486 This section sketches the interaction between outbound Mobile IP 3487 processing and outbound IP Security (IPsec) processing for 3488 packets sent by a mobile node while away from home. Any specific 3489 implementation MAY use algorithms and data structures other than 3490 those suggested here, but its processing MUST be consistent with the 3491 effect of the operation described here and with the relevant IPsec 3492 specifications. In the steps described below, it is assumed that 3493 IPsec is being used in transport mode [13] and that the mobile node 3494 is using its home address as the source for the packet (from the 3495 point of view of higher protocol layers or applications, as described 3496 in Section 10.1): 3498 - The packet is created by higher layer protocols and applications 3499 (e.g., by TCP) as if the mobile node were at home and Mobile IP 3500 were not being used. Mobile IP is transparent to such higher 3501 layers. 3503 - As part of outbound packet processing in IP, the packet is 3504 compared against the IPsec Security Policy Database (SPD) to 3505 determine what processing is required for the packet [13]. 3507 - As a special case for Mobile IP, if a Binding Update or 3508 Binding Acknowledgement is being included in the packet, IPsec 3509 authentication, integrity protection, and replay protection MUST 3510 be applied to the packet [13, 11, 12], as defined in Section 4.4. 3511 If the SPD check above has already indicated that authentication 3512 and replay protection are required, this processing is sufficient 3513 for the Mobile IP requirement that all packets containing Binding 3514 Updates or Binding Acknowledgements be authenticated and covered 3515 by replay protection. Otherwise, an implementation can force 3516 the required IPsec processing on this individual packet by, for 3517 example, creating a temporary SPD entry for the handling of this 3518 packet. 3520 - If IPsec processing is required, the packet is either mapped to 3521 an existing Security Association (or SA bundle), or a new SA (or 3522 SA bundle) is created for the packet, according to the procedures 3523 defined for IPsec. 3525 - Since the mobile node is away from home, the mobile node inserts 3526 a Home Address option into the packet, replacing the Source 3527 Address in the packet's IP header with a care-of address suitable 3528 for the link on which the packet is being sent, as described in 3529 Section 10.1. The Destination Options header in which the Home 3530 Address option is inserted MUST appear in the packet before the 3531 AH [11] (or ESP [12]) header, so that the Home Address option is 3532 processed by the destination node (and, possibly, intermediate 3533 routing nodes) before the AH or ESP header is processed. 3535 - If a Binding Update is being included in the packet, it is 3536 also added to a Destination Options header in the packet. The 3537 Destination Options header in which the Binding Update option is 3538 inserted MUST appear after the AH or ESP header. 3540 - Finally, once the packet is fully assembled, the necessary IPsec 3541 authentication (and encryption, if required) processing is 3542 performed on the packet, initializing the Authentication Data in 3543 the AH or ESP header. The authentication data MUST be calculated 3544 as if the following were true: 3546 * the IPv6 source address in the IPv6 header contains the 3547 mobile node's home address, 3549 * the Home Address field of the Home Address destination option 3550 (section 5.4) contains the new care-of address. 3552 This allows, but does not require, the receiver of the packet 3553 containing the Binding Update to exchange the two fields of the 3554 incoming packet, simplifying processing for all subsequent packet 3555 headers. The mechanics of implementation do not absolutely 3556 require such an exchange to occur; other implementation 3557 strategies may be more appropriate, as long as the result of the 3558 authentication calculation remain the same. 3560 In addition, when using any automated key management protocol [13] 3561 (such as IKE [8]) to create any new SA (or SA bundle) while away from 3562 home (whether due to the inclusion of a Binding Update or Binding 3563 Acknowledgement in an outgoing packet, or otherwise), a mobile node 3564 MUST take special care in its processing of the key management 3565 protocol. Otherwise, other nodes with which the mobile node 3566 must communicate as part of the automated key management protocol 3567 processing may be unable to correctly deliver packets to the mobile 3568 node if they and/or the mobile node's home agent do not then have a 3569 current Binding Cache entry for the mobile node. For the default 3570 case of using IKE as the automated key management protocol [8, 13], 3571 such problems can be avoided by the following requirements on the use 3572 of IKE by a mobile node while away from home: 3574 - The mobile node MUST use its care-of address as the Source 3575 Address of all packets it sends as part of the key management 3576 protocol (without use of Mobile IP for these packets, as 3577 suggested in Section 10.1). 3579 - In addition, for all security associations bound to the mobile 3580 node's home address, the mobile node MUST include an ISAKMP 3581 Identification Payload [14] in the IKE exchange, giving the 3582 mobile node's home address as the initiator of the Security 3583 Association [22]. 3585 10.3. Receiving Packets While Away from Home 3587 While away from home, a mobile node will receive packets addressed to 3588 its home address, by one of three methods: 3590 - Packets sent by a correspondent node that does not have a 3591 Binding Cache entry for the mobile node, will be sent by the 3592 correspondent node in the same way as any normal IP packet. Such 3593 packets will then be intercepted by the mobile node's home agent, 3594 encapsulated using IPv6 encapsulation [4], and tunneled to the 3595 mobile node's primary care-of address. 3597 - Packets sent by a correspondent node that has a Binding Cache 3598 entry for the mobile node that contains the mobile node's current 3599 care-of address, will be sent by the correspondent node using 3600 a Routing header. The packet will be addressed to the mobile 3601 node's care-of address, with the final hop in the Routing header 3602 directing the packet to the mobile node's home address; the 3603 processing of this last hop of the Routing header is entirely 3604 internal to the mobile node, since the care-of address and home 3605 address are both addresses within the mobile node. 3607 - Packets sent by a correspondent node that has a Binding Cache 3608 entry for the mobile node that contains an out-of-date care-of 3609 address for the mobile node, will be sent by the correspondent 3610 node using a Routing header, as described above. If the mobile 3611 node sent a Binding Update to a home agent on the link on which 3612 its previous care-of address is located (Section 10.9), and 3613 if this home agent is still serving as a home agent for the 3614 mobile node's previous care-of address, then such a packet will 3615 be intercepted by this home agent, encapsulated using IPv6 3616 encapsulation [4], and tunneled to the mobile node's new care-of 3617 address (registered with this home agent). 3619 For packets received by either the first or last of these three 3620 methods, the mobile node SHOULD send a Binding Update to the original 3621 sender of the packet, as described in Section 10.8, subject to the 3622 rate limiting defined in Section 10.11. The mobile node SHOULD 3623 also process the received packet in the manner defined for IPv6 3624 encapsulation [4], which will result in the encapsulated (inner) 3625 packet being processed normally by upper-layer protocols within the 3626 mobile node, as if it had been addressed (only) to the mobile node's 3627 home address. 3629 For packets received by the second method above (using a Routing 3630 header), the mobile node SHOULD process the received packet in the 3631 manner defined for the type of IPv6 Routing header used [6], which 3632 will result in the packet being processed normally by upper-layer 3633 protocols within the mobile node, as if it had been addressed (only) 3634 to the mobile node's home address. 3636 In addition, the general procedures defined by IPv6 for Routing 3637 headers suggest that a received Routing header MAY be automatically 3638 "reversed" to construct a Routing header for use in any response 3639 packets sent by upper-layer protocols, if the received packet is 3640 authenticated [6]. If this is done for upper-layer protocol response 3641 packets sent by a mobile node while away from home, the mobile 3642 node SHOULD NOT include its own care-of address, which appears in 3643 the Routing header of the received packet, in the reversed route 3644 for the response packet. If the received Routing header contained 3645 no additional hops (other than the mobile node's home address and 3646 care-of address), then any upper-layer protocol response packet 3647 SHOULD NOT include a Routing header. 3649 10.4. Movement Detection 3651 A mobile node MAY use any combination of mechanisms available to it 3652 to detect when it has moved from one link to another. The primary 3653 movement detection mechanism for Mobile IPv6 defined here uses the 3654 facilities of IPv6 Neighbor Discovery, including Router Discovery 3655 and Neighbor Unreachability Detection, although the mobile node MAY 3656 supplement this mechanism with other information available to the 3657 mobile node (e.g., from lower protocol layers). The description 3658 here is based on the conceptual model of the organization and data 3659 structures defined by Neighbor Discovery [17]. 3661 Mobile nodes SHOULD use Router Discovery to discover new routers and 3662 on-link subnet prefixes; a mobile node MAY send Router Solicitation 3663 messages, or MAY wait for unsolicited (periodic) multicast Router 3664 Advertisement messages, as specified for Router Discovery [17]. 3665 Based on received Router Advertisement messages, a mobile node (in 3666 the same way as any other node) maintains an entry in its Default 3667 Router List for each router, and an entry in its Prefix List for each 3668 subnet prefix, that it currently considers to be on-link. Each entry 3669 in these lists has an associated invalidation timer value (extracted 3670 from the Router Advertisement and Prefix Information options) used to 3671 expire the entry when it becomes invalid. 3673 While away from home, a mobile node SHOULD select one router from 3674 its Default Router List to use as its default router, and one subnet 3675 prefix advertised by that router from its Prefix List to use as 3676 the subnet prefix in its primary care-of address. A mobile node 3677 MAY also have associated additional care-of addresses, using other 3678 subnet prefixes from its Prefix List. The method by which a mobile 3679 node selects and forms a care-of address from the available subnet 3680 prefixes is described in Section 10.5. The mobile node registers 3681 its primary care-of address with its home agent, as described in 3682 Section 10.6. 3684 While a mobile node is away from home and using some router as its 3685 default router, it is important for the mobile node to be able to 3686 quickly detect when that router becomes unreachable, so that it can 3687 switch to a new default router and to a new primary care-of address. 3688 Since some links (notably wireless) do not necessarily work equally 3689 well in both directions, it is likewise important for the mobile 3690 node to detect when it becomes unreachable for packets sent from its 3691 default router, so that the mobile node can take steps to ensure that 3692 any correspondent nodes attempting to communicate with it can still 3693 reach it through some other route. 3695 To detect when its default router becomes unreachable, a mobile 3696 node SHOULD use Neighbor Unreachability Detection. As specified in 3697 Neighbor Discovery [17], while the mobile node is actively sending 3698 packets to (or through) its default router, the mobile node can 3699 detect that the router (as its neighbor) is still reachable either 3700 through indications from upper layer protocols on the mobile node 3701 that a connection is making "forward progress" (e.g., receipt of TCP 3702 acknowledgements for new data transmitted), or through receipt of a 3703 Neighbor Advertisement message from its default router in response 3704 to an explicit Neighbor Solicitation messages to it. Note that 3705 although this mechanism detects that the mobile node's default router 3706 has become unreachable to the mobile node only while the mobile node 3707 is actively sending packets to it, this is the only time that this 3708 direction of reachability confirmation is needed. Confirmation 3709 that the mobile node is still reachable from the router is handled 3710 separately, as described below. 3712 For a mobile node to detect when it has become unreachable from its 3713 default router, the mobile node cannot efficiently rely on Neighbor 3714 Unreachability Detection alone, since the network overhead would be 3715 prohibitively high in many cases for a mobile node to continually 3716 probe its default router with Neighbor Solicitation messages even 3717 when it is not otherwise actively sending packets to it. Instead, 3718 a mobile node SHOULD consider receipt of any IPv6 packets from its 3719 current default router as an indication that it is still reachable 3720 from the router. Both packets from the router's IP address and 3721 (IPv6) packets from its link-layer address (e.g., those forwarded but 3722 not originated by the router) SHOULD be considered. 3724 Since the router SHOULD be sending periodic unsolicited multicast 3725 Router Advertisement messages, the mobile node will have frequent 3726 opportunity to check if it is still reachable from its default 3727 router, even in the absence of other packets to it from the router. 3728 If Router Advertisements that the mobile node receives include 3729 an Advertisement Interval option, the mobile node MAY use its 3730 Advertisement Interval field as an indication of the frequency with 3731 which it SHOULD expect to continue to receive future Advertisements 3732 from that router. This field specifies the minimum rate (the maximum 3733 amount of time between successive Advertisements) that the mobile 3734 node SHOULD expect. If this amount of time elapses without the 3735 mobile node receiving any Advertisement from this router, the mobile 3736 node can be sure that at least one Advertisement sent by the router 3737 has been lost. It is thus possible for the mobile node to implement 3738 its own policy for determining the number of Advertisements from 3739 its current default router it is willing to tolerate losing before 3740 deciding to switch to a different router from which it may currently 3741 be correctly receiving Advertisements. 3743 On some types of network interfaces, the mobile node MAY also 3744 supplement this monitoring of Router Advertisements, by setting its 3745 network interface into "promiscuous" receive mode, so that it is able 3746 to receive all packets on the link, including those not link-level 3747 addressed to it (i.e., disabling link-level address filtering). The 3748 mobile node will then be able to detect any packets sent by the 3749 router, in order to detect reachability from the router. This use of 3750 promiscuous mode may be useful on very low bandwidth (e.g., wireless) 3751 links, but its use MUST be configurable on the mobile node. 3753 If the above means do not provide indication that the mobile node is 3754 still reachable from its current default router (i.e., the mobile 3755 node receives no packets from the router for a period of time), then 3756 the mobile node SHOULD attempt to actively probe the router with 3757 Neighbor Solicitation messages, even if it is not otherwise actively 3758 sending packets to the router. If it receives a solicited Neighbor 3759 Advertisement message in response from the router, then the mobile 3760 node can deduce that it is still reachable. It is expected that the 3761 mobile node will in most cases be able to determine its reachability 3762 from the router by listening for packets from the router as described 3763 above, and thus, such extra Neighbor Solicitation probes should 3764 rarely be necessary. 3766 With some types of networks, it is possible that additional 3767 indications about link-layer mobility can be obtained from 3768 lower-layer protocol or device driver software within the mobile 3769 node. However, a mobile node MUST NOT assume that all link-layer 3770 mobility indications from lower layers indicate a movement of the 3771 mobile node to a new link, such that the mobile node would need to 3772 switch to a new default router and primary care-of address. For 3773 example, movement of a mobile node from one cell to another in many 3774 wireless LANs can be made transparent to the IP level through use of 3775 a link-layer "roaming" protocol, as long as the different wireless 3776 LAN cells all operate as part of the same IP link with the same 3777 subnet prefix. Upon lower-layer indication of link-layer mobility, 3778 the mobile node MAY send Router Solicitation messages to determine if 3779 new routers (and new on-link subnet prefixes) are present on its new 3780 link. 3782 Such lower-layer information might also be useful to a mobile node in 3783 deciding to switch its primary care-of address to one of the other 3784 care-of addresses it has formed from the on-link subnet prefixes 3785 currently available through different routers from which the mobile 3786 node is reachable. For example, a mobile node MAY use signal 3787 strength or signal quality information (with suitable hysteresis) for 3788 its link with the available routers to decide when to switch to a new 3789 primary care-of address using that router rather than its current 3790 default router (and current primary care-of address). Even though 3791 the mobile node's current default router may still be reachable in 3792 terms of Neighbor Unreachability Detection, the mobile node MAY use 3793 such lower-layer information to determine that switching to a new 3794 default router would provide a better connection. 3796 10.5. Forming New Care-of Addresses 3798 After detecting that it has moved from one link to another (i.e., its 3799 current default router has become unreachable and it has discovered 3800 a new default router), a mobile node SHOULD form a new primary 3801 care-of address using one of the on-link subnet prefixes advertised 3802 by the new router. A mobile node MAY form a new primary care-of 3803 address at any time, except that it MUST NOT do so too frequently. 3804 Specifically, a mobile node MUST NOT send a Binding Update about a 3805 new care-of address to its home agent (which is required to register 3806 the new address as its primary care-of address) more often than once 3807 per MAX_UPDATE_RATE seconds. 3809 In addition, after discovering a new on-link subnet prefix, a mobile 3810 node MAY form a new (non-primary) care-of address using that subnet 3811 prefix, even when it has not switched to a new default router. A 3812 mobile node can have only one primary care-of address at a time 3813 (which is registered with its home agent), but it MAY have an 3814 additional care-of address for any or all of the prefixes on its 3815 current link. Furthermore, since a wireless network interface may 3816 actually allow a mobile node to be reachable on more than one link at 3817 a time (i.e., within wireless transmitter range of routers on more 3818 than one separate link), a mobile node MAY have care-of addresses 3819 on more than one link at a time. The use of more than one care-of 3820 address at a time is described in Section 10.18. 3822 As described in Section 4, in order to form a new care-of address, 3823 a mobile node MAY use either stateless [27] or stateful (e.g., 3824 DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to 3825 send packets as part of the method of address autoconfiguration, 3826 it MUST use an IPv6 link-local address rather than its own IPv6 3827 home address as the Source Address in the IPv6 header of each such 3828 autoconfiguration packet. 3830 In some cases, a mobile node may already know a (constant) IPv6 3831 address that has been assigned to it for its use only while 3832 visiting a specific foreign link. For example, a mobile node may be 3833 statically configured with an IPv6 address assigned by the system 3834 administrator of some foreign link, for its use while visiting that 3835 link. If so, rather than using Address Autoconfiguration to form a 3836 new care-of address using this subnet prefix, the mobile node MAY use 3837 its own pre-assigned address as its care-of address on this link. 3839 After forming a new care-of address, a mobile node MAY perform 3840 Duplicate Address Detection [27] on that new address to confirm its 3841 uniqueness. However, doing so represents a tradeoff between safety 3842 (ensuring that the new address is not used if it is a duplicate 3843 address) and overhead (performing Duplicate Address Detection 3844 requires the sending of one or more additional packets over what 3845 may be, for example, a slow wireless link through which the mobile 3846 node is connected). Performing Duplicate Address Detection also in 3847 general would cause a delay before the mobile node could use the 3848 new care-of address, possibly causing the mobile node to be unable 3849 to continue communication with correspondent nodes for some period 3850 of time. For these reasons, a mobile node, after forming a new 3851 care-of address, MAY begin using the new care-of address without 3852 performing Duplicate Address Detection. Furthermore, the mobile node 3853 MAY continue using the address without performing Duplicate Address 3854 Detection, although it SHOULD in most cases (e.g., unless network 3855 bandwidth or battery consumption for communication is of primary 3856 concern) begin Duplicate Address Detection asynchronously when it 3857 begins use of the address, allowing the Duplicate Address Detection 3858 procedure to complete in parallel with normal communication using the 3859 address. 3861 In addition, normal processing for Duplicate Address Detection 3862 specifies that, in certain cases, the node SHOULD delay sending the 3863 initial Neighbor Solication message of Duplicate Address Detection 3864 by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27]; 3865 however, in this case, the mobile node SHOULD NOT perform such a 3866 delay in its use of Duplicate Address Detection, unless the mobile 3867 node is intializing after rebooting. 3869 10.6. Sending Binding Updates to the Home Agent 3871 After deciding to change its primary care-of address as described 3872 in Sections 10.4 and 10.5, a mobile node MUST register this care-of 3873 address with its home agent in order to make this its primary care-of 3874 address. To do so, the mobile node sends a packet to its home agent 3875 containing a Binding Update option, with the packet constructed as 3876 follows: 3878 - The Home Registration (H) bit MUST be set in the Binding Update. 3880 - The Acknowledge (A) bit MUST be set in the Binding Update. 3882 - The packet MUST contain a Home Address option, giving the mobile 3883 node's home address for the binding. 3885 - The care-of address for the binding MUST be used as the Source 3886 Address in the packet's IPv6 header, unless an Alternate Care-of 3887 Address sub-option is included in the Binding Update option. 3889 - The Prefix Length field SHOULD be set to the length of the mobile 3890 node's subnet prefix in its home address, to request the mobile 3891 node's home agent to serve as a home agent for all home addresses 3892 for the mobile node based on all on-link subnet prefixes on the 3893 home link. Otherwise, this field MUST be set to zero. 3895 - The value specified in the Lifetime field SHOULD be less than 3896 or equal to the remaining lifetime of the home address and the 3897 care-of address specified for the binding. 3899 The Acknowledge (A) bit in the Binding Update requests the home 3900 agent to return a Binding Acknowledgement in response to this 3901 Binding Update. As described in Section 5.2, the mobile node SHOULD 3902 retransmit this Binding Update to its home agent until it receives 3903 a matching Binding Acknowledgement. Once reaching a retransmission 3904 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 3905 continue to periodically retransmit the Binding Update at this rate 3906 until acknowledged (or until it begins attempting to register a 3907 different primary care-of address). 3909 The Prefix Length field in the Binding Update allows the mobile node 3910 to request its home agent to serve all home addresses for the mobile 3911 node, as indicated by the interface identifier in the mobile node's 3912 home address (the remaining low-order bits after the indicated subnet 3913 prefix), together with each on-link subnet prefix on the home link. 3914 Until the lifetime of this registration expires, the home agent 3915 considers itself the home agent for each such home address of the 3916 mobile node. As the set of on-link subnet prefixes on the home link 3917 changes over time, the home agent changes the set of home addresses 3918 for this mobile node for which it is serving as the home agent. 3920 When sending a Binding Update to its home agent, the mobile node MUST 3921 also create or update the corresponding Binding Update List entry, as 3922 specified in Section 10.8. 3924 If the mobile node has additional home addresses using a different 3925 interface identifier, then the mobile node SHOULD send an additional 3926 packet containing a Binding Update to its home agent to register the 3927 care-of address for each such other home address (or set of home 3928 addresses sharing an interface identifier). These additional Binding 3929 Updates MUST each be sent as a separate packet, since each MUST be 3930 protected by IPsec [13, 11, 12] to authenticate the Binding Update as 3931 coming from the home address being bound, as defined in Section 4.4. 3933 While the mobile node is away from home, it relies on the home agent 3934 to participate in Duplicate Address Detection (DAD) to defend its 3935 home address against stateless autoconfiguration performed by another 3936 node. Therefore, the mobile node SHOULD set the Duplicate Address 3937 Detection (D) bit based on any requirements for DAD Detection that 3938 would apply to the mobile node if it were at home [17, 27]. 3940 The home agent will only perform DAD for the mobile node's home 3941 address when the mobile node has supplied a valid binding between 3942 its home address and a care-of address. If some time elapses during 3943 which the mobile node has no binding at the home agent, it might be 3944 possible for another node to autoconfigure the mobile node's home 3945 address. Therefore, the mobile node MUST treat creation of a new 3946 binding with the home agent using an existing home address the same 3947 as creation of a new home address. In the unlikely event that the 3948 mobile node's home address is autoconfigured as the IPv6 address 3949 of another network node on the home network, the home agent will 3950 reply to the mobile node's subsequent Binding Update with a Binding 3951 Acknowledgement showing Status 138, Duplicate Address Detection 3952 failed. See section 10.10 for information about retransmitting 3953 Binding Updates. 3955 10.7. Dynamic Home Agent Address Discovery 3957 It is possible that when the mobile node needs to send a Binding 3958 Update to its home agent to register its new primary care-of address, 3959 as described in Section 10.6, the mobile node may not know the 3960 address of any router on its home link that can serve as a home agent 3961 for it. For example, some nodes on its home link may have been 3962 reconfigured while the mobile node has been away from home, such that 3963 the router that was operating as the mobile node's home agent has 3964 been replaced by a different router serving this role. 3966 In this case, the mobile node MAY use the dynamic home agent address 3967 discovery mechanism to find the address of a suitable home agent on 3968 its home link. To do so, the mobile node sends an ICMP Home Agent 3969 Address Discovery Request message to the "Mobile IPv6 Home-Agents" 3970 anycast address [10] for its home subnet prefix. This packet MUST 3971 NOT contain a Home Address option and must be sent using the mobile 3972 node's care-of address as the Source Address in the packet's IP 3973 header (the packet is sent from the care-of address, not using 3974 Mobile IP). As described in Section 9.2, the home agent on its home 3975 link that receives this Request message will return an ICMP Home 3976 Agent Address Discovery Reply message, giving this home agent's own 3977 global unicast IP address along with a list of the global unicast IP 3978 address of each other home agent operating on the home link. 3980 The mobile node, upon receiving this Home Agent Address Discovery 3981 Reply message, MAY then send its home registration Binding Update to 3982 the home agent address given as the IP Source Address of the packet 3983 carrying the Reply message or to any of the unicast IP addresses 3984 listed in the Home Agent Addresses field in the Reply. For example, 3985 if necessary, the mobile node MAY attempt its home registration 3986 with each of these home agents, in turn, by sending each a Binding 3987 Update and waiting for the matching Binding Acknowledgement, until 3988 its registration is accepted by one of these home agents. In trying 3989 each of the returned home agent addresses, the mobile node SHOULD try 3990 each in the order listed in the Home Agent Addresses field in the 3991 received Home Agent Address Discovery Reply message. If the home 3992 agent identified by the Source Address field in the IP header of the 3993 packet carrying the Home Agent Address Discovery Reply message is 3994 not listed in the Home Agent Addresses field in the Reply, it SHOULD 3995 be tried before the first address given in the list; otherwise, it 3996 SHOULD be tried in its listed order. 3998 If the mobile node has a current registration with some home agent 3999 on its home link (the Lifetime for that registration has not yet 4000 expired), then the mobile node MUST attempt any new registration 4001 first with that home agent. If that registration attempt fails 4002 (e.g., times out or is rejected), the mobile node SHOULD then 4003 reattempt this registration with another home agent on its home link. 4004 If the mobile node knows of no other suitable home agent, then it MAY 4005 attempt the dynamic home agent address discovery mechanism described 4006 above. 4008 10.8. Sending Binding Updates to Correspondent Nodes 4010 A mobile node MAY send a Binding Update to any correspondent node at 4011 any time to allow the correspondent node to cache the mobile node's 4012 current care-of address (subject to the rate limiting defined in 4013 Section 10.11). In any Binding Update sent by a mobile node, the 4014 care-of address (either the Source Address in the packet's IPv6 4015 header or the Care-of Address field in the Binding Update) MUST be 4016 set to one of the care-of addresses currently in use by the mobile 4017 node or to the mobile node's home address. 4019 If set to one of the mobile node's current care-of addresses (the 4020 care-of address given MAY differ from the mobile node's primary 4021 care-of address), the Binding Update requests the correspondent node 4022 to create or update an entry for the mobile node in the correspondent 4023 node's Binding Cache to record this care-of address for use in 4024 sending future packets to the mobile node. In this case, the value 4025 specified in the Lifetime field sent in the Binding Update SHOULD be 4026 less than or equal to the remaining lifetime of the home address and 4027 the care-of address specified for the binding. 4029 If, instead, the care-of address is set to the mobile node's home 4030 address, the Binding Update requests the correspondent node to delete 4031 any existing Binding Cache entry that it has for the mobile node. 4032 A mobile node MAY set the care-of address differently for sending 4033 Binding Updates to different correspondent nodes. 4035 When sending any Binding Update, the mobile node MUST record in its 4036 Binding Update List the following fields from the Binding Update: 4038 - The IP address of the node to which the Binding Update was sent. 4040 - The home address for which the Binding Update was sent (the value 4041 in the Home Address option in the packet carrying the Binding 4042 Update). 4044 - The initial lifetime of the binding, initialized from the 4045 Lifetime field sent in the Binding Update. 4047 - The remaining lifetime of the binding, also initialized from 4048 the Lifetime field sent in the Binding Update. This remaining 4049 lifetime value counts down and may also be reduced when the 4050 matching Binding Acknowledgement is received, based on the 4051 Lifetime value specified in that Binding Acknowledgement, as 4052 described in Section 10.12. When the remaining lifetime reaches 4053 zero, the Binding Update List entry MUST be deleted. 4055 The mobile node MUST retain in its Binding Update List information 4056 about all Binding Updates sent, for which the lifetime of the binding 4057 has not yet expired. However, when sending a Binding Update, if an 4058 entry already exists in the mobile node's Binding Update List for 4059 an earlier Binding Update sent to that same destination node, the 4060 existing Binding Update List entry is updated to reflect the new 4061 Binding Update rather than creating a new Binding Update List entry. 4063 In general, when a mobile node sends a Binding Update to its home 4064 agent to register a new primary care-of address (as described in 4065 Section 10.6), the mobile node will also send a Binding Update to 4066 each other node for which an entry exists in the mobile node's 4067 Binding Update List. Thus, other relevant nodes are generally kept 4068 updated about the mobile node's binding and can send packets directly 4069 to the mobile node using the mobile node's current care-of address. 4071 The mobile node, however, need not send these Binding Updates 4072 immediately after configuring a new care-of address. For example, 4073 since the Binding Update is a destination option and can be included 4074 in any packet sent by a mobile node, the mobile node MAY delay 4075 sending a new Binding Update to any correspondent node for a 4076 short period of time, in hopes that the needed Binding Update 4077 can be included in some packet that the mobile node sends to that 4078 correspondent node for some other reason (for example, as part of 4079 some TCP connection in use). In this case, when sending a packet 4080 to some correspondent node, the mobile node SHOULD check in its 4081 Binding Update List to determine if a new Binding Update to this 4082 correspondent node is needed, and SHOULD include the new Binding 4083 Update in this packet as necessary. 4085 In addition, when a mobile node receives a packet for which the 4086 mobile node can deduce that the original sender of the packet has 4087 no Binding Cache entry for the mobile node, or for which the mobile 4088 node can deduce that the original sender of the packet has an 4089 out-of-date care-of address for the mobile node in its Binding Cache, 4090 the mobile node SHOULD return a Binding Update to the sender giving 4091 its current care-of address (subject to the rate limiting defined 4092 in Section 10.11). In particular, the mobile node SHOULD return a 4093 Binding Update in response to receiving a packet that meets all of 4094 the following tests: 4096 - The packet was tunneled using IPv6 encapsulation. 4098 - The Destination Address in the tunnel (outer) IPv6 header is 4099 equal to any of the mobile node's care-of addresses. 4101 - The Destination Address in the original (inner) IPv6 header 4102 is equal to one of the mobile node's home addresses; or this 4103 Destination Address is equal to one of the mobile node's previous 4104 care-of addresses for which the mobile node has an entry in its 4105 Binding Update List, representing an unexpired Binding Update 4106 sent to a home agent on the link on which its previous care-of 4107 address is located (Section 10.9). 4109 - The Source Address in the tunnel (outer) IPv6 header differs from 4110 the Source Address in the original (inner) IPv6 header. 4112 The destination address to which the Binding Update should be sent 4113 in response to receiving a packet meeting all of the above tests is 4114 the Source Address in the original (inner) IPv6 header of the packet. 4115 The home address for which this Binding Update is sent should be the 4116 Destination Address of the original (inner) packet. 4118 Binding Updates sent to correspondent nodes are not generally 4119 required to be acknowledged. However, if the mobile node wants 4120 to be sure that its new care-of address has been entered into a 4121 correspondent node's Binding Cache, the mobile node MAY request an 4122 acknowledgement by setting the Acknowledge (A) bit in the Binding 4123 Update. In this case, however, the mobile node SHOULD NOT continue 4124 to retransmit the Binding Update once the retransmission timeout 4125 period has reached MAX_BINDACK_TIMEOUT. 4127 A mobile node MAY choose to keep its location private from certain 4128 correspondent nodes, and thus need not send new Binding Updates to 4129 those correspondents. A mobile node MAY also send a Binding Update 4130 to such a correspondent node to instruct it to delete any existing 4131 binding for the mobile node from its Binding Cache, as described in 4132 Section 5.1. No other IPv6 nodes are authorized to send Binding 4133 Updates on behalf of a mobile node. 4135 10.9. Establishing Forwarding from a Previous Care-of Address 4137 When a mobile node connects to a new link and forms a new care-of 4138 address, it MAY establish forwarding of packets from a previous 4139 care-of address to this new care-of address. To do so, the mobile 4140 node sends a Binding Update to any home agent on the link on which 4141 the previous care-of address is located, indicating this previous 4142 care-of address as the home address for the binding, and giving its 4143 new care-of address as the binding's care-of address. Such packet 4144 forwarding allows packets destined to the mobile node from nodes that 4145 have not yet learned the mobile node's new care-of address, to be 4146 forwarded to the mobile node rather than being lost once the mobile 4147 node is no longer reachable at this previous care-of address. 4149 In constructing this Binding Update, the mobile node utilizes the 4150 following specific steps: 4152 - The Home Address field in the Home Address option in the packet 4153 carrying the Binding Update MUST be set to the previous care-of 4154 address for which packet forwarding is being established. 4156 - The care-of address for the new binding MUST be set to the new 4157 care-of address to which packets destined to the previous care-of 4158 address are to be forwarded. Normally, this care-of address for 4159 the binding is specified by setting the Source Address of the 4160 packet carrying the Binding Update, to this address. However, 4161 the mobile node MAY instead include an Alternate Care-of Address 4162 sub-option in the Binding Update option, with its Alternate 4163 Care-of Address field set to the care-of address for the binding. 4165 - The Home Registration (H) bit MUST also be set in this Binding 4166 Update, to request this home agent to temporarily act as a home 4167 agent for this previous care-of address. 4169 This home agent will thus tunnel packets for the mobile node (packets 4170 destined to its specified previous care-of address) to its new 4171 care-of address. All of the procedures defined for home agent 4172 operation MUST be followed by this home agent for this registration. 4173 Note that this home agent does not necessarily know (and need not 4174 know) the mobile node's (permanent) home address as part of this 4175 registration. 4177 The packet carrying the Binding Update MUST be addressed to 4178 this home agent's global unicast address. Normally, this global 4179 unicast address is learned by the mobile node based on the Router 4180 Advertisements received by the mobile node (Section 6.2) while 4181 attached to the link on which this previous care-of address and this 4182 home agent are located; the mobile node obtains this home agent 4183 address from its Home Agents List (Section 4.6). Alternatively, 4184 the mobile node MAY use dynamic home agent address discovery 4185 (Section 10.7) to discover the global unicast address of a home agent 4186 on this previous link, but it SHOULD use an address from its Home 4187 Agents List if available for the prefix it used to form this previous 4188 care-of address. 4190 As with any packet containing a Binding Update (see section 5.1), 4191 the Binding Update packet to this home agent MUST meet the IPsec 4192 requirements for Binding Updates, defined in Section 4.4. 4194 10.10. Retransmitting Binding Updates 4196 When the mobile node sends a Binding Update, it has to determine 4197 a value for the initial retransmission timer. If the mobile node 4198 is changing or updating an existing binding at the home agent, it 4199 should use the specified value of INITIAL_BINDACK_TIMEOUT for this 4200 initial retransmission timer. If on the other hand the mobile node 4201 does not have an existing binding at the home agent, it SHOULD use a 4202 value for the initial retransmission timer that is at least 1.5 times 4203 longer than (RetransTimer * DupAddrDetectTransmits). This value is 4204 likely to be substantially longer than the otherwise specified value 4205 of INITIAL_BINDACK_TIMEOUT that would be used by the mobile node. 4206 This longer retransmission interval will allow the the home agent 4207 to complete the DAD procedure which is mandated in this case, as 4208 detailed in section 10.6. 4210 If, after sending a Binding Update in which the care-of address has 4211 changed and the Acknowledge (A) bit is set, a mobile node fails 4212 to receive a valid, matching Binding Acknowledgement within the 4213 selected initial retransmission interval, the mobile node SHOULD 4214 retransmit the Binding Update, until a Binding Acknowledgement is 4215 received. Such a retransmitted Binding Update MUST use a Sequence 4216 Number value greater than that used for the previous transmission of 4217 this Binding Update. The retransmissions by the mobile node MUST 4218 use an exponential back-off process, in which the timeout period 4219 is doubled upon each retransmission until either the node receives 4220 a Binding Acknowledgement or the timeout period reaches the value 4221 MAX_BINDACK_TIMEOUT. 4223 10.11. Rate Limiting for Sending Binding Updates 4225 A mobile node MUST NOT send Binding Updates about the same binding to 4226 any individual node more often than once per MAX_UPDATE_RATE seconds. 4227 After sending MAX_FAST_UPDATES consecutive Binding Updates to a 4228 particular node with the same care-of address, the mobile node SHOULD 4229 reduce its rate of sending Binding Updates to that node, to the rate 4230 of SLOW_UPDATE_RATE per second. The mobile node MAY continue to send 4231 Binding Updates at this slower rate indefinitely, in hopes that the 4232 node will eventually be able to process a Binding Update and begin 4233 to route its packets directly to the mobile node at its new care-of 4234 address. 4236 10.12. Receiving Binding Acknowledgements 4238 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 4239 node MUST validate the packet according to the following tests: 4241 - The packet meets the specific IPsec requirements for Binding 4242 Acknowledgements, defined in Section 4.4. 4244 - The Option Length field in the Binding Acknowledgement option is 4245 greater than or equal to the length specified in Section 5.2. 4247 - The Sequence Number field matches the Sequence Number sent by the 4248 mobile node to this destination address in an outstanding Binding 4249 Update. 4251 Any Binding Acknowledgement not satisfying all of these tests MUST be 4252 silently ignored, although the remainder of the packet (i.e., other 4253 options, extension headers, or payload) SHOULD be processed normally 4254 according to any procedure defined for that part of the packet. 4256 When a mobile node receives a packet carrying a valid Binding 4257 Acknowledgement, the mobile node MUST examine the Status field as 4258 follows: 4260 - If the Status field indicates that the Binding Update was 4261 accepted (the Status field is less than 128), then the mobile 4262 node MUST update the corresponding entry in its Binding Update 4263 List to indicate that the Binding Update has been acknowledged; 4264 the mobile node MUST then stop retransmitting the Binding Update. 4265 In addition, if the value specified in the Lifetime field in the 4266 Binding Acknowledgement is less than the Lifetime value sent 4267 in the Binding Update being acknowledged, then the mobile node 4268 MUST subtract the difference between these two Lifetime values 4269 from the remaining lifetime for the binding as maintained in the 4270 corresponding Binding Update List entry (with a minimum value 4271 for the Binding Update List entry lifetime of 0). That is, if 4272 the Lifetime value sent in the Binding Update was L_update, the 4273 Lifetime value received in the Binding Acknowledgement was L_ack, 4274 and the current remaining lifetime of the Binding Update List 4275 entry is L_remain, then the new value for the remaining lifetime 4276 of the Binding Update List entry should be 4278 max((L_remain - (L_update - L_ack)), 0) 4280 where max(X, Y) is the maximum of X and Y. The effect of this 4281 step is to correctly manage the mobile node's view of the 4282 binding's remaining lifetime (as maintained in the corresponding 4283 Binding Update List entry) so that it correctly counts down from 4284 the Lifetime value given in the Binding Acknowledgement, but with 4285 the timer countdown beginning at the time that the Binding Update 4286 was sent. 4288 - If the Status field indicates that the Binding Update was 4289 rejected (the Status field is greater than or equal to 128), then 4290 the mobile node MUST delete the corresponding Binding Update List 4291 entry, and it MUST also stop retransmitting the Binding Update. 4292 Optionally, the mobile node MAY then take steps to correct the 4293 cause of the error and retransmit the Binding Update (with a new 4294 Sequence Number value), subject to the rate limiting restriction 4295 specified in Section 10.11. 4297 10.13. Receiving Binding Requests 4299 When a mobile node receives a packet containing a Binding Request, 4300 it SHOULD return to the sender a packet containing a Binding Update. 4302 The Lifetime field in this Binding Update SHOULD be set to a new 4303 lifetime, extending any current lifetime remaining from a previous 4304 Binding Update sent to this node (as indicated in any existing 4305 Binding Update List entry for this node), except that this lifetime 4306 MUST NOT exceed the remaining lifetime for the mobile node's primary 4307 care-of address registration at its home agent. When sending this 4308 Binding Update, the mobile node MUST update its Binding Update List 4309 in the same way as for any other Binding Update sent by the mobile 4310 node. 4312 Note, however, that the mobile node MAY choose to keep its current 4313 binding private from the sender of the Binding Request. In this 4314 case, the mobile node instead SHOULD return a Binding Update to the 4315 sender, in which the Lifetime field is set to zero and the care-of 4316 address is set to the mobile node's home address. 4318 If the Binding Request for which the Binding Update is being returned 4319 contains a Unique Identifer Sub-Option, the Binding Update MUST also 4320 include a Unique Identifier Sub-Option. The unique identifier in the 4321 Sub-Option Data field of the Unique Identifier Sub-Option MUST be 4322 copied from the unique identifier carried in the Binding Request. 4324 10.14. Receiving ICMP Error Messages 4326 The Option Type value for a Binding Update option specifies that 4327 any node receiving this option that does not recognize the Option 4328 Type SHOULD return an ICMP Parameter Problem, Code 2, message to 4329 the sender of the packet containing the Binding Update option. If 4330 a node sending a Binding Update receives such an ICMP error message 4331 in response, it SHOULD record in its Binding Update List that future 4332 Binding Updates SHOULD NOT be sent to this destination. 4334 Likewise, although ALL IPv6 nodes (whether host or router, whether 4335 mobile or stationary) MUST implement the ability to correctly process 4336 received packets containing a Home Address option, all Option Type 4337 values in IPv6 include a specification of the behavior that a node 4338 receiving a packet containing this option performs if it does not 4339 implement receipt of that type of option. For the Home Address 4340 option, the Option Type value specifies that any node receiving 4341 this option that does not recognize the Option Type SHOULD return 4342 an ICMP Parameter Problem, Code 2, message to the sender of the 4343 packet containing the Home Address option. If a mobile node receives 4344 such an ICMP error message from some node indicating that it does 4345 not recognize the mobile node's Home Address option, the mobile 4346 node SHOULD log the error and then discard the ICMP message; this 4347 error message indicates that the node to which the original packet 4348 was addressed (the node returning the ICMP error message) does not 4349 correctly implement this required part of the IPv6 protocol. 4351 10.15. Receiving Local Router Advertisement Messages 4353 Each mobile node maintains a Home Agents List recording information 4354 about all home agents from which it receives a Router Advertisement, 4355 for which the home agent lifetime indicated in that Router 4356 Advertisement has not yet expired. This list is used by the mobile 4357 node to enable it to send a Binding Update to the global unicast 4358 address of a home agent on its previous link when it moves to a new 4359 link, as described in Section 10.9. On receipt of a valid Router 4360 Advertisement, as defined in the processing algorithm specified for 4361 Neighbor Discovery [17], the mobile node performs the following 4362 steps, in addition to any steps already required of it by Neighbor 4363 Discovery and by other procedures described in this document: 4365 - If the Home Agent (H) bit in the Router Advertisement is not 4366 set, skip all of the following steps. There are no special 4367 processing steps required by this aspect of Mobile IP for this 4368 Router Advertisement, since the Advertisement was not sent by a 4369 home agent. 4371 - Otherwise, extract the Source Address from the IP header of the 4372 Router Advertisement. This is the link-local IP address on this 4373 link of the home agent sending this Advertisement [17]. 4375 - Determine from the Router Advertisement the preference for this 4376 home agent. If the Router Advertisement contains a Home Agent 4377 Information Option, then the preference is taken from the Home 4378 Agent Preference field in the option; otherwise, the default 4379 preference of 0 MUST be used. 4381 - Determine from the Router Advertisement the lifetime for 4382 this home agent. If the Router Advertisement contains a Home 4383 Agent Information Option, then the lifetime is taken from 4384 the Home Agent Lifetime field in the option; otherwise, the 4385 lifetime specified by the Router Lifetime field in the Router 4386 Advertisement SHOULD be used. 4388 - If the link-local address of the home agent sending this 4389 Advertisement is already present in this mobile node's Home 4390 Agents List and the received home agent lifetime value is zero, 4391 immediately delete this entry in the Home Agents List. 4393 - Otherwise, if the link-local address of the home agent sending 4394 this Advertisement is already present in the receiving mobile 4395 node's Home Agents List, reset its lifetime and preference to the 4396 values determined above. 4398 - If the link-local address of the home agent sending this 4399 Advertisement, as determined above, is not already present in the 4400 Home Agents List maintained by the receiving mobile node, and 4401 the lifetime for the sending home agent, as determined above, 4402 is non-zero, create a new entry in the list, and initialize its 4403 lifetime and preference to the values determined above. 4405 - If the Home Agents List entry for the link-local address of 4406 the home agent sending this Advertisement was not deleted as 4407 described above, determine any global address(es) of the home 4408 agent based on each Prefix Information option received in 4409 this Advertisement in which the Router Address (R) bit is set 4410 (Section 6.2). For each such global address determined from this 4411 Advertisement, add this global address to the list of global 4412 addresses for this home agent in this Home Agents List entry. 4414 A mobile node SHOULD maintain an entry in its Home Agents List for 4415 each such valid home agent address until that entry's lifetime 4416 expires, after which time the entry MUST be deleted. 4418 10.16. Sending Tunneled Router Solicitations 4420 When a mobile node has a home address that is about to become 4421 invalid, it tunnels a Router Solicitation to its home agent in 4422 an attempt to acquire fresh routing prefix information. The new 4423 information enables the mobile node to participate in renumbering 4424 operations affecting the home network, as described in section 9.8. 4426 The mobile node SHOULD tunnel a Router Solicitation to the home agent 4427 when its home address will become invalid within MaxRtrAdvInterval 4428 seconds, where this value is acquired in a previous Router 4429 Advertisement from the home agent. If no such value is known, the 4430 value MAX_PFX_ADV_DELAY seconds is used instead. 4432 The mobile node tunnels (using IPv6 encapsulation [4]) the 4433 solicitation, including the following IPv6 header fields: 4435 Outer src = care-of address 4436 Outer dst = Home Agent's global address 4437 Inner src = home address 4438 Inner dst = Home Agent's global address 4440 If the mobile node does not have a valid home address available for 4441 use as the Inner src address, it MAY use the unspecified IPv6 address 4442 (0:0:0:0:0:0:0:0). 4444 This solicitation follows the same retransmission rules as already 4445 specified for Router Solicitations [17], except that the initial 4446 retransmission interval is specified to be INITIAL_SOLICIT_TIMER. 4448 10.17. Receiving Tunneled Router Advertisements 4450 Section 9.8 describes the operation of a home agent to support 4451 renumbering a mobile node's home subnet while the mobile node is 4452 away from home. The home agent tunnels certain Router Advertisement 4453 messages to the mobile node while away from home, giving "important" 4454 Prefix Information options that describe changes in the prefixes in 4455 use on the mobile node's home link. 4457 When a mobile node receives a tunneled Router Advertisement, it MUST 4458 validate it according to the following tests: 4460 - The Source Address of the IP packet carrying the Router 4461 Advertisement is the same as the home agent address to which the 4462 mobile node last sent an accepted "home registration" Binding 4463 Update to register its primary care-of address. 4465 - The packet MUST be protected by IPsec [13, 11, 12] to guard 4466 against malicious Router Advertisements. The IPsec protection 4467 MUST provide sender authentication, data integrity protection, 4468 and replay protection, covering the Router Advertisement. 4470 - The packet contains a Binding Request destination option. 4472 - The Binding Request option contains a Unique Identifier 4473 Sub-Option. 4475 Any received tunneled Router Advertisement not meeting all of these 4476 tests MUST be silently discarded. 4478 If a received tunneled Router Advertisement is not discarded 4479 according to the tests listed above, the mobile node MUST process the 4480 Router Advertisement as if it were connected to its home link [17]. 4481 Such processing may result in the mobile node configuring a new home 4482 address, although due to separation between preferred lifetime and 4483 valid lifetime, such changes should not affect most communication by 4484 the mobile node, in the same way as for nodes that are at home. 4486 In processing the packet containing this Router Advertisement, the 4487 mobile node SHOULD return to the home agent a Binding Update in 4488 response to the Binding Request carried in the packet. The correct 4489 formation of this Binding Update by the mobile node and processing 4490 of it by the home agent will be viewed by the home agent as an 4491 acknowledgement of this Router Advertisement, confirming to it that 4492 this Router Advertisement was received by the mobile node. 4494 In addition, if processing of this Router Advertisement resulted in 4495 the mobile node configuring a new home address, and if the method 4496 used for this new home address configuration would require the mobile 4497 node to perform Duplicate Address Detection [27] for the new address 4498 if the mobile node were located at home, then the mobile node MUST 4499 set the Duplicate Address Detection (D) bit in this Binding Update to 4500 its home agent, to request the home agent to perform this Duplicate 4501 Address Detection on behalf of the mobile node. 4503 10.18. Using Multiple Care-of Addresses 4505 As described in Section 10.5, a mobile node MAY use more than one 4506 care-of address at a time. Particularly in the case of many wireless 4507 networks, a mobile node effectively might be reachable through 4508 multiple links at the same time (e.g., with overlapping wireless 4509 cells), on which different on-link subnet prefixes may exist. A 4510 mobile node SHOULD select a primary care-of address from among those 4511 care-of addresses it has formed using any of these subnet prefixes, 4512 based on the movement detection mechanism in use, as described in 4513 Section 10.4. When the mobile node selects a new primary care-of 4514 address, it MUST register it with its home agent by sending it a 4515 Binding Update with the Home Registration (H) and Acknowledge (A) 4516 bits set, as described in Section 10.6. 4518 To assist with smooth handoffs, a mobile node SHOULD retain 4519 its previous primary care-of address as a (non-primary) care-of 4520 address, and SHOULD still accept packets at this address, even after 4521 registering its new primary care-of address with its home agent. 4522 This is reasonable, since the mobile node could only receive packets 4523 at its previous primary care-of address if it were indeed still 4524 connected to that link. If the previous primary care-of address was 4525 allocated using stateful Address Autoconfiguration [2], the mobile 4526 node may not wish to release the address immediately upon switching 4527 to a new primary care-of address. 4529 10.19. Routing Multicast Packets 4531 A mobile node that is connected to its home link functions in the 4532 same way as any other (stationary) node. Thus, when it is at home, 4533 a mobile node functions identically to other multicast senders and 4534 receivers. This section therefore describes the behavior of a mobile 4535 node that is not on its home link. 4537 In order to receive packets sent to some multicast group, a mobile 4538 node must join that multicast group. One method by which a mobile 4539 node MAY join the group is via a (local) multicast router on the 4540 foreign link being visited. The mobile node SHOULD use one of its 4541 care-of addresses that shares a subnet prefix with the multicast 4542 router, as the source IPv6 address of its multicast group membership 4543 control messages. The mobile node MUST insert a Home Address 4544 destination option in such outgoing multicast packets, so that any 4545 multicast applications that depend on the address of the sending node 4546 will correctly use the mobile node's home address for that value. 4548 Alternatively, a mobile node MAY join multicast groups via a 4549 bi-directional tunnel to its home agent. The mobile node tunnels its 4550 multicast group membership control packets to its home agent, and the 4551 home agent forwards multicast packets down the tunnel to the mobile 4552 node. 4554 A mobile node that wishes to send packets to a multicast group 4555 also has two options: (1) send directly on the foreign link being 4556 visited; or (2) send via a tunnel to its home agent. Because 4557 multicast routing in general depends upon the Source Address used in 4558 the IPv6 header of the multicast packet, a mobile node that tunnels a 4559 multicast packet to its home agent MUST use its home address as the 4560 IPv6 Source Address of the inner multicast packet. 4562 10.20. Returning Home 4564 A mobile node detects that it has returned to its home link through 4565 the movement detection algorithm in use (Section 10.4), when the 4566 mobile node detects that its home subnet prefix is again on-link. 4567 The mobile node SHOULD then send a Binding Update to its home agent, 4568 to instruct its home agent to no longer intercept or tunnel packets 4569 for it. In this Binding Update, the mobile node MUST set the care-of 4570 address for the binding (the Source Address field in the packet's 4571 IPv6 header) to the mobile node's own home address. As with other 4572 Binding Updates sent to register with its home agent, the mobile 4573 node MUST set the Acknowledge (A) and Home Registration (H) bits, 4574 and SHOULD retransmit the Binding Update until a matching Binding 4575 Acknowledgement is received. 4577 When sending this Binding Update to its home agent, the mobile 4578 node must be careful in how it uses Neighbor Solicitation [17] (if 4579 needed) to learn the home agent's link-layer address, since the home 4580 agent will be currently configured to defend the mobile node's home 4581 address for Duplicate Address Detection. In particular, a Neighbor 4582 Solicitation from the mobile node using its home address as the 4583 Source Address would be detected by the home agent as a duplicate 4584 address. In many cases, Neighbor Solicitation by the mobile node 4585 for the home agent's address will not be necessary, since the mobile 4586 node may have already learned the home agent's link-layer address, 4587 for example from a Source Link-Layer Address option in the Router 4588 Advertisement from which it learned that its home address was on-link 4589 and that the mobile node had thus returned home. If the mobile node 4590 does Neighbor Solicitation to learn the home agent's link-layer 4591 address, in this special case of the mobile node returning home, the 4592 mobile node MUST unicast the packet, and in addition set the Source 4593 Address of this Neighbor Solicitation to the unspecified address 4594 (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home agent 4595 will be able to distinguish from a similar packet that would only be 4596 used for DAD. 4598 The mobile node then sends its Binding Update using the home agent's 4599 link-layer address, instructing its home agent to no longer serve 4600 as a home agent for it. By processing this Binding Update, the 4601 home agent will cease defending the mobile node's home address for 4602 Duplicate Address Detection and will no longer respond to Neighbor 4603 Solicitations for the mobile node's home address. The mobile node is 4604 then the only node on the link using the mobile node's home address. 4605 In addition, when returning home prior to the expiration of a current 4606 binding for its home address, and configuring its home address on its 4607 network interface on its home link, the mobile node MUST NOT perform 4608 Duplicate Address Detection on its own home address, in order to 4609 avoid confusion or conflict with its home agent's use of the same 4610 address. If the mobile node returns home after the bindings for all 4611 of its care-of addresses have expired, then it SHOULD perform DAD. 4613 After receiving the Binding Acknowledgement for its Binding Update 4614 to its home agent, the mobile node MUST multicast onto the home 4615 link (to the all-nodes multicast address) a Neighbor Advertisement 4616 message [17], to advertise the mobile node's own link-layer address 4617 for its own home address. The Target Address in this Neighbor 4618 Advertisement message MUST be set to the mobile node's home address, 4619 and the Advertisement MUST include a Target Link-layer Address option 4620 specifying the mobile node's link-layer address. The mobile node 4621 MUST multicast such a Neighbor Advertisement message for each of its 4622 home addresses, as defined by the current on-link prefixes, including 4623 its link-local address and site-local address. The Solicited 4624 Flag (S) in these Advertisements MUST NOT be set, since they were 4625 not solicited by any Neighbor Solicitation message. The Override 4626 Flag (O) in these Advertisements MUST be set, indicating that the 4627 Advertisements SHOULD override any existing Neighbor Cache entries at 4628 any node receiving them. 4630 Since multicasts on the local link (such as Ethernet) are typically 4631 not guaranteed to be reliable, the mobile node MAY retransmit these 4632 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 4633 increase their reliability. It is still possible that some nodes on 4634 the home link will not receive any of these Neighbor Advertisements, 4635 but these nodes will eventually be able to recover through use of 4636 Neighbor Unreachability Detection [17]. 4638 11. Protocol Constants 4640 INITIAL_BINDACK_TIMEOUT 1 second 4642 INITIAL_SOLICIT_TIMER 2 seconds 4644 MAX_BINDACK_TIMEOUT 256 seconds 4646 MAX_UPDATE_RATE once per second 4648 SLOW_UPDATE_RATE once per 10 seconds 4650 MAX_FAST_UPDATES 5 transmissions 4652 MAX_ADVERT_REXMIT 3 transmissions 4654 MAX_PFX_ADV_DELAY 1,000 seconds 4656 HomeRtrAdvInterval 1,000 seconds 4658 12. IANA Considerations 4660 This document defines four new types of IPv6 destination options, 4661 each of which must be assigned an Option Type value: 4663 - The Binding Update option, described in Section 5.1; 4665 - The Binding Acknowledgement option, described in Section 5.2; 4667 - The Binding Request option, described in Section 5.3; and 4669 - The Home Address option, described in Section 5.4. 4671 In addition, this document defines two ICMP message types, used as 4672 part of the dynamic home agent address discovery mechanism: 4674 - The Home Agent Address Discovery Request message, described in 4675 Section 5.6; and 4677 - The Home Agent Address Discovery Reply message, described in 4678 Section 5.7. 4680 This document also defines two new Neighbor Discovery [17] options, 4681 which must be assigned Option Type values within the option numbering 4682 space for Neighbor Discovery messages: 4684 - The Advertisement Interval option, described in Section 6.3; and 4686 - The Home Agent Information option, described in Section 6.4. 4688 Finally, this document defines a new type of anycast address, which 4689 must be assigned a reserved value for use with any subnet prefix to 4690 define this anycast address on each subnet: 4692 - The "Mobile IPv6 Home-Agents" anycast address [10], used in the 4693 dynamic home agent address discovery mechanism described in 4694 Sections 9.2 and 10.7. 4696 13. Security Considerations 4698 13.1. Binding Updates, Acknowledgements, and Requests 4700 The Binding Update option described in this document will result 4701 in packets addressed to a mobile node being delivered instead to 4702 its care-of address. This ability to change the routing of these 4703 packets could be a significant vulnerability if any packet containing 4704 a Binding Update option was not authenticated. Such use of "remote 4705 redirection", for instance as performed by the Binding Update option, 4706 is widely understood to be a security problem in the current Internet 4707 if not authenticated [1]. 4709 The Binding Acknowledgement option also requires authentication, 4710 since, for example, an attacker could otherwise trick a mobile node 4711 into believing a different outcome from a registration attempt with 4712 its home agent. 4714 No authentication is required for the Binding Request option, since 4715 the use of this option does not modify or create any state in either 4716 the sender or the receiver. The Binding Request option does open 4717 some issues with binding privacy, but those issues can be dealt with 4718 either through existing IPsec encryption mechanisms or through use of 4719 firewalls. 4721 The existing IPsec replay protection mechanisms allow a "replay 4722 protection window" to support receiving packets out of order. 4723 Although appropriate for many forms of communication, Binding Updates 4724 MUST be applied only in the order sent. The Binding Update option 4725 thus includes a Sequence Number field to provide this necessary 4726 sequencing. The use of this Sequence Number together with IPsec 4727 replay protection is similar in many ways, for example, to the the 4728 sequence number in TCP. IPsec provides strong replay protection but 4729 no ordering, and the sequence number provides ordering but need not 4730 protect against replays such as may occur when the sequence number 4731 wraps around. 4733 13.2. Security for the Home Address Option 4735 No special authentication of the Home Address option is required, 4736 except that if the IPv6 header of a packet is covered by 4737 authentication, then that authentication MUST also cover the Home 4738 Address option; this coverage is achieved automatically by the 4739 definition of the Option Type code for the Home Address option 4740 (Section 5.4), since it indicates that the option is included in the 4741 authentication computation. Thus, even when authentication is used 4742 in the IPv6 header, the security of the Source Address field in the 4743 IPv6 header is not compromised by the presence of a Home Address 4744 option. Without authentication of the packet, then any field in the 4745 IPv6 header, including the Source Address field, and any other parts 4746 of the packet, including the Home Address option, can be forged or 4747 modified in transit. In this case, the contents of the Home Address 4748 option is no more suspect than any other part of the packet. 4750 The use of the Home Address option allows packets sent by a 4751 mobile node to pass normally through routers implementing ingress 4752 filtering [7]. Since the care-of address used in the Source Address 4753 field of the packet's IPv6 header is topologically correct for the 4754 sending location of the mobile node, ingress filtering can trace the 4755 location of the mobile node in the same way as can be done with any 4756 sender when ingress filtering is in use. A node receiving a packet 4757 that includes a Home Address option MAY implement the processing of 4758 this option by physically exchanging the Home Address option field 4759 with the source IPv6 address in the IPv6 header. 4761 13.3. General Mobile Computing Issues 4763 The mobile computing environment is potentially very different from 4764 the ordinary computing environment. In many cases, mobile computers 4765 will be connected to the network via wireless links. Such links 4766 are particularly vulnerable to passive eavesdropping, active replay 4767 attacks, and other active attacks. Furthermore, mobile computers 4768 are more susceptible to loss or theft than stationary computers. 4769 Any secrets such as authentication or encryption keys stored on the 4770 mobile computer are thus subject to compromise in ways generally not 4771 common in the non-mobile environment. 4773 Users who have sensitive data that they do not wish others to have 4774 access to SHOULD use additional mechanisms (such as encryption) to 4775 provide privacy protection, but such mechanisms are beyond the scope 4776 of this document. Users concerned about traffic analysis SHOULD 4777 consider appropriate use of link encryption. If stronger location 4778 privacy is desired, the mobile node can create a tunnel to its home 4779 agent. Then, packets destined for correspondent nodes will appear 4780 to emanate from the home subnet, and it may be more difficult to 4781 pinpoint the location of the mobile node. Such mechanisms are all 4782 beyond the scope of this document. 4784 Whether or not the mobile node is away from home is likely to 4785 influence the choice of security policy from the SPD. For instance, 4786 if a mobile node is connected to its home network and it communicates 4787 with a correspondent node on its home network, no security may be 4788 needed. If, on the other hand, the mobile node is attached to 4789 foreign network and has sent a Binding Update to its home agent, then 4790 the mobile node may need to make use of security features in order to 4791 communicate with that same correspondent node. 4793 Changes from Previous Version of the Draft 4795 This appendix briefly lists some of the major changes in this 4796 draft relative to the previous version of this same draft, 4797 draft-ietf-mobileip-ipv6-12.txt: 4799 - Specified that the Home Address destination option MUST be 4800 inserted between Routing Header and Fragment Header 4802 - Specified that the Binding Update MUST be located after the IPsec 4803 header(s). 4805 - Specified that the AH is to be calculated as if the home address 4806 were in the IPv6 header, and the care-of address were in the Home 4807 Address destination option. 4809 - Changed SHOULD to MUST for treating unspecified home agent 4810 preferences as 0. 4812 - Introduced the notion of scheduling Router Advertisements to 4813 be sent to the mobile node whenever a prefix advertisement or 4814 internal reconfiguration causes a mobile node's home address to 4815 be in danger of becoming deprecated. 4817 - Specified that the mobile node MUST set the `D' bit whenever it 4818 sends a Binding Update that is new, instead of simply updating an 4819 existing binding to a new care-of address or binding lifetime. 4821 - Added new section on mobile node tunneling Router Solicitations 4823 - Added appendix about remote autoconfiguration for home addresses. 4825 - Added specification about picking a longer initial retransmission 4826 interval for initial Binding Updates sent to the home agent, 4827 because the home agent will take longer since it has to perform 4828 DAD. 4830 - Added the following protocol constants: 4832 INITIAL_SOLICIT_TIMER: 2 seconds 4834 MAX_PFX_ADV_DELAY: 1,000 seconds 4836 HomeRtrAdvInterval: 1,000 seconds 4838 Acknowledgements 4840 We would like to thank the members of the Mobile IP and IPng Working 4841 Groups for their comments and suggestions on this work. We would 4842 particularly like to thank (in alphabetical order) Fred Baker 4843 (Cisco), Josh Broch (Carnegie Mellon University), Robert Chalmers 4844 (University of California at Santa Barbara), Rich Draves (Microsoft 4845 Research), Francis Dupont (ENST Bretagne), Thomas Eklund (SwithCore), 4846 Jun-Ichiro Itojun Hagino (IIJ Research Laboratory), Aime Lerouzic 4847 (Bull S.A.), Thomas Narten (IBM), Erik Nordmark (Sun Microsystems), 4848 Simon Nybroe (Ericsson Telebit), David Oran (Cisco), Basavaraj Patil 4849 (Nokia), Ken Powell (Compaq), Phil Roberts (Motorola), Patrice 4850 Romand (Bull S.A.), Tom Soderlund (Nokia Research), Hesham Soliman 4851 (Ericsson), Jim Solomon (RedBack Networks), Tapio Suihko (Technical 4852 Research Center of Finland), Benny Van Houdt (University of Antwerp), 4853 Jon-Olov Vatn (KTH), and Xinhua Zhao (Stanford University) for 4854 their detailed reviews of earlier versions of this document. Their 4855 suggestions have helped to improve both the design and presentation 4856 of the protocol. 4858 We would also like to thank the participants in the Mobile IPv6 4859 testing event held at Nancy, France, September 15-17, 1999, for 4860 their valuable feedback as a result of interoperability testing 4861 of four Mobile IPv6 implementations coming from four different 4862 organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC 4863 (FreeBSD), and INRIA (FreeBSD). Further, we would like to thank the 4864 feedback from the implementors who participated in the Mobile IPv6 4865 interoperability testing at Connectathon 2000 in San Jose, 4866 California, March 6-9, 2000. Finally, we would like to thank the 4867 participants at the ETSI interoperability testing at ETSI, in Sophia 4868 Antipolis, France, during October 2-6, 2000, including teams from 4869 Compaq, Ericsson, INRIA, Nokia, and Technical University of Helsinki. 4871 References 4873 [1] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. 4874 ACM Computer Communications Review, 19(2), March 1989. 4876 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 4877 Protocol for IPv6 (DHCPv6), February 1999. Work in progress. 4879 [3] Scott Bradner. Key words for use in RFCs to Indicate 4880 Requirement Levels. RFC 2119, March 1997. 4882 [4] Alex Conta and Stephen Deering. Generic Packet Tunneling in 4883 IPv6 Specification. RFC 2473, December 1998. 4885 [5] Alex Conta and Stephen Deering. Internet Control Message 4886 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 4887 Specification. RFC 2463, December 1998. 4889 [6] Stephen E. Deering and Robert M. Hinden. Internet Protocol 4890 Version 6 (IPv6) Specification. RFC 2460, December 1998. 4892 [7] Paul Ferguson and Daniel Senie. Network Ingress Filtering: 4893 Defeating Denial of Service Attacks which employ IP Source 4894 Address Spoofing. RFC 2267, January 1998. 4896 [8] Dan Harkins and Dave Carrel. The Internet Key Exchange (IKE). 4897 RFC 2409, November 1998. 4899 [9] Robert M. Hinden and Stephen E. Deering. IP Version 6 4900 Addressing Architecture. RFC 2373, July 1998. 4902 [10] David B. Johnson and Stephen E. Deering. Reserved IPv6 Subnet 4903 Anycast Addresses. RFC 2526, March 1999. 4905 [11] Stephen Kent and Randall Atkinson. IP Authentication Header. 4906 RFC 2402, November 1998. 4908 [12] Stephen Kent and Randall Atkinson. IP Encapsulating Security 4909 Payload (ESP). RFC 2406, November 1998. 4911 [13] Stephen Kent and Randall Atkinson. Security Architecture for 4912 the Internet Protocol. RFC 2401, November 1998. 4914 [14] Douglas Maughan, Mark Schneider, Mark Schertler, and Jeff 4915 Turner. Internet Security Association and Key Management 4916 Protocol (ISAKMP). RFC 2408, November 1998. 4918 [15] P. Mockapetris. Domain Names -- Concepts and Facilities. 4919 RFC 1034, November 1987. 4921 [16] P. Mockapetris. Domain Names -- Implementation and 4922 Specification. RFC 1035, November 1987. 4924 [17] Thomas Narten, Erik Nordmark, and William Allen Simpson. 4925 Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 4926 1998. 4928 [18] Charles Perkins. IP Encapsulation within IP. RFC 2003, October 4929 1996. 4931 [19] Charles Perkins, editor. IP Mobility Support. RFC 2002, 4932 October 1996. 4934 [20] Charles Perkins. Minimal Encapsulation within IP. RFC 2004, 4935 October 1996. 4937 [21] Charles Perkins and David B. Johnson. Route Optimization in 4938 Mobile IP, February 1999. Work in progress. 4940 [22] Derrell Piper. The Internet IP Security Domain of 4941 Interpretation for ISAKMP. RFC 2407, November 1998. 4943 [23] David C. Plummer. An Ethernet Address Resolution Protocol: 4944 Or Converting Network Protocol Addresses to 48.bit Ethernet 4945 Addresses for Transmission on Ethernet Hardware. RFC 826, 4946 November 1982. 4948 [24] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 4950 [25] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 4951 September 1981. 4953 [26] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, 4954 October 1994. See also http://www.iana.org/numbers.html. 4956 [27] Susan Thomson and Thomas Narten. IPv6 Stateless Address 4957 Autoconfiguration. RFC 2462, December 1998. 4959 A. Remote Home Address Configuration 4961 The method for initializing a mobile node's home addresses on 4962 power-up or after an extended period of being disconnected from 4963 the network is beyond the scope of this specification. Whatever 4964 procedure is used should result in the mobile node having the same 4965 stateless or stateful (e.g., DHCPv6) home address autoconfiguration 4966 information it would have if it were attached to the home network. 4967 Due to the possibility that the home network could be renumbered 4968 while the mobile node is disconnected, a robust mobile node would not 4969 rely solely on storing these addresses locally. 4971 A mobile node MAY generate a temporary home address using the 4972 following information: 4974 - the subnet prefix from the home network's mobile agent anycast 4975 address, and 4977 - the globally unique interface identifier that would have been 4978 used to generate the link local address if the mobile node were 4979 attached directly to the home network. 4981 Such a temporary address could be used to establish a binding with 4982 a home agent in the absence of any other known home addresses. It 4983 could be created with short valid lifetime and a preferred lifetime 4984 of zero to ensure a quick transition to other addresses generated 4985 when stateless or stateful (DHCPv6) address autoconfiguration runs. 4987 Such a mobile node could initialize by using the following procedure: 4989 1. Generate a care-of address using stateless or stateful 4990 autoconfiguration. 4992 2. Query DNS for the home network's mobile agent anycast address. 4994 3. Send a Home Agent Address Discovery Request message to the home 4995 network. 4997 4. Receive Home Agent Address Discovery Reply message. 4999 5. Select the most preferred home agent address and use it to 5000 generate a temporary home address for the mobile node using the 5001 rules defined above. 5003 6. Send a binding update option with a Router Solicitation to the 5004 home agent. This registers the mobile node's temporary home 5005 address and requests a router advertisement to initiate stateless 5006 address autoconfiguration at the same time. 5008 7. Receive binding acknowledgement and binding request options with 5009 a router advertisement from the home agent. 5011 8. Parse the Router Advertisement and configure all prefixes and 5012 addresses according to the method stated there. If the M or O 5013 flags are set in the router advertisement, follow the stateful 5014 (DHCPv6) configuration procedures. These procedures could make 5015 the temporary home address permanent by increasing its valid and 5016 preferred lifetimes. 5018 9. Send binding update option(s) to update the binding for the 5019 temporary home address and to establish bindings for any new home 5020 addresses. 5022 Chair's Address 5024 The Working Group can be contacted via its current chairs: 5026 Phil Roberts 5027 Motorola 5028 1501 West Shure Drive 5029 Arlington Heights, IL 60004 5031 Phone: +1 847 632-3148 5032 E-mail: qa3445@email.mot.com 5034 Basavaraj Patil 5035 Nokia 5036 6000 Connection Drive 5037 M/S M8-540 5038 Irving, TX 75039 5039 USA 5041 Phone: +1 972 894-6709 5042 Fax: +1 972 894-5349 5043 E-mail: raj.patil@nokia.com 5045 Authors' Addresses 5047 Questions about this document can also be directed to the authors: 5049 David B. Johnson 5050 Rice University 5051 Department of Computer Science, MS 132 5052 6100 Main Street 5053 Houston, TX 77005-1892 5054 USA 5056 Phone: +1 713 348-3063 5057 Fax: +1 713 348-5930 5058 E-mail: dbj@cs.rice.edu 5060 Charles Perkins 5061 Nokia 5062 313 Fairchild Drive 5063 Mountain View, CA 94043 5064 USA 5066 Phone: +1 650 625-2986 5067 Fax: +1 650 625-2502 5068 E-mail: charliep@iprg.nokia.com