idnits 2.17.1 draft-ietf-mobileip-ipv6-11.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 == The page length should not exceed 58 lines per page, but there was 107 longer pages, the longest (page 0) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 108 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Packets sent by a mobile node while away from home generally include a Home Address option. When any node receives a packet containing a Home Address option, it MUST process the option in a manner consistent with copying the Home Address field from the Home Address option into the IPv6 header, replacing the original value of the Source Address field there. However, any actual modifications to the Source Address field in the packet's IPv6 header MUST not be performed until after all processing of other options contained in this same Destination Options extension header is completed. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (10 March 2000) is 8813 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 (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group David B. Johnson 2 INTERNET-DRAFT Carnegie Mellon University 3 Charles Perkins 4 Nokia 5 10 March 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 and ICMP Messages . . . . . 11 66 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 14 67 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 18 69 5. New IPv6 Destination Options and Message Types 20 70 5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 20 71 5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 25 72 5.3. Binding Request Option . . . . . . . . . . . . . . . . . 29 73 5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 31 74 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 33 75 5.6. ICMP Home Agent Address Discovery Request Message . . . . 36 76 5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 38 78 6. Modifications to IPv6 Neighbor Discovery 40 79 6.1. Modified Router Advertisement Message Format . . . . . . 40 80 6.2. Modified Prefix Information Option Format . . . . . . . . 41 81 6.3. New Advertisement Interval Option Format . . . . . . . . 43 82 6.4. New Home Agent Information Option Format . . . . . . . . 44 83 6.5. Changes to Sending Router Advertisements . . . . . . . . 46 84 6.6. Changes to Sending Router Solicitations . . . . . . . . . 47 86 7. Requirements for IPv6 Nodes 49 87 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 49 88 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 49 89 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 49 90 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 50 92 8. Correspondent Node Operation 52 93 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 52 94 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 52 95 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 53 96 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 54 97 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 54 98 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 54 99 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 55 100 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 56 101 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 57 103 9. Home Agent Operation 59 104 9.1. Receiving Router Advertisement Messages . . . . . . . . . 59 105 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 60 106 9.3. Primary Care-of Address Registration . . . . . . . . . . 62 107 9.4. Primary Care-of Address De-registration . . . . . . . . . 64 108 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 65 109 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 67 110 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 68 112 10. Mobile Node Operation 71 113 10.1. Sending Packets While Away from Home . . . . . . . . . . 71 114 10.2. Interaction with Outbound IPsec Processing . . . . . . . 72 115 10.3. Receiving Packets While Away from Home . . . . . . . . . 74 116 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 75 117 10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 78 118 10.6. Sending Binding Updates to the Home Agent . . . . . . . . 79 119 10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 80 120 10.8. Sending Binding Updates to Correspondent Nodes . . . . . 81 121 10.9. Establishing Forwarding from a Previous Care-of Address . 84 122 10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 85 123 10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 85 124 10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 86 125 10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 86 126 10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 87 127 10.15. Receiving Local Router Advertisement Messages . . . . . . 87 128 10.16. Receiving Tunneled Router Advertisements . . . . . . . . 89 129 10.17. Using Multiple Care-of Addresses . . . . . . . . . . . . 90 130 10.18. Routing Multicast Packets . . . . . . . . . . . . . . . . 91 131 10.19. Returning Home . . . . . . . . . . . . . . . . . . . . . 91 133 11. Protocol Constants 94 135 12. IANA Considerations 95 137 13. Security Considerations 96 138 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 96 139 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 96 140 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 97 142 Changes from Previous Version of the Draft 99 144 Acknowledgements 100 146 References 101 148 Chair's Address 103 150 Authors' Addresses 104 151 1. Introduction 153 This document specifies the operation of mobile computers using 154 Internet Protocol Version 6 (IPv6) [6]. Without specific support 155 for mobility in IPv6, packets destined to a mobile node (host or 156 router) would not be able to reach it while the mobile node is away 157 from its home link (the link on which its home IPv6 subnet prefix is 158 in use), since routing is based on the subnet prefix in a packet's 159 destination IP address. In order to continue communication in spite 160 of its movement, a mobile node could change its IP address each time 161 it moves to a new link, but the mobile node would then not be able 162 to maintain transport and higher-layer connections when it changes 163 location. Mobility support in IPv6 is particularly important, as 164 mobile computers are likely to account for a majority or at least a 165 substantial fraction of the population of the Internet during the 166 lifetime of IPv6. 168 The protocol operation defined here, known as Mobile IPv6, allows a 169 mobile node to move from one link to another without changing the 170 mobile node's IP address. A mobile node is always addressable by 171 its "home address", an IP address assigned to the mobile node within 172 its home subnet prefix on its home link. Packets may be routed to 173 the mobile node using this address regardless of the mobile node's 174 current point of attachment to the Internet, and the mobile node may 175 continue to communicate with other nodes (stationary or mobile) after 176 moving to a new link. The movement of a mobile node away from its 177 home link is thus transparent to transport and higher-layer protocols 178 and applications. 180 The Mobile IPv6 protocol is just as suitable for mobility across 181 homogeneous media as for mobility across heterogeneous media. For 182 example, Mobile IPv6 facilitates node movement from one Ethernet 183 segment to another as well as it facilitates node movement from an 184 Ethernet segment to a wireless LAN cell, with the mobile node's IP 185 address remaining unchanged in spite of such movement. 187 One can think of the Mobile IPv6 protocol as solving the "macro" 188 mobility management problem. More "micro" mobility management 189 applications -- for example, handoff among wireless transceivers, 190 each of which covers only a very small geographic area -- are 191 possibly more suited to other solutions. For example, in many 192 current wireless LAN products, link-layer mobility mechanisms allow a 193 "handoff" of a mobile node from one cell to another, reestablishing 194 link-layer connectivity to the node in each new location. As long 195 as such handoff occurs only within cells of the mobile node's home 196 link, such link-layer mobility mechanisms are likely to offer faster 197 convergence and lower overhead than Mobile IPv6. Extensions to the 198 Mobile IPv6 protocol are also possible to support a more local, 199 hierarchical form of mobility management, but such extensions are 200 beyond the scope of this document. 202 The protocol specified in this document solves the problem of 203 transparently routing packets to and from mobile nodes while away 204 from home. However, it does not attempt to solve all general 205 problems related to the use of mobile computers or wireless networks. 206 In particular, this protocol does not attempt to solve: 208 - Handling links with partial reachability, such as typical 209 wireless networks. Some aspects of this problem are addressed 210 by the movement detection procedure described in Section 10.4, 211 but no attempt has been made to fully solve this problem in its 212 general form. Most aspects of this problem can be solved by the 213 workaround of restricting such networks to only one router per 214 link, although there are still possible hidden terminal problems 215 when two nodes on the same link (on opposite sides of the router) 216 attempt to communicate directly. 218 - Access control on a link being visited by a mobile node. This 219 is a general problem any time an untrusted node is allowed to 220 connect to any link layer. It is independent of whether the 221 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 222 address on the link. 224 2. Comparison with Mobile IP for IPv4 226 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 227 natural combination of the experiences gained from the development 228 of Mobile IP support in IPv4 (Mobile IPv4) [19, 18, 20], together 229 with the opportunities provided by the design and deployment of a new 230 version of IP itself (IPv6) and the new protocol features offered 231 by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, 232 but the protocol is now fully integrated into IP and provides many 233 improvements over Mobile IPv4. This section summarizes the major 234 differences between Mobile IPv4 and Mobile IPv6: 236 - Support for what is known in Mobile IPv4 as "Route 237 Optimization" [21] is now built in as a fundamental part 238 of the protocol, rather than being added on as an optional 239 set of extensions that may not be supported by all nodes 240 as in Mobile IPv4. This integration of Route Optimization 241 functionality allows direct routing from any correspondent node 242 to any mobile node, without needing to pass through the mobile 243 node's home network and be forwarded by its home agent, and thus 244 eliminates the problem of "triangle routing" present in the base 245 Mobile IPv4 protocol [19]. This integration also allows the 246 Mobile IPv4 "registration" functionality and the Mobile IPv4 247 Route Optimization functionality to be performed by a single 248 protocol rather than two separate (and different) protocols. 250 - Support is also integrated into Mobile IPv6 -- and into IPv6 251 itself -- for allowing mobile nodes and Mobile IP to coexist 252 efficiently with routers that perform "ingress filtering" [7]. A 253 mobile node now uses its care-of address as the Source Address in 254 the IP header of packets it sends, allowing the packets to pass 255 normally through ingress filtering routers. The home address 256 of the mobile node is carried in the packet in a Home Address 257 destination option, allowing the use of the care-of address in 258 the packet to be transparent above the IP layer. The ability 259 to correctly process a Home Address option in a received packet 260 is required in all IPv6 nodes, whether mobile nor stationary, 261 whether host or router. 263 - The use of the care-of address as the Source Address in each 264 packet's IP header also simplifies routing of multicast packets 265 sent by a mobile node. With Mobile IPv4, the mobile node 266 had to tunnel multicast packets to its home agent in order to 267 transparently use its home address as the source of the multicast 268 packets. With Mobile IPv6, the use of the Home Address option 269 allows the home address to be used but still be compatible with 270 multicast routing that is based in part on the packet's Source 271 Address. 273 - There is no longer any need to deploy special routers as 274 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 275 mobile nodes make use of the enhanced features of IPv6, such 276 as Neighbor Discovery [17] and Address Autoconfiguration [27], 277 to operate in any location away from home without any special 278 support required from its local router. 280 - Unlike Mobile IPv4, Mobile IPv6 utilizes IP Security 281 (IPsec) [11, 12, 13] for all security requirements (sender 282 authentication, data integrity protection, and replay protection) 283 for Binding Updates (which serve the role of both registration 284 and Route Optimization in Mobile IPv4). Mobile IPv4 relies 285 on its own security mechanisms for these functions, based on 286 statically configured "mobility security associations". 288 - The movement detection mechanism in Mobile IPv6 provides 289 bidirectional confirmation of a mobile node's ability to 290 communicate with its default router in its current location 291 (packets that the router sends are reaching the mobile node, and 292 packets that the mobile node sends are reaching the router). 293 This confirmation provides a detection of the "black hole" 294 situation that may exist in some wireless environments where the 295 link to the router does not work equally well in both directions, 296 such as when the mobile node has moved out of good wireless 297 transmission range from the router. The mobile node may then 298 attempt to find a new router and begin using a new care-of 299 address if its link to its current router is not working well. 300 In contrast, in Mobile IPv4, only the forward direction (packets 301 from the router are reaching the mobile node) is confirmed, 302 allowing the black hole condition to persist. 304 - Most packets sent to a mobile node while away from home in 305 Mobile IPv6 are sent using an IPv6 Routing header rather than IP 306 encapsulation, whereas Mobile IPv4 must use encapsulation for all 307 packets. The use of a Routing header requires less additional 308 header bytes to be added to the packet, reducing the overhead 309 of Mobile IP packet delivery. To avoid modifying the packet in 310 flight, however, packets intercepted and tunneled by a mobile 311 node's home agent in Mobile IPv6 must still use encapsulation for 312 delivery to the mobile node. 314 - While a mobile node is away from home, its home agent intercepts 315 any packets for the mobile node that arrive at the home network, 316 using IPv6 Neighbor Discovery [17] rather than ARP [23] as is 317 used in Mobile IPv4. The use of Neighbor Discovery improves 318 the robustness of the protocol (e.g., due to the Neighbor 319 Advertisement "override" bit) and simplifies implementation 320 of Mobile IP due to the ability to not be concerned with any 321 particular link layer as is required in ARP. 323 - The use of IPv6 encapsulation (and the Routing header) removes 324 the need in Mobile IPv6 to manage "tunnel soft state", which was 325 required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 326 to the definition of ICMP for IPv6, the use of tunnel soft state 327 is no longer required in IPv6 for correctly relaying ICMP error 328 messages from within the tunnel back to the original sender of 329 the packet. 331 - The dynamic home agent address discovery mechanism in Mobile IPv6 332 uses IPv6 anycast [10] and returns a single reply to the mobile 333 node, rather than the corresponding Mobile IPv4 mechanism that 334 used IPv4 directed broadcast and returned a separate reply from 335 each home agent on the mobile node's home link. The Mobile IPv6 336 mechanism is more efficient and more reliable, since only 337 one packet need be sent back to the mobile node and since the 338 mobile node is less likely to lose one of the replies because no 339 "implosion" of replies is required by the protocol. 341 - Mobile IPv6 defines an Advertisement Interval option on 342 Router Advertisements (equivalent to Agent Advertisements in 343 Mobile IPv4), allowing a mobile node to decide for itself how 344 many Router Advertisements (Agent Advertisements) it is willing 345 to miss before declaring its current router unreachable. 347 - The use of IPv6 destination options allows all Mobile IPv6 348 control traffic to be piggybacked on any existing IPv6 packets, 349 whereas in Mobile IPv4 and its Route Optimization extensions, 350 separate UDP packets were required for each control message. 352 3. Terminology 354 3.1. General Terms 356 IP 358 Internet Protocol Version 6 (IPv6). 360 node 362 A device that implements IP. 364 router 366 A node that forwards IP packets not explicitly addressed to 367 itself. 369 host 371 Any node that is not a router. 373 link 375 A communication facility or medium over which nodes can 376 communicate at the link layer, such as an Ethernet (simple or 377 bridged). A link is the layer immediately below IP. 379 interface 381 A node's attachment to a link. 383 subnet prefix 385 A bit string that consists of some number of initial bits of an 386 IP address. 388 interface identifier 390 A number used to identify a node's interface on a link. The 391 interface identifier is the remaining low-order bits in the 392 node's IP address after the subnet prefix. 394 link-layer address 396 A link-layer identifier for an interface, such as IEEE 802 397 addresses on Ethernet links. 399 packet 401 An IP header plus payload. 403 3.2. Mobile IPv6 Terms 405 home address 407 An IP address assigned to a mobile node within its home link. 409 home subnet prefix 411 The IP subnet prefix corresponding to a mobile node's home 412 address. 414 home link 416 The link on which a mobile node's home subnet prefix is 417 defined. Standard IP routing mechanisms will deliver packets 418 destined for a mobile node's home address to its home link. 420 mobile node 422 A node that can change its point of attachment from one link to 423 another, while still being reachable via its home address. 425 movement 427 A change in a mobile node's point of attachment to the Internet 428 such that it is no longer connected to the same link as it was 429 previously. If a mobile node is not currently attached to its 430 home link, the mobile node is said to be "away from home". 432 correspondent node 434 A peer node with which a mobile node is communicating. The 435 correspondent node may be either mobile or stationary. 437 foreign subnet prefix 439 Any IP subnet prefix other than the mobile node's home subnet 440 prefix. 442 foreign link 444 Any link other than the mobile node's home link. 446 home agent 448 A router on a mobile node's home link with which the mobile 449 node has registered its current care-of address. While the 450 mobile node is away from home, the home agent intercepts 451 packets on the home link destined to the mobile node's home 452 address, encapsulates them, and tunnels them to the mobile 453 node's registered care-of address. 455 care-of address 457 An IP address associated with a mobile node while visiting a 458 foreign link; the subnet prefix of this IP address is a foreign 459 subnet prefix. Among the multiple care-of addresses that a 460 mobile node may have at a time (e.g., with different subnet 461 prefixes), the one registered with the mobile node's home agent 462 is called its "primary" care-of address. 464 binding 466 The association of the home address of a mobile node with a 467 care-of address for that mobile node, along with the remaining 468 lifetime of that association. 470 3.3. Specification Language 472 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 473 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 474 document are to be interpreted as described in RFC 2119 [3]. 476 4. Overview of Mobile IPv6 478 4.1. Basic Operation 480 A mobile node is always addressable by its home address, whether it 481 is currently attached to its home link or is away from home. While 482 a mobile node is at home, packets addressed to its home address are 483 routed to it using conventional Internet routing mechanisms in the 484 same way as if the node were never mobile. Since the subnet prefix 485 of a mobile node's home address is the subnet prefix (or one of the 486 subnet prefixes) on the mobile node's home link (it is the mobile 487 node's home subnet prefix), packets addressed to it will be routed to 488 its home link. 490 While a mobile node is attached to some foreign link away from home, 491 it is also addressable by one or more care-of addresses, in addition 492 to its home address. A care-of address is an IP address associated 493 with a mobile node while visiting a particular foreign link. The 494 subnet prefix of a mobile node's care-of address is the subnet prefix 495 (or one of the subnet prefixes) on the foreign link being visited by 496 the mobile node; if the mobile node is connected to this foreign link 497 while using that care-of address, packets addressed to this care-of 498 address will be routed to the mobile node in its location away from 499 home. 501 The association between a mobile node's home address and care-of 502 address is known as a "binding" for the mobile node. A mobile node 503 typically acquires its care-of address through stateless [27] or 504 stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according 505 to the methods of IPv6 Neighbor Discovery [17]. Other methods 506 of acquiring a care-of address are also possible, such as static 507 pre-assignment by the owner or manager of a particular foreign link, 508 but details of such other methods are beyond the scope of this 509 document. 511 While away from home, a mobile node registers one of its care-of 512 addresses with a router on its home link, requesting this router 513 to function as the "home agent" for the mobile node. This binding 514 registration is done by the mobile node sending to the home agent 515 a packet containing a "Binding Update" destination option; the 516 home agent then replies to the mobile node by returning a packet 517 containing a "Binding Acknowledgement" destination option. The 518 care-of address in this binding registered with its home agent is 519 known as the mobile node's "primary care-of address". The mobile 520 node's home agent thereafter uses proxy Neighbor Discovery to 521 intercept any IPv6 packets addressed to the mobile node's home 522 address (or home addresses) on the home link, and tunnels each 523 intercepted packet to the mobile node's primary care-of address. 524 To tunnel each intercepted packet, the home agent encapsulates the 525 packet using IPv6 encapsulation [4], with the outer IPv6 header 526 addressed to the mobile node's primary care-of address. 528 Section 10.17 discusses the reasons why it may be desirable for 529 a mobile node to use more than one care-of address at the same 530 time. However, a mobile node's primary care-of address is distinct 531 among these in that the home agent maintains only a single care-of 532 address registered for each mobile node, and always tunnels a mobile 533 node's packets intercepted from its home link to this mobile node's 534 registered primary care-of address. The home agent thus need not 535 implement any policy to determine which of possibly many care-of 536 addresses to which to tunnel each intercepted packet, leaving the 537 mobile node entirely in control of this policy by which of its 538 care-of addresses it registers with its home agent. 540 It is possible that while a mobile node is away from home, some nodes 541 on its home link may be reconfigured, such that the router that was 542 operating as the mobile node's home agent is replaced by a different 543 router serving this role. In this case, the mobile node may not 544 know the IP address of its own home agent. Mobile IPv6 provides a 545 mechanism, known as "dynamic home agent address discovery", that 546 allows a mobile node to dynamically discover the IP address of a home 547 agent on its home link with which it may register its care-of address 548 while away from home. The mobile node sends an ICMP "Home Agent 549 Address Discovery Request" message to the "Mobile IPv6 Home-Agents" 550 anycast address for its own home subnet prefix [10] and thus reaches 551 one of the (possibly many) routers on its home link currently 552 operating as a home agent. This home agent then returns an ICMP 553 "Home Agent Address Discovery Reply" message to the mobile node, 554 including a list of home agents on the home link. This list of home 555 agents is maintained by each home agent on the home link through use 556 of the Home Agent (H) bit in each home agent's periodic unsolicited 557 multicast Router Advertisements. 559 The Binding Update and Binding Acknowledgement destination options, 560 together with a "Binding Request" destination option, are also used 561 to allow IPv6 nodes communicating with a mobile node, to dynamically 562 learn and cache the mobile node's binding. When sending a packet 563 to any IPv6 destination, a node checks its cached bindings for an 564 entry for the packet's destination address. If a cached binding for 565 this destination address is found, the node uses an IPv6 Routing 566 header [6] (instead of IPv6 encapsulation) to route the packet to 567 the mobile node by way of the care-of address indicated in this 568 binding. If, instead, the sending node has no cached binding for 569 this destination address, the node sends the packet normally (with 570 no Routing header), and the packet is subsequently intercepted and 571 tunneled by the mobile node's home agent as described above. Any 572 node communicating with a mobile node is referred to in this document 573 as a "correspondent node" of the mobile node, and may itself be 574 either a stationary node or a mobile node. 576 Since a Binding Update, Binding Acknowledgement, and Binding Request 577 are each represented in a packet as an IPv6 destination option [6], 578 they may be included in any IPv6 packet. Any of these options can be 579 sent in either of two ways: 581 - A Binding Update, Binding Acknowledgement, or Binding Request can 582 be included within any IPv6 packet carrying any payload such as 583 TCP [25] or UDP [24]. 585 - A Binding Update, Binding Acknowledgement, or Binding Request can 586 be sent as a separate IPv6 packet containing no payload. In this 587 case, the Next Header field in the last extension header in the 588 packet is set to the value 59, to indicate "No Next Header" [6]. 590 Mobile IPv6 also defines one additional IPv6 destination option. 591 When a mobile node sends a packet while away from home, it will 592 generally set the Source Address in the packet's IPv6 header to one 593 of its current care-of addresses, and will also include a "Home 594 Address" destination option in the packet, giving the mobile node's 595 home address. Many routers implement security policies such as 596 "ingress filtering" [7] that do not allow forwarding of packets that 597 appear to have a Source Address that is not topologically correct. 598 By using the care-of address as the IPv6 header Source Address, 599 the packet will be able to pass normally through such routers, 600 yet ingress filtering rules will still be able to locate the true 601 topological source of the packet in the same way as packets from 602 non-mobile nodes. By also including the Home Address option in each 603 packet, the sending mobile node can communicate its home address to 604 the correspondent node receiving this packet, allowing the use of 605 the care-of address to be transparent above the Mobile IPv6 support 606 level (e.g., at the transport layer). The inclusion of a Home 607 Address option in a packet affects only the correspondent node's 608 receipt of this single packet; no state is created or modified in the 609 correspondent node as a result of receiving a Home Address option in 610 a packet. 612 4.2. New IPv6 Destination Options and ICMP Messages 614 As discussed in general in Section 4.1, the following four new IPv6 615 destination options are defined for Mobile IPv6: 617 Binding Update 619 A Binding Update option is used by a mobile node to notify 620 a correspondent node or the mobile node's home agent of its 621 current binding. The Binding Update sent to the mobile node's 622 home agent to register its primary care-of address is marked 623 as a "home registration". Any packet that includes a Binding 624 Update option MUST be protected by IPsec [13] to guard against 625 malicious Binding Updates. The Binding Update option and 626 its specific IPsec requirements are described in detail in 627 Section 5.1. 629 Binding Acknowledgement 631 A Binding Acknowledgement option is used to acknowledge receipt 632 of a Binding Update, if an acknowledgement was requested 633 in the Binding Update. Any packet that includes a Binding 634 Acknowledgement option MUST be protected by IPsec [13] to 635 guard against malicious Binding Acknowledgements. The Binding 636 Acknowledgement option and its specific IPsec requirements are 637 described in detail in Section 5.2. 639 Binding Request 641 A Binding Request option is used to request a mobile node to 642 send to the requesting node a Binding Update containing the 643 mobile node's current binding. This option is typically used 644 by a correspondent node to refresh a cached binding for a 645 mobile node, when the cached binding is in active use but the 646 binding's lifetime is close to expiration. No authentication 647 is required for the Binding Request option. The Binding 648 Request option is described in detail in Section 5.3. 650 Home Address 652 A Home Address option is used in a packet sent by a mobile 653 node to inform the recipient of that packet of the mobile 654 node's home address. For packets sent by a mobile node while 655 away from home, the mobile node generally uses one of its 656 care-of addresses as the Source Address in the packet's IPv6 657 header. By including a Home Address option in the packet, the 658 correspondent node receiving the packet is able to substitute 659 the mobile node's home address for this care-of address when 660 processing the packet, thus making the use of the care-of 661 address transparent to the correspondent node. If the IP 662 header of a packet carrying a Home Address option is covered 663 by authentication, then the Home Address option MUST also be 664 covered by this authentication, but no other authentication is 665 required for the Home Address option. The Home Address option 666 is described in detail in Section 5.4. 668 Sub-options within the format of these options MAY be included after 669 the fixed portion of the option data specified in this document. The 670 presence of such sub-options will be indicated by the Option Length 671 field within the option. When the Option Length is greater than the 672 length required for the option specified here, the remaining octets 673 are interpreted as sub-options. The encoding and format of defined 674 sub-options are described in Section 5.5. 676 IPv6 requires that options appearing in a Hop-by-Hop Options 677 header or Destination Options header be aligned in a packet so that 678 multi-octet values within the Option Data field of each option fall 679 on natural boundaries (i.e., fields of width n octets are placed 680 at an integer multiple of n octets from the start of the header, 681 for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar 682 alignment requirements, so that multi-octet values within the 683 Sub-Option Data field of each sub-option fall on natural boundaries. 684 The alignment requirement of an option or sub-option is specified in 685 this document using the standard notation used elsewhere for IPv6 686 alignment requirements [6]. Specifically, the notation xn+y means 687 that the Option Type or Sub-Option Type field must fall at an integer 688 multiple of x octets from the start of the header, plus y octets. 689 For example: 691 2n means any 2-octet offset from the start of the header. 693 8n+2 means any 8-octet offset from the start of the header, 694 plus 2 octets. 696 Mobile IPv6 also introduces two new ICMP message types, for use in 697 the dynamic home agent address discovery mechanism. As discussed in 698 general in Section 4.1, the following two new ICMP message types are 699 used: 701 Home Agent Address Discovery Request 703 The ICMP Home Agent Address Discovery Request message is used 704 by a mobile node to initiate the dynamic home agent address 705 discovery mechanism. When attempting a home registration, the 706 mobile node may use this mechanism to discover the address of 707 one or more routers currently operating as home agents on its 708 home link, with which it may register while away from home. 709 The Home Agent Address Discovery Request message is described 710 in detail in Section 5.6. 712 Home Agent Address Discovery Reply 714 The ICMP Home Agent Address Discovery Reply message is used by 715 a home agent to respond to a mobile node using the dynamic home 716 agent address discovery mechanism. When a home agent receives 717 a Home Agent Address Discovery Request message, it replies with 718 a Home Agent Address Discovery Reply message, giving a list 719 of the routers on the mobile node's home link serving as home 720 agents. The Home Agent Address Discovery Reply message is 721 described in detail in Section 5.7. 723 4.3. Conceptual Data Structures 725 This document describes the Mobile IPv6 protocol in terms of the 726 following three conceptual data structures: 728 Binding Cache 730 A cache, maintained by each IPv6 node, of bindings for other 731 nodes. The Binding Cache MAY be implemented in any manner 732 consistent with the external behavior described in this 733 document, for example by being combined with the node's 734 Destination Cache as maintained by Neighbor Discovery [17]. 735 When sending a packet, the Binding Cache is searched before the 736 Neighbor Discovery conceptual Destination Cache [17] (i.e., any 737 Binding Cache entry for this destination SHOULD take precedence 738 over any Destination Cache entry for the same destination). 739 Each Binding Cache entry conceptually contains the following 740 fields: 742 - The home address of the mobile node for which this is the 743 Binding Cache entry. This field is used as the key for 744 searching the Binding Cache for the destination address of 745 a packet being sent. If the destination address of the 746 packet matches the home address in the Binding Cache entry, 747 this entry SHOULD be used in routing that packet. 749 - The care-of address for the mobile node indicated by 750 the home address field in this Binding Cache entry. If 751 the destination address of a packet being routed by a 752 node matches the home address in this entry, the packet 753 SHOULD be routed to this care-of address, as described in 754 Section 8.9, for packets originated by this node, or in 755 Section 9.6, if this node is the mobile node's home agent 756 and the packet was intercepted by it on the home link. 758 - A lifetime value, indicating the remaining lifetime 759 for this Binding Cache entry. The lifetime value is 760 initialized from the Lifetime field in the Binding Update 761 that created or last modified this Binding Cache entry. 762 Once the lifetime on this entry expires, the entry MUST be 763 deleted from the Binding Cache. 765 - A flag indicating whether or not this Binding Cache entry 766 is a "home registration" entry. 768 - A flag indicating whether or not this Binding Cache entry 769 represents a mobile node that should be advertised as a 770 router in proxy Neighbor Advertisements sent by this node 771 on its behalf. This flag is only valid if the Binding 772 Cache entry indicates that this is a "home registration" 773 entry. 775 - The value of the Prefix Length field received in the 776 Binding Update that created or last modified this Binding 777 Cache entry. This field is only valid if the "home 778 registration" flag is set on this Binding Cache entry. 780 - The maximum value of the Sequence Number field received 781 in previous Binding Updates for this mobile node home 782 address. The Sequence Number field is 16 bits long, and 783 all comparisons between Sequence Number values MUST be 784 performed modulo 2**16. 786 - Recent usage information for this Binding Cache entry, as 787 needed to implement the cache replacement policy in use in 788 the Binding Cache and to assist in determining whether a 789 Binding Request should be sent when the lifetime on this 790 entry nears expiration. 792 - The time at which a Binding Request was last sent for this 793 entry, as needed to implement the rate limiting restriction 794 for sending Binding Requests. 796 An entry in a node's Binding Cache for which the node is 797 serving as a home agent is marked as a "home registration" 798 entry and SHOULD NOT be deleted by the home agent until the 799 expiration of its binding lifetime. Other Binding Cache 800 entries MAY be replaced at any time by any reasonable local 801 cache replacement policy but SHOULD NOT be unnecessarily 802 deleted. Any node's Binding Cache may contain at most one 803 entry for each mobile node home address. The contents of a 804 node's Binding Cache MUST NOT be changed in response to a Home 805 Address option in a received packet. 807 Binding Update List 809 A list, maintained by each mobile node, recording information 810 for each Binding Update sent by this mobile node, for which the 811 Lifetime sent in that Binding Update has not yet expired. The 812 Binding Update List includes all bindings sent by the mobile 813 node: those to correspondent nodes, those to the mobile node's 814 home agent, and those to a home agent on the link on which the 815 mobile node's previous care-of address is located. The Binding 816 Update List MAY be implemented in any manner consistent with 817 the external behavior described in this document. Each Binding 818 Update List entry conceptually contains the following fields: 820 - The IP address of the node to which a Binding Update was 821 sent. This node might still have a Binding Cache entry 822 created or updated from this Binding Update, if the Binding 823 Update was successfully received by that node (e.g., not 824 lost by the network) and if that node has not deleted the 825 entry before its expiration (e.g., to reclaim space in its 826 Binding Cache for other entries). 828 - The home address for which that Binding Update was sent. 829 This will be one of the mobile node's home addresses for 830 most Binding Updates (Sections 10.6 and 10.8), but will 831 be the mobile node's previous care-of address for Binding 832 Updates sent to to establish forwarding from by a home 833 agent from this previous care-of address (Section 10.9). 835 - The care-of address sent in that Binding Update. This 836 value is necessary for the mobile node to determine if it 837 has sent a Binding Update giving its new care-of address to 838 this destination after changing its care-of address. 840 - The remaining lifetime of that binding. This lifetime is 841 initialized from the Lifetime value sent in the Binding 842 Update and is decremented until it reaches zero, at which 843 time this entry MUST be deleted from the Binding Update 844 List. 846 - The maximum value of the Sequence Number field sent in 847 previous Binding Updates to this destination. The Sequence 848 Number field is 16 bits long, and all comparisons between 849 Sequence Number values MUST be performed modulo 2**16. 851 - The time at which a Binding Update was last sent to this 852 destination, as needed to implement the rate limiting 853 restriction for sending Binding Updates. 855 - The state of any retransmissions needed for this Binding 856 Update, if the Acknowledge (A) bit was set in this Binding 857 Update. This state includes the time remaining until the 858 next retransmission attempt for the Binding Update, and the 859 current state of the exponential back-off mechanism for 860 retransmissions. 862 - A flag that, when set, indicates that future Binding 863 Updates should not be sent to this destination. The 864 mobile node sets this flag in the Binding Update List 865 entry when it receives an ICMP Parameter Problem, Code 2, 866 error message in response to a Binding Update sent to that 867 destination, as described in Section 10.14. 869 Home Agents List 871 A list, maintained by each home agent and each mobile node, 872 recording information about each home agent from which this 873 node has received a Router Advertisement in which the Home 874 Agent (H) bit is set, for which the remaining lifetime for 875 this list entry (defined below) has not yet expired. The 876 home agents list is thus similar to the Default Router 877 List conceptual data structure maintained by each host for 878 Neighbor Discovery [17], although the Home Agents List MAY be 879 implemented in any manner consistent with the external behavior 880 described in this document. 882 Each home agent maintains a separate Home Agents List for 883 each link on which it is serving as a home agent; this list 884 is used by a home agent in the dynamic home agent address 885 discovery mechanism. Each mobile node, while away from home, 886 also maintains a Home Agents List, to enable it to notify a 887 home agent on its previous link when it moves to a new link; a 888 mobile node MAY maintain a separate Home Agents List for each 889 link to which it is (or has recently) connected, or it MAY 890 maintain a single list for all links. Each Home Agents List 891 entry conceptually contains the following fields: 893 - The link-local IP address of a router on the link, that 894 this node currently believes is operating as a home agent 895 for that link. A new entry is created or an existing 896 entry is updated in the Home Agents List in response to 897 receipt of a valid Router Advertisement in which the Home 898 Agent (H) bit is set. The link-local address of the home 899 agent is learned through the Source Address of the Router 900 Advertisements received from it [17]. 902 - One or more global IP addresses for this home agent, 903 learned through Prefix Information options with the 904 Router Address (R) bit is set, received in Router 905 Advertisements from this link-local address. Global 906 addresses for the router in a Home Agents List entry MUST 907 be deleted once the prefix associated with that address is 908 no longer valid [17]. 910 - The remaining lifetime of this Home Agents List entry. If 911 a Home Agent Information Option is present in a Router 912 Advertisement received from a home agent, the lifetime of 913 the Home Agents List entry representing that home agent 914 is initialized from the Home Agent Lifetime field in the 915 option; otherwise, the lifetime is initialized from the 916 Router Lifetime field in the received Router Advertisement. 917 The Home Agents List entry lifetime is decremented until it 918 reaches zero, at which time this entry MUST be deleted from 919 the Home Agents List. 921 - The preference for this home agent; higher values 922 indicate a more preferable home agent. The preference 923 value is taken from the Home Agent Preference field (a 924 signed, twos-complement integer) in the received Router 925 Advertisement, if the Router Advertisement contains a Home 926 Agent Information Option, and is otherwise set to the 927 default value of 0. A home agent uses this preference in 928 ordering the Home Agents List returned in an ICMP Home 929 Agent Address Discovery message in response to a mobile 930 node's initiation of dynamic home agent address discovery. 931 A mobile node uses this preference in determining which 932 of the home agents on its previous link to notify when it 933 moves to a new link. 935 4.4. Binding Management 937 When a mobile node configures a new care-of address and decides to 938 use this new address as its primary care-of address, the mobile 939 node registers this new binding with its home agent by sending 940 the home agent a Binding Update. The mobile node indicates 941 that an acknowledgement is needed for this Binding Update and 942 continues to periodically retransmit it until acknowledged. The 943 home agent acknowledges the Binding Update by returning a Binding 944 Acknowledgement to the mobile node. 946 When a mobile node receives a packet tunneled to it from its 947 home agent, the mobile node assumes that the original sending 948 correspondent node has no Binding Cache entry for the mobile node, 949 since the correspondent node would otherwise have sent the packet 950 directly to the mobile node using a Routing header. The mobile node 951 thus returns a Binding Update to the correspondent node, allowing 952 it to cache the mobile node's binding for routing future packets to 953 it. Although the mobile node may request an acknowledgement for 954 this Binding Update, it need not, since subsequent packets from the 955 correspondent node will continue to be intercepted and tunneled by 956 the mobile node's home agent, effectively causing any needed Binding 957 Update retransmission. 959 A correspondent node with a Binding Cache entry for a mobile node 960 may refresh this binding, for example if the binding's lifetime 961 is near expiration, by sending a Binding Request to the mobile 962 node. Normally, a correspondent node will only refresh a Binding 963 Cache entry in this way if it is actively communicating with the 964 mobile node and has indications, such as an open TCP connection to 965 the mobile node, that it will continue this communication in the 966 future. When a mobile node receives a Binding Request, it replies by 967 returning a Binding Update to the node sending the Binding Request. 969 A mobile node may use more than one care-of address at the same 970 time, although only one care-of address may be registered for it at 971 its home agent as its primary care-of address. The mobile node's 972 home agent will tunnel all intercepted packets for the mobile node 973 to its (single) registered primary care-of address, but the mobile 974 node will accept packets that it receives at any of its current 975 care-of addresses. Use of more than one care-of address by a mobile 976 node may be useful, for example, to improve smooth handoff when the 977 mobile node moves from one wireless link to another. If each of 978 these wireless links is connected to the Internet through a separate 979 base station, such that the wireless transmission range from the 980 two base stations overlap, the mobile node may be able to remain 981 connected to both links while in the area of overlap. In this case, 982 the mobile node could acquire a new care-of address on the new link 983 before moving out of transmission range and disconnecting from the 984 old link. The mobile node may thus still accept packets at its 985 old care-of address while it works to update its home agent and 986 correspondent nodes, notifying them of its new care-of address on the 987 new link. 989 Since correspondent nodes cache bindings, it is expected that 990 correspondent nodes usually will route packets directly to the mobile 991 node's care-of address, so that the home agent is rarely involved 992 with packet transmission to the mobile node. This is essential for 993 scalability and reliability, and for minimizing overall network load. 994 By caching the care-of address of a mobile node, optimal routing of 995 packets can be achieved from the correspondent node to the mobile 996 node. Routing packets directly to the mobile node's care-of address 997 also eliminates congestion at the mobile node's home agent and home 998 link. In addition, the impact of any possible failure of the home 999 agent, the home link, or intervening networks leading to or from the 1000 home link is reduced, since these nodes and links are not involved in 1001 the delivery of most packets to the mobile node. 1003 5. New IPv6 Destination Options and Message Types 1005 5.1. Binding Update Option 1007 The Binding Update destination option is used by a mobile node 1008 to notify other nodes of a new care-of address for itself. As a 1009 destination option, it MAY be included in any existing packet being 1010 sent to this same destination or MAY be sent in a packet by itself; 1011 a packet containing a Binding Update is sent in the same way as any 1012 packet sent by a mobile node (Section 10.1). 1014 The Binding Update option is encoded in type-length-value (TLV) 1015 format as follows: 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Option Type | Option Length | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 |A|H|R|D|Reservd| Prefix Length | Sequence Number | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Lifetime | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Sub-Options... 1027 +-+-+-+-+-+-+-+-+-+-+-+- 1029 Option Type 1031 198 = 0xC6 1033 Option Length 1035 8-bit unsigned integer. Length of the option, in octets, 1036 excluding the Option Type and Option Length fields. This field 1037 MUST be set to 8 plus the total length of all sub-options 1038 present, including their Sub-Option Type and Sub-Option Len 1039 fields. 1041 Acknowledge (A) 1043 The Acknowledge (A) bit is set by the sending mobile node to 1044 request a Binding Acknowledgement (Section 5.2) be returned 1045 upon receipt of the Binding Update. 1047 Home Registration (H) 1049 The Home Registration (H) bit is set by the sending mobile node 1050 to request the receiving node to act as this node's home agent. 1051 The destination of the packet carrying this option MUST be that 1052 of a router sharing the same subnet prefix as the home address 1053 of the mobile node in the binding (given by the Home Address 1054 field in the Home Address option in the packet). 1056 Router (R) 1058 The Router (R) bit, when set, indicates that the sending 1059 mobile node is a router. This bit is only valid when the 1060 Home Registration (H) bit is also set, and MUST NOT be set 1061 otherwise. This bit is saved in the home agent's "home 1062 registration" Binding Cache entry for the mobile node, and 1063 is copied into the corresponding bit in all proxy Neighbor 1064 Advertisement messages sent on behalf of this mobile node by 1065 the home agent using this Binding Cache entry. 1067 Duplicate Address Detection (D) 1069 The Duplicate Address Detection (D) bit is set by the sending 1070 mobile node to request the receiving node (the mobile node's 1071 home agent) to perform Duplicate Address Detection [27] on 1072 the mobile node's home link for the home address in this 1073 binding. This bit is only valid when the Home Registration (H) 1074 and Acknowledge (A) bits are also set, and MUST NOT be set 1075 otherwise. If the Duplicate Address Detection performed by 1076 the home agent fails, the Status field in the returned Binding 1077 Acknowledgement will be set to 138 (Duplicate Address Detection 1078 failed). 1080 Reservd 1082 This field is unused. It MUST be initialized to zero by the 1083 sender and MUST be ignored by the receiver. 1085 Prefix Length 1087 The Prefix Length field is valid only for a "home registration" 1088 Binding Update; this field MUST be zero if the Home 1089 Registration (H) bit is not set in the Binding Update. The 1090 Prefix Length field is set by the sending mobile node to the 1091 (nonzero) length of its subnet prefix in its home address 1092 (given in the Home Address option in the packet) to request 1093 its home agent to use the interface identifier in the mobile 1094 node's home address (the remaining low-order bits after the 1095 indicated subnet prefix) to form all other home addresses for 1096 the mobile node on the home link. The home agent becomes the 1097 home agent not only for the individual home address given in 1098 this binding, but also for all other home addresses for this 1099 mobile node formed from this interface identifier. That is, 1100 for each on-link prefix on the home link, the home agent uses 1101 the interface identifier to form other valid addresses for 1102 the mobile node on the home link, and acts as a home agent 1103 also for those addresses. In addition, the home agent forms 1104 the link-local address and site-local address corresponding 1105 to this interface identifier, and defends each for purposes 1106 of Duplicate Address Detection; the home agent also performs 1107 Duplicate Address Detection on each such address as part of 1108 the home registration processing, if the Duplicate Address 1109 Detection (D) bit is set in the Binding Update. Details of 1110 this operation are described in Section 9.3. 1112 Sequence Number 1114 Used by the receiving node to sequence Binding Updates and by 1115 the sending node to match a returned Binding Acknowledgement 1116 with this Binding Update. Each Binding Update sent by a mobile 1117 node MUST use a Sequence Number greater than the Sequence 1118 Number value sent in the previous Binding Update (if any) to 1119 the same destination address (modulo 2**16). There is no 1120 requirement, however, that the Sequence Number value strictly 1121 increase by 1 with each new Binding Update sent or received. 1123 Lifetime 1125 32-bit unsigned integer. The number of seconds remaining 1126 before the binding must be considered expired. A value of all 1127 one bits (0xffffffff) indicates infinity. A value of zero 1128 indicates that the Binding Cache entry for the mobile node 1129 should be deleted. 1131 Sub-Options 1133 Additional information, associated with this Binding Update 1134 option, that need not be present in all Binding Updates sent. 1135 This use of sub-options also allows for future extensions to 1136 the format of the Binding Update option to be defined. The 1137 encoding and format of defined sub-options are described in 1138 Section 5.5. The following sub-options are valid in a Binding 1139 Update option: 1141 - Unique Identifier Sub-Option 1143 - Alternate Care-of Address Sub-Option 1145 The alignment requirement [6] for the Binding Update option is 4n+2. 1147 Any packet that includes a Binding Update option MUST also include 1148 a Home Address option. The home address of the mobile node in the 1149 binding given in the Binding Update option is indicated by the Home 1150 Address field in the Home Address option in the packet. 1152 The care-of address for the binding given in the Binding Update 1153 option is normally specified by the Source Address field in the IPv6 1154 header of the packet carrying the Binding Update option. However, a 1155 care-of address different from the Source Address MAY be specified 1156 by including an Alternate Care-of Address sub-option in the Binding 1157 Update option. 1159 Any packet that includes a Binding Update option MUST be protected by 1160 IPsec [13] to guard against malicious Binding Updates. Specifically, 1161 any packet that includes a Binding Update option MUST utilize 1162 IPsec sender authentication, data integrity protection, and replay 1163 protection. Currently, Mobile IPv6 requires that this protection 1164 covering a Binding Update MUST be provided by use of AH [11]; if 1165 another Security Association applied to the packet for other reasons 1166 requires use of ESP [12], the packet MUST use both AH and ESP. Use 1167 of ESP for protecting the Binding Update is not currently defined in 1168 this document, since ESP does not protect the portion of the packet 1169 above the ESP header itself. 1171 If the care-of address for the binding (specified either in an 1172 Alternate Care-of Address sub-option in the Binding Update option, if 1173 present, or in the Source Address field in the packet's IPv6 header) 1174 is equal to the home address of the mobile node, the Binding Update 1175 option indicates that any existing binding for the mobile node MUST 1176 be deleted. Likewise, if the Lifetime field in the Binding Update 1177 option is equal to 0, the Binding Update option indicates that any 1178 existing binding for the mobile node MUST be deleted. In each of 1179 these cases, a Binding Cache entry for the mobile node MUST NOT be 1180 created in response to receiving the Binding Update. 1182 The last Sequence Number value sent to a destination in a Binding 1183 Update is stored by the mobile node in its Binding Update List entry 1184 for that destination; the last Sequence Number value received from 1185 a mobile node in a Binding Update is stored by a correspondent node 1186 in its Binding Cache entry for that mobile node. Thus, the mobile 1187 node's and the correspondent node's knowledge of the last sequence 1188 number expire at the same time. If the sending mobile node has no 1189 Binding Update List entry, the Sequence Number may start at any 1190 value; if the receiving correspondent node has no Binding Cache entry 1191 for the sending mobile node, it MUST accept any Sequence Number value 1192 in a received Binding Update from this mobile node. 1194 The three highest-order bits of the Option Type are encoded to 1195 indicate specific processing of the option [6]. For the Binding 1196 Update option, these three bits are set to 110, indicating that any 1197 IPv6 node processing this option that does not recognize the Option 1198 Type must discard the packet and, only if the packet's Destination 1199 Address was not a multicast address, return an ICMP Parameter 1200 Problem, Code 2, message to the packet's Source Address; and that the 1201 data within the option cannot change en-route to the packet's final 1202 destination. 1204 5.2. Binding Acknowledgement Option 1206 The Binding Acknowledgement destination option is used to acknowledge 1207 receipt of a Binding Update option (Section 5.1). When a node 1208 receives a packet containing a Binding Update option, with this 1209 node being the destination of the packet (only the destination node 1210 processes the option since it is a destination option), this node 1211 MUST return a Binding Acknowledgement to the source of the packet, 1212 if the Acknowledge (A) bit is set in the Binding Update. As a 1213 destination option, this node MAY include the Binding Acknowledgement 1214 in any existing packet being sent to the mobile node or MAY send it 1215 in a packet by itself. A packet containing a Binding Acknowledgement 1216 is sent in the same way as any packet to a mobile node, using a 1217 Routing header to route the packet to the mobile node by way of the 1218 care-of address in the binding (Section 8.9). 1220 The Binding Acknowledgement option is encoded in type-length-value 1221 (TLV) format as follows: 1223 0 1 2 3 1224 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 1225 +-+-+-+-+-+-+-+-+ 1226 | Option Type | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Option Length | Status | Sequence Number | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Lifetime | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Refresh | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Sub-Options... 1235 +-+-+-+-+-+-+-+-+-+-+-+- 1237 Option Type 1239 7 1241 Option Length 1243 8-bit unsigned integer. Length of the option, in octets, 1244 excluding the Option Type and Option Length fields. This field 1245 MUST be set to 11 plus the total length of all sub-options 1246 present, including their Sub-Option Type and Sub-Option Len 1247 fields. 1249 Status 1251 8-bit unsigned integer indicating the disposition of the 1252 Binding Update. Values of the Status field less than 128 1253 indicate that the Binding Update was accepted by the receiving 1254 node. The following such Status values are currently defined: 1256 0 Binding Update accepted 1258 Values of the Status field greater than or equal to 128 1259 indicate that the Binding Update was rejected by the receiving 1260 node. The following such Status values are currently defined: 1262 128 Reason unspecified 1263 130 Administratively prohibited 1264 131 Insufficient resources 1265 132 Home registration not supported 1266 133 Not home subnet 1267 136 Incorrect interface identifier length 1268 137 Not home agent for this mobile node 1269 138 Duplicate Address Detection failed 1271 Up-to-date values of the Status field are to be specified in 1272 the most recent "Assigned Numbers" [26]. 1274 Sequence Number 1276 The Sequence Number in the Binding Acknowledgement is copied 1277 from the Sequence Number field in the Binding Update being 1278 acknowledged, for use by the mobile node in matching this 1279 Acknowledgement with an outstanding Binding Update. 1281 Lifetime 1283 The granted lifetime, in seconds, for which this node will 1284 attempt to retain the entry for this mobile node in its Binding 1285 Cache. If the node sending the Binding Acknowledgement is 1286 serving as the mobile node's home agent, the Lifetime period 1287 also indicates the period for which this node will continue 1288 this service; if the mobile node requires home agent service 1289 from this node beyond this period, the mobile node MUST send a 1290 new Binding Update to it before the expiration of this period 1291 (even if it is not changing its primary care-of address), in 1292 order to extend the lifetime. The value of this field is 1293 undefined if the Status field indicates that the Binding Update 1294 was rejected. 1296 Refresh 1298 The recommended interval, in seconds, at which the mobile 1299 node SHOULD send a new Binding Update to this node in order 1300 to "refresh" the mobile node's binding in this node's Binding 1301 Cache. This refreshing of the binding is useful in case the 1302 node fails and loses its cache state. The Refresh period is 1303 determined by the node sending the Binding Acknowledgement 1304 (the node caching the binding). If this node is serving as 1305 the mobile node's home agent, the Refresh value may be set, 1306 for example, based on whether the node stores its Binding 1307 Cache in volatile storage or in nonvolatile storage. If the 1308 node sending the Binding Acknowledgement is not serving as the 1309 mobile node's home agent, the Refresh period SHOULD be set 1310 equal to the Lifetime period in the Binding Acknowledgement; 1311 even if this node loses this cache entry due to a failure of 1312 the node, packets from it can still reach the mobile node 1313 through the mobile node's home agent, causing a new Binding 1314 Update to this node to allow it to recreate this cache entry. 1315 The value of this field is undefined if the Status field 1316 indicates that the Binding Update was rejected. 1318 Sub-Options 1320 Additional information, associated with this Binding 1321 Acknowledgement option, that need not be present in all Binding 1322 Acknowledgements sent. This use of sub-options also allows for 1323 future extensions to the format of the Binding Acknowledgement 1324 option to be defined. The encoding and format of defined 1325 sub-options are described in Section 5.5. Currently, no valid 1326 sub-options are defined for in a Binding Acknowledgement 1327 option. 1329 The alignment requirement [6] for the Binding Acknowledgement option 1330 is 4n+3. 1332 Any packet that includes a Binding Acknowledgement option MUST 1333 be protected by IPsec [13] to guard against malicious Binding 1334 Acknowledgements. Specifically, any packet that includes a Binding 1335 Acknowledgement option MUST utilize IPsec sender authentication, data 1336 integrity protection, and replay protection. Currently, Mobile IPv6 1337 requires that this protection covering a Binding Acknowledgement 1338 MUST be provided by use of AH [11]; if another Security Association 1339 applied to the packet for other reasons requires use of ESP [12], 1340 the packet MUST use both AH and ESP. Use of ESP for protecting the 1341 Binding Acknowledgement is not currently defined in this document, 1342 since ESP does not protect the portion of the packet above the ESP 1343 header itself. 1345 If the node returning the Binding Acknowledgement accepted the 1346 Binding Update for which the Acknowledgement is being returned (the 1347 value of the Status field in the Acknowledgement is less than 128), 1348 this node will have an entry for the mobile node in its Binding Cache 1349 and MUST use this entry (which includes the care-of address received 1350 in the Binding Update) in sending the packet containing the Binding 1351 Acknowledgement to the mobile node. The details of sending this 1352 packet to the mobile node are the same as for sending any packet to a 1353 mobile node using a binding, and are described in Section 8.9. The 1354 packet is sent using a Routing header, routing the packet to the 1355 mobile node by way of its care-of address recorded in the Binding 1356 Cache entry. 1358 If the node returning the Binding Acknowledgement instead 1359 rejected the Binding Update (the value of the Status field in the 1360 Acknowledgement is greater than or equal to 128), this node MUST 1361 similarly use a Routing header in sending the packet containing the 1362 Binding Acknowledgement, as described in Section 8.9, but MUST NOT 1363 use its Binding Cache in forming the IP header or Routing header 1364 in this packet. Rather, the care-of address used by this node in 1365 sending the packet containing the Binding Acknowledgement MUST be 1366 copied from the care-of address received in the rejected Binding 1367 Update; this node MUST NOT modify its Binding Cache in response 1368 to receiving this rejected Binding Update and MUST ignore its 1369 Binding Cache in sending the packet in which it returns this Binding 1370 Acknowledgement. The packet is sent using a Routing header, routing 1371 the packet to the home address of the rejected Binding Update by 1372 way of the care-of address indicated in the packet containing the 1373 Binding Update. When sending a Binding Acknowledgement to reject a 1374 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 1375 packet containing no payload (with the Next Header field in the last 1376 extension header in the packet set to indicate "No Next Header" [6]). 1378 The three highest-order bits of the Option Type are encoded to 1379 indicate specific processing of the option [6]. For the Binding 1380 Acknowledgement option, these three bits are set to 000, indicating 1381 that any IPv6 node processing this option that does not recognize the 1382 Option Type must skip over this option and continue processing the 1383 header, and that the data within the option cannot change en-route to 1384 the packet's final destination. 1386 5.3. Binding Request Option 1388 The Binding Request destination option is used to request a mobile 1389 node's binding from the mobile node. As a destination option, it 1390 MAY be included in any existing packet being sent to the mobile 1391 node or MAY be sent in a packet by itself; a packet containing a 1392 Binding Request option is sent in the same way as any packet to a 1393 mobile node (Section 8.9). When a mobile node receives a packet 1394 containing a Binding Request option, it SHOULD return a Binding 1395 Update (Section 5.1) to the source of the Binding Request. 1397 The Binding Request option is encoded in type-length-value (TLV) 1398 format as follows: 1400 0 1 1401 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1403 | Option Type | Option Length | Sub-Options... 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1406 Option Type 1408 8 1410 Option Length 1412 8-bit unsigned integer. Length of the option, in octets, 1413 excluding the Option Type and Option Length fields. This field 1414 MUST be set to 0 plus the total length of all sub-options 1415 present, including their Sub-Option Type and Sub-Option Len 1416 fields. 1418 Sub-Options 1420 Additional information, associated with this Binding Request 1421 option, that need not be present in all Binding Requests sent. 1422 This use of sub-options also allows for future extensions to 1423 the format of the Binding Request option to be defined. The 1424 encoding and format of defined sub-options are described in 1425 Section 5.5. The following sub-options are valid in a Binding 1426 Request option: 1428 - Unique Identifier Sub-Option 1430 There is no requirement for alignment [6] of the Binding Request 1431 option. 1433 The three highest-order bits of the Option Type are encoded to 1434 indicate specific processing of the option [6]. For the Binding 1435 Request option, these three bits are set to 000, indicating that any 1436 IPv6 node processing this option that does not recognize the Option 1437 Type must skip over this option and continue processing the header, 1438 and that the data within the option cannot change en-route to the 1439 packet's final destination. 1441 5.4. Home Address Option 1443 The Home Address destination option is used in a packet sent by a 1444 mobile node while away from home, to inform the recipient of that 1445 packet of the mobile node's home address. For packets sent by a 1446 mobile node while away from home, the mobile node generally uses 1447 one of its care-of addresses as the Source Address in the packet's 1448 IPv6 header. By including a Home Address option in the packet, the 1449 correspondent node receiving the packet is able to substitute the 1450 mobile node's home address for this care-of address when processing 1451 the packet, thus making the use of the care-of address transparent to 1452 the correspondent node. 1454 The Home Address option is encoded in type-length-value (TLV) format 1455 as follows: 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Option Type | Option Length | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | | 1463 + + 1464 | | 1465 + Home Address + 1466 | | 1467 + + 1468 | | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Sub-Options... 1471 +-+-+-+-+-+-+-+-+-+-+-+- 1473 Option Type 1475 201 = 0xC9 1477 Option Length 1479 8-bit unsigned integer. Length of the option, in octets, 1480 excluding the Option Type and Option Length fields. This field 1481 MUST be set to 16 plus the total length of all sub-options 1482 present, including their Sub-Option Type and Sub-Option Len 1483 fields. 1485 Home Address 1487 The home address of the mobile node sending the packet. 1489 Sub-Options 1491 Additional information, associated with this Home Address 1492 option, that need not be present in all Home Address options 1493 sent. This use of sub-options also allows for future 1494 extensions to the format of the Home Address option to be 1495 defined. The encoding and format of defined sub-options are 1496 described in Section 5.5. Currently, no valid sub-options are 1497 defined for use in a Home Address option. 1499 The alignment requirement [6] for the Home Address option is 8n+6. 1501 The inclusion of a Home Address option in a packet affects the 1502 receiving node's processing of only this single packet; no state is 1503 created or modified in the receiving node as a result of receiving a 1504 Home Address option in a packet. In particular, the presence of a 1505 Home Address option in a received packet MUST NOT alter the contents 1506 of the receiver's Binding Cache and MUST NOT cause any changes in the 1507 routing of subsequent packets sent by this receiving node. 1509 No authentication of the Home Address option is required, except that 1510 if the IPv6 header of a packet is covered by authentication, then 1511 that authentication MUST also cover the Home Address option; this 1512 coverage is achieved automatically by the definition of the Option 1513 Type code for the Home Address option, since it indicates that the 1514 data within the option cannot change en-route to the packet's final 1515 destination, and thus the option is included in the authentication 1516 computation. If the packet carries no IP authentication, then the 1517 contents of the Home Address option, as well as the Source Address 1518 field or any other field in the IPv6 header, may have been forged or 1519 altered during transit. 1521 Upon receipt of a packet containing a Home Address option, the 1522 receiving node replaces the Source Address in the IPv6 header with 1523 the Home Address in the Home Address option. By requiring that any 1524 authentication of the IPv6 header also cover the Home Address option, 1525 the security of the Source Address field in the IPv6 header is not 1526 compromised by the presence of a Home Address option. Security 1527 issues related to the Home Address option are discussed further in 1528 Section 13. 1530 The three highest-order bits of the Option Type are encoded to 1531 indicate specific processing of the option [6]. For the Home Address 1532 option, these three bits are set to 110, indicating that any IPv6 1533 node processing this option that does not recognize the Option Type 1534 must discard the packet and, only if the packet's Destination Address 1535 was not a multicast address, return an ICMP Parameter Problem, 1536 Code 2, message to the packet's Source Address; and that the data 1537 within the option cannot change en-route to the packet's final 1538 destination. 1540 5.5. Mobile IPv6 Destination Option Sub-Options 1542 In order to allow optional fields that may not be needed in most uses 1543 of any given Mobile IPv6 destination option, and to allow future 1544 extensions to the format of these destination options to be defined, 1545 any of the Mobile IPv6 destination options defined in this document 1546 MAY include one or more sub-options. 1548 Such sub-options are included in the data portion of the destination 1549 option itself, after the fixed portion of the option data specified 1550 for that particular destination option (Sections 5.1 through 5.4). 1551 The presence of such sub-options will be indicated by the Option 1552 Length field. When the Option Length is greater than the standard 1553 length defined for that destination option, the remaining octets are 1554 interpreted as sub-options. 1556 These sub-options are encoded within the remaining space of the 1557 option data for that option, using a type-length-value (TLV) format 1558 as follows: 1560 0 1 2 3 1561 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 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 |Sub-Option Type| Sub-Option Len| Sub-Option Data... 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Sub-Option Type 1568 8-bit identifier of the type of sub-option. In processing a 1569 Mobile IPv6 destination option containing a sub-option for 1570 which the Sub-Option Type value is not recognized by the 1571 receiver, the receiver SHOULD quietly ignore and skip over the 1572 sub-option, correctly handling any remaining sub-options in the 1573 option. 1575 Sub-Option Length 1577 8-bit unsigned integer. Length of the Sub-Option Data field 1578 of this sub-option, in octets. The Sub-Option Len does not 1579 include the length of the Sub-Option Type and Sub-Option Len 1580 fields. 1582 Sub-Option Data 1584 Variable-length field. Sub-Option-Type-specific data. 1586 As with IPv6 options appearing in a Hop-by-Hop Options header 1587 or Destination Options header [6], individual sub-options within 1588 a Mobile IPv6 destination option may have specific alignment 1589 requirements, to ensure that multi-octet values within Sub-Option 1590 Data fields fall on natural boundaries. The alignment requirement 1591 of each sub-option is specified as part of the definition of each 1592 sub-option below. 1594 Each section above defining the Mobile IPv6 destination options 1595 specifies which of the defined sub-options is valid for that 1596 destination option. In addition, there are two padding sub-options, 1597 Pad1 and PadN (defined below), which are used when necessary to align 1598 subsequent sub-options. The Pad1 and PadN sub-options are valid for 1599 all Mobile IPv6 destination options. Unlike the padding options 1600 used in Hop-by-Hop Options header or Destination Options header [6], 1601 there is no requirement for padding the total size of any Mobile IPv6 1602 destination option to a multiple of 8 octets in length, and the 1603 Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All 1604 Mobile IPv6 sub-options defined in this document MUST be recognized 1605 by all Mobile IPv6 implementations. 1607 Currently, the following sub-option types are defined for use in 1608 Mobile IPv6 destination options: 1610 Pad1 Sub-Option (alignment requirement: none) 1612 0 1613 0 1 2 3 4 5 6 7 1614 +-+-+-+-+-+-+-+-+ 1615 | 0 | 1616 +-+-+-+-+-+-+-+-+ 1618 NOTE! the format of the Pad1 sub-option is a special 1619 case -- it does not have Sub-Option Len and Sub-Option Data 1620 fields. 1622 The Pad1 sub-option is used to insert one octet of padding 1623 into the Sub-Options area of a Mobile IPv6 option. If more 1624 than one octet of padding is required, the PadN sub-option, 1625 described next, should be used, rather than multiple Pad1 1626 sub-options. 1628 PadN Sub-Option (alignment requirement: none) 1630 0 1 1631 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1633 | 1 | Sub-Option Len| Sub-Option Data 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1636 The PadN sub-option is used to insert two or more octets of 1637 padding into the Sub-Options area of a Mobile IPv6 option. 1638 For N octets of padding, the Sub-Option Len field contains 1639 the value N-2, and the Sub-Option Data consists of N-2 1640 zero-valued octets. 1642 Unique Identifier Sub-Option (alignment requirement: 2n) 1644 0 1 2 3 1645 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 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | 2 | 2 | Unique Identifier | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 The Unique Identifier sub-option is valid only in Binding 1651 Request and Binding Update destination options. The Unique 1652 Identifier field contains a 16-bit value that serves to 1653 uniquely identify a Binding Request among those sent by this 1654 Source Address, and to allow the Binding Update to identify 1655 the specific Binding Request to which it responds. This 1656 matching of Binding Updates to Binding Requests is required 1657 in the procedure for renumbering the home subnet while a 1658 mobile node is away from home (Section 9.7). 1660 Alternate Care-of Address Sub-Option (alignment requirement: 8n+6) 1662 0 1 2 3 1663 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 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | 4 | 16 | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | | 1668 + + 1669 | | 1670 + Alternate Care-of Addresses + 1671 | | 1672 + + 1673 | | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 The Alternate Care-of Address sub-option is valid only in 1677 Binding Update destination options. The Alternate Care-of 1678 Address field contains an address to use as the care-of 1679 address for the binding, rather than using the Source 1680 Address of the packet as the care-of address. 1682 5.6. ICMP Home Agent Address Discovery Request Message 1684 The ICMP Home Agent Address Discovery Request message is used by a 1685 mobile node to initiate the dynamic home agent address discovery 1686 mechanism, as described in Sections 9.2 and 10.7. The mobile 1687 node sends a Home Agent Address Discovery Request message to the 1688 "Mobile IPv6 Home-Agents" anycast address for its own home subnet 1689 prefix [10], and one of the home agents there responds to the mobile 1690 node with a Home Agent Address Discovery Reply message giving a list 1691 of the routers on the mobile node's home link serving as home agents. 1693 0 1 2 3 1694 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 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Type | Code | Checksum | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Identifier | | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1700 | | 1701 + Reserved + 1702 | | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | | 1705 + + 1706 | | 1707 + Home Address + 1708 | | 1709 + + 1710 | | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 Type 1715 1717 Code 1719 0 1721 Checksum 1723 The ICMP checksum [5]. 1725 Identifier 1727 An identifier to aid in matching Home Agent Address Discovery 1728 Reply messages to this Home Agent Address Discovery Request 1729 message. 1731 Reserved 1733 This field is unused. It MUST be initialized to zero by the 1734 sender and MUST be ignored by the receiver. 1736 Home Address 1738 The home address of the mobile node sending the Home Agent 1739 Address Discovery Request message. 1741 The Source Address of the Home Agent Address Discovery Request 1742 message packet MUST be one of the mobile node's current care-of 1743 addresses, and the mobile node MUST NOT include a Home Address 1744 option in this packet; the home agent then MUST return the Home 1745 Agent Address Discovery Reply message directly to this care-of 1746 address. These restrictions are necessary, since at the time of 1747 performing this dynamic home agent address discovery, the mobile node 1748 is generally not registered with its home agent; using the mobile 1749 node's care-of address simplifies the return of the Reply message to 1750 the mobile node. 1752 5.7. ICMP Home Agent Address Discovery Reply Message 1754 The ICMP Home Agent Address Discovery Reply message is used by a 1755 home agent to respond to a mobile node using the dynamic home agent 1756 address discovery mechanism, as described in Sections 9.2 and 10.7. 1757 The mobile node sends a Home Agent Address Discovery Request message 1758 to the "Mobile IPv6 Home-Agents" anycast address for its own home 1759 subnet prefix [10], and one of the home agents there responds to the 1760 mobile node with a Home Agent Address Discovery Reply message giving 1761 a list of the routers on the mobile node's home link serving as home 1762 agents. 1764 0 1 2 3 1765 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 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | Type | Code | Checksum | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Identifier | | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1771 | | 1772 + Reserved + 1773 | | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | | 1776 + + 1777 . . 1778 . Home Agent Addresses . 1779 . . 1780 + + 1781 | | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 Type 1786 1788 Code 1790 0 1792 Checksum 1794 The ICMP checksum [5]. 1796 Identifier 1798 The identifier from the invoking Home Agent Address Discovery 1799 Request message. 1801 Reserved 1803 This field is unused. It MUST be initialized to zero by the 1804 sender and MUST be ignored by the receiver. 1806 Home Agent Addresses 1808 A list of addresses of home agents on the home link for the 1809 mobile node. The number of addresses present in the list is 1810 indicated by the remaining length of the IPv6 packet carrying 1811 the Home Agent Address Discovery Reply message. 1813 6. Modifications to IPv6 Neighbor Discovery 1815 6.1. Modified Router Advertisement Message Format 1817 Mobile IPv6 modifies the format of the Router Advertisement 1818 message [17] by the addition of a single flag bit to indicate that 1819 the router sending the Advertisement message is serving as a home 1820 agent on this link. The format of the Router Advertisement message 1821 is as follows: 1823 0 1 2 3 1824 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 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | Type | Code | Checksum | 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | Reachable Time | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | Retrans Timer | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Options ... 1835 +-+-+-+-+-+-+-+-+-+-+-+- 1837 This format represents the following changes over that originally 1838 specified for Neighbor Discovery [17]: 1840 Home Agent (H) 1842 The Home Agent (H) bit is set in a Router Advertisement to 1843 indicate that the router sending this Router Advertisement is 1844 also functioning as a Mobile IP home agent on this link. 1846 Reserved 1848 Reduced from a 6-bit field to a 5-bit field to account for the 1849 addition of the Home Agent (H) bit. 1851 6.2. Modified Prefix Information Option Format 1853 Mobile IPv6 requires knowledge of a router's global address for two 1854 reasons: 1856 - To allow a home agent (a router) to learn the address of all 1857 other home agents on the link for which it is providing home 1858 agent service, for use in building its Home Agents List as 1859 part of the dynamic home agent address discovery mechanism 1860 (Sections 9.2 and 10.7). 1862 - To allow a mobile node to send a Binding Update to a router on 1863 the link on which its previous care-of address is located, for 1864 purposes of establishing forwarding from this previous care-of 1865 address to its new care-of address (Section 10.9). 1867 However, Neighbor Discovery [17] only advertises a router's 1868 link-local address, by requiring this address to be used as the IP 1869 Source Address of each Router Advertisement. 1871 Mobile IPv6 extends Neighbor Discovery to allow a router to easily 1872 and efficiently advertise its global address, by the addition of a 1873 single flag bit in the format of a Prefix Information option for 1874 use in Router Advertisement messages. The format of the Prefix 1875 Information option is as follows: 1877 0 1 2 3 1878 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 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Type | Length | Prefix Length |L|A|R|Reserved1| 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | Valid Lifetime | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | Preferred Lifetime | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Reserved2 | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | | 1889 + + 1890 | | 1891 + Prefix + 1892 | | 1893 + + 1894 | | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 This format represents the following changes over that originally 1898 specified for Neighbor Discovery [17]: 1900 Router Address (R) 1902 1-bit router address flag. When set, indicates that the 1903 Prefix field, in addition to advertising the indicated prefix, 1904 contains a complete IP address assigned to the sending router. 1905 This router IP address has the same scope and conforms to the 1906 same lifetime values as the advertised prefix. This use of 1907 the Prefix field is compatible with its use in advertising 1908 the prefix itself, since prefix advertisement uses only the 1909 leading number Prefix bits specified by the Prefix Length 1910 field. Interpretation of this flag bit is thus independent 1911 of the processing required for the On-Link (L) and Autonomous 1912 Address-Configuration (A) flag bits. 1914 Reserved1 1916 Reduced from a 6-bit field to a 5-bit field to account for the 1917 addition of the Router Address (R) bit. 1919 In a solicited Router Advertisement, a router MUST include at least 1920 one Prefix Information option with the Router Address (R) bit set. 1921 Neighbor Discovery specifies that, if including all options in a 1922 Router Advertisement causes the size of the Advertisement to exceed 1923 the link MTU, multiple Advertisements can be sent, each containing 1924 a subset of the options [17]. In this case, at least one of these 1925 multiple Advertisements being sent instead of a single larger 1926 solicited Advertisement, MUST include a Prefix Information option 1927 with the Router Address (R) bit set. 1929 All routers SHOULD include at least one Prefix Information option 1930 with the Router Address (R) bit set, in each unsolicited multicast 1931 Router Advertisement that they send. If multiple Advertisements 1932 are being sent instead of a single larger unsolicited multicast 1933 Advertisement, at least one of these multiple Advertisements SHOULD 1934 include a Prefix Information option with the Router Address (R) bit 1935 set. 1937 6.3. New Advertisement Interval Option Format 1939 Mobile IPv6 defines a new Advertisement Interval option, used in 1940 Router Advertisement messages to advertise the interval at which the 1941 sending router sends unsolicited multicast Router Advertisements. 1942 The format of the Advertisement Interval option is as follows: 1944 0 1 2 3 1945 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 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | Type | Length | Reserved | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Advertisement Interval | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 Type 1954 7 1956 Length 1958 8-bit unsigned integer. The length of the option (including 1959 the type and length fields) in units of 8 octets. The value of 1960 this field MUST be 1. 1962 Reserved 1964 This field is unused. It MUST be initialized to zero by the 1965 sender and MUST be ignored by the receiver. 1967 Advertisement Interval 1969 32-bit unsigned integer. The maximum time, in milliseconds, 1970 between successive unsolicited router Router Advertisement 1971 messages sent by this router on this network interface. Using 1972 the conceptual router configuration variables defined by 1973 Neighbor Discovery [17], this field MUST be equal to the value 1974 MaxRtrAdvInterval, expressed in milliseconds. 1976 Routers MAY include this option in their Router Advertisements. A 1977 mobile node receiving a Router Advertisement containing this option 1978 SHOULD utilize the specified Advertisement Interval for that router 1979 in its movement detection algorithm, as described in Section 10.4. 1981 This option MUST be silently ignored for other Neighbor Discovery 1982 messages. 1984 6.4. New Home Agent Information Option Format 1986 Mobile IPv6 defines a new Home Agent Information option, used in 1987 Router Advertisement messages sent by a home agent to advertise 1988 information specific to this router's functionality as a home agent. 1989 The format of the Home Agent Information option is as follows: 1991 0 1 2 3 1992 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 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | Type | Length | Reserved | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 | Home Agent Preference | Home Agent Lifetime | 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 Type 2001 8 2003 Length 2005 8-bit unsigned integer. The length of the option (including 2006 the type and length fields) in units of 8 octets. The value of 2007 this field MUST be 1. 2009 Reserved 2011 This field is unused. It MUST be initialized to zero by the 2012 sender and MUST be ignored by the receiver. 2014 Home Agent Preference 2016 16-bit signed, twos-complement integer. The preference for 2017 the home agent sending this Router Advertisement, for use in 2018 ordering the addresses returned to a mobile node in the Home 2019 Agent Addresses field of a Home Agent Address Discovery Reply 2020 message. higher values mean more preferable. If this option 2021 is not included in a Router Advertisement in which the Home 2022 Agent (H) bit is set, the preference value for this home agent 2023 SHOULD be considered to be 0. Values greater than 0 indicate a 2024 home agent more preferable than this default value, and values 2025 less than 0 indicate a less preferable home agent. 2027 In addition to the manual configuration of the Home Agent 2028 Preference value as described in Section 7.3, the Home Agent 2029 Preference sent by a home agent could be set dynamically by the 2030 sending home agent, for example based on the number of mobile 2031 nodes it is currently serving or on its remaining resources for 2032 serving additional mobile nodes, but such dynamic settings are 2033 beyond the scope of this document. Any such dynamic setting 2034 of the Home Agent Preference, however, MUST be careful to set 2035 the preference appropriately, relative to the default Home 2036 Agent Preference value of 0 that may be in use by some home 2037 agents on this link (i.e., a home agent not including a Home 2038 Agent Information option in its Router Advertisements will be 2039 considered to have a Home Agent Preference value of 0). 2041 Home Agent Lifetime 2043 16-bit unsigned integer. The lifetime associated with the home 2044 agent in units of seconds. The maximum value corresponds to 2045 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 2046 Lifetime applies only to this router's usefulness as a home 2047 agent; it does not apply to information contained in other 2048 message fields or options. If this option is not included in 2049 a Router Advertisement in which the Home Agent (H) bit is set, 2050 the lifetime for this home agent SHOULD be considered to be the 2051 same as the Router Lifetime specified in the main body of the 2052 Router Advertisement message. 2054 Home agents MAY include this option in their Router Advertisements. 2055 This option MUST NOT be included in a Router Advertisement in which 2056 the Home Agent (H) bit (Section 6.1) is not set. 2058 This option MUST be silently ignored for other Neighbor Discovery 2059 messages. 2061 If both the Home Agent Preference and Home Agent Lifetime are set 2062 to their default values specified above, this option SHOULD NOT be 2063 included in the Router Advertisement messages sent by this home 2064 agent. 2066 6.5. Changes to Sending Router Advertisements 2068 The Neighbor Discovery protocol specification [17] limits routers to 2069 a minimum interval of 3 seconds between sending unsolicited multicast 2070 Router Advertisement messages from any given network interface 2071 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 2073 "Routers generate Router Advertisements frequently enough 2074 that hosts will learn of their presence within a few 2075 minutes, but not frequently enough to rely on an absence 2076 of advertisements to detect router failure; a separate 2077 Neighbor Unreachability Detection algorithm provides failure 2078 detection." 2080 This limitation, however, is not suitable to providing timely 2081 movement detection for mobile nodes. Mobile nodes detect their 2082 own movement by learning the presence of new routers as the mobile 2083 node moves into wireless transmission range of them (or physically 2084 connects to a new wired network), and by learning that previous 2085 routers are no longer reachable. Mobile nodes MUST be able to 2086 quickly detect when they move to a link served by a new router, so 2087 that they can acquire a new care-of address and send Binding Updates 2088 to register this care-of address with their home agent and to notify 2089 correspondent nodes as needed. 2091 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 2092 this limit such that routers MAY send unsolicited multicast Router 2093 Advertisements more frequently. In particular, on network interfaces 2094 where the router is expecting to provide service to visiting mobile 2095 nodes (e.g., wireless network interfaces), or on which it is serving 2096 as a home agent to one or more mobile nodes (who may return home and 2097 need to hear its Advertisements), the home agent SHOULD be configured 2098 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 2099 to allow sending of unsolicited multicast Router Advertisements more 2100 often. Recommended values for these limits are: 2102 - MinRtrAdvInterval 0.5 seconds 2104 - MaxRtrAdvInterval 1.5 seconds 2106 Use of these modified limits MUST be configurable, and specific 2107 knowledge of the type of network interface in use SHOULD be taken 2108 into account in configuring these limits for each network interface. 2110 When sending unsolicited multicast Router Advertisements more 2111 frequently than the standard limit on unsolicited multicast 2112 Advertisement frequency, the sending router need not include all 2113 options in each of these Advertisements, but it SHOULD include at 2114 least one Prefix Information option with the Router Address (R) bit 2115 set (Section 6.2) in each. 2117 6.6. Changes to Sending Router Solicitations 2119 In addition to the limit on routers sending unsolicited multicast 2120 Router Advertisement messages (Section 6.5), Neighbor Discovery 2121 defines limits on nodes sending Router Solicitation messages, such 2122 that a node SHOULD send no more than 3 Router Solicitations, and that 2123 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 2124 However, these limits prevent a mobile node from finding a new 2125 default router (and thus a new care-of address) quickly as it moves 2126 about. 2128 Mobile IPv6 relaxes this limit such that, while a mobile node is away 2129 from home, it MAY send Router Solicitations more frequently. The 2130 following limits for sending Router Solicitations are recommended for 2131 mobile nodes while away from home: 2133 - A mobile node that is not configured with any current care-of 2134 address (e.g., the mobile node has moved since its previous 2135 care-of address was configured), MAY send more than the defined 2136 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 2137 Solicitations. 2139 - The rate at which a mobile node sends Router Solicitations MUST 2140 be limited, although a mobile node MAY send Router Solicitations 2141 more frequently than the defined Neighbor Discovery limit of 2142 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 2143 be configurable, and specific knowledge of the type of network 2144 interface in use SHOULD be taken into account in configuring this 2145 limit for each network interface. A recommended minimum interval 2146 is 1 second. 2148 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 2149 a mobile node MUST reduce the rate at which it sends subsequent 2150 Router Solicitations. Subsequent Router Solicitations SHOULD 2151 be sent using a binary exponential backoff mechanism, doubling 2152 the interval between consecutive Router Solicitations, up to a 2153 maximum interval. The maximum interval MUST be configurable and 2154 SHOULD be chosen appropriately based on the characteristics of 2155 the type of network interface in use. 2157 - While still searching for a new default router and care-of 2158 address, a mobile node MUST NOT increase the rate at which it 2159 sends Router Solicitations unless it has received a positive 2160 indication (such as from lower network layers) that it has moved 2161 to a new link. After successfully acquiring a new care-of 2162 address, the mobile node SHOULD also increase the rate at which 2163 it will send Router Solicitations when it next begins searching 2164 for a new default router and care-of address. 2166 - A mobile node that is currently configured with a care-of 2167 address SHOULD NOT send Router Solicitations, until its movement 2168 detection algorithm (Section 10.4) determines that it has moved 2169 and that its current care-of address might no longer be valid. 2171 7. Requirements for IPv6 Nodes 2173 Mobile IPv6 places some special requirements on the functions 2174 provided by different types of IPv6 nodes. This section summarizes 2175 those requirements, identifying the functionality each requirement 2176 is intended to support. Further details on this functionality is 2177 provided in the following sections. 2179 7.1. Requirements for All IPv6 Hosts and Routers 2181 Since any IPv6 node may at any time be a correspondent node of a 2182 mobile node, either sending a packet to a mobile node or receiving a 2183 packet from a mobile node, the following requirements apply to ALL 2184 IPv6 nodes (whether host or router, whether mobile or stationary): 2186 - Every IPv6 node MUST be able to process a Home Address option 2187 received in any IPv6 packet. 2189 - Every IPv6 node SHOULD be able to process a Binding Update option 2190 received in a packet, and to return a Binding Acknowledgement 2191 option if the Acknowledge (A) bit is set in the received Binding 2192 Update. 2194 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 2195 bindings received in accepted Binding Updates. 2197 7.2. Requirements for All IPv6 Routers 2199 The following requirements apply to all IPv6 routers, even those not 2200 serving as a home agent for Mobile IPv6: 2202 - Every IPv6 router SHOULD be able to send an Advertisement 2203 Interval option in its Router Advertisements, to aid movement 2204 detection by mobile nodes. The use of this option in Router 2205 Advertisements MUST be configurable. 2207 - Every IPv6 router SHOULD be able to support sending unsolicited 2208 multicast Router Advertisements at the faster rate described in 2209 Section 6.5. The use of this faster rate MUST be configurable. 2211 7.3. Requirements for IPv6 Home Agents 2213 In order for a mobile node to operate correctly while away from home, 2214 at least one IPv6 router on the mobile node's home link must function 2215 as a home agent for the mobile node. The following additional 2216 requirements apply to all IPv6 routers capable of serving as a home 2217 agent: 2219 - Every home agent MUST be able to maintain an entry in its Binding 2220 Cache for each mobile node for which it is serving as the home 2221 agent. Each such Binding Cache entry records the mobile node's 2222 binding with its primary care-of address and is marked as a "home 2223 registration". 2225 - Every home agent MUST be able to intercept packets (using proxy 2226 Neighbor Discovery) addressed to a mobile node for which it is 2227 currently serving as the home agent, on that mobile node's home 2228 link, while the mobile node is away from home. 2230 - Every home agent MUST be able to encapsulate such intercepted 2231 packets in order to tunnel them to the primary care-of address 2232 for the mobile node indicated in its binding in the home agent's 2233 Binding Cache. 2235 - Every home agent MUST be able to return a Binding Acknowledgement 2236 option in response to a Binding Update option received with the 2237 Acknowledge (A) bit set. 2239 - Every home agent MUST maintain a separate Home Agents List for 2240 each link on which it is serving as a home agent, as described in 2241 Section 4.3. 2243 - Every home agent MUST be able to accept packets addressed to 2244 the "Mobile IPv6 Home-Agents" anycast address for the subnet 2245 on which it is serving as a home agent [10], and MUST be 2246 able to participate in dynamic home agent address discovery 2247 (Section 9.2). 2249 - Every home agent SHOULD support a configuration mechanism to 2250 allow a system administrator to manually set the value to be sent 2251 by this home agent in the Home Agent Preference field of the Home 2252 Agent Information Option in Router Advertisements that it sends. 2254 7.4. Requirements for IPv6 Mobile Nodes 2256 Finally, the following requirements apply to all IPv6 nodes capable 2257 of functioning as mobile nodes: 2259 - Every IPv6 mobile node MUST be able to perform IPv6 2260 decapsulation [4]. 2262 - Every IPv6 mobile node MUST support sending Binding Update 2263 options, as specified in Sections 10.6, 10.8, and 10.9; and MUST 2264 be able to receive and process Binding Acknowledgement options, 2265 as specified in Section 10.12. 2267 - Every IPv6 mobile node MUST support use of the dynamic home agent 2268 address discovery mechanism, as described in Section 10.7. 2270 - Every IPv6 mobile node MUST maintain a Binding Update List in 2271 which it records the IP address of each other node to which it 2272 has sent a Binding Update, for which the Lifetime sent in that 2273 binding has not yet expired. 2275 - Every IPv6 mobile node MUST support receiving a Binding Request 2276 option, by responding with a Binding Update option. 2278 - Every IPv6 mobile node MUST support sending packets containing a 2279 Home Address option; this option MUST be included in all packets 2280 sent while away from home, if the packet would otherwise have 2281 been sent with the mobile node's home address as the IP Source 2282 Address. 2284 - Every IPv6 mobile node MUST maintain a Home Agents List, as 2285 described in Section 4.3. 2287 8. Correspondent Node Operation 2289 A correspondent node is any node communicating with a mobile node. 2290 The correspondent node, itself, may be stationary or mobile, and may 2291 possibly also be functioning as a home agent for Mobile IPv6. The 2292 procedures in this section thus apply to all IPv6 nodes. 2294 8.1. Receiving Packets from a Mobile Node 2296 Packets sent by a mobile node while away from home generally include 2297 a Home Address option. When any node receives a packet containing 2298 a Home Address option, it MUST process the option in a manner 2299 consistent with copying the Home Address field from the Home Address 2300 option into the IPv6 header, replacing the original value of the 2301 Source Address field there. However, any actual modifications to 2302 the Source Address field in the packet's IPv6 header MUST not be 2303 performed until after all processing of other options contained in 2304 this same Destination Options extension header is completed. 2306 Further processing of such a packet after option processing (e.g., 2307 at the transport layer) thus need not know that the original Source 2308 Address was a care-of address, or that the Home Address option was 2309 used in the packet. Since the sending mobile node uses its home 2310 address at the transport layer when sending such a packet, the use of 2311 the care-of address and Home Address option is transparent to both 2312 the mobile node and the correspondent node above the level of the 2313 Home Address option generation and processing. 2315 8.2. Receiving Binding Updates 2317 Upon receiving a Binding Update option in some packet, the receiving 2318 node MUST validate the Binding Update according to the following 2319 tests: 2321 - The packet meets the specific IPsec requirements for Binding 2322 Updates, defined in Section 5.1. 2324 - The packet MUST contain a valid Home Address option. The home 2325 address for the binding is specified by the Home Address field of 2326 the Home Address option. 2328 - The Option Length field in the Binding Update option is greater 2329 than or equal to the length specified in Section 5.1. 2331 - The Sequence Number field in the Binding Update option is greater 2332 than the Sequence Number received in the previous Binding Update 2333 for this home address, if any. The Sequence Number comparison is 2334 performed modulo 2**16. 2336 Any Binding Update not satisfying all of these tests MUST be 2337 silently ignored, and the packet carrying the Binding Update MUST be 2338 discarded. 2340 If the Binding Update is valid according to the tests above, then the 2341 Binding Update is processed further as follows: 2343 - If the Lifetime specified in the Binding Update is nonzero and 2344 the specified Care-of Address is not equal to the home address 2345 for the binding (as given in the Home Address option in the 2346 packet), then this is a request to cache a binding for the 2347 mobile node. If the Home Registration (H) bit is set in the 2348 Binding Update, the Binding Update is processed according to the 2349 procedure specified in Section 9.3; otherwise, it is processed 2350 according to the procedure specified in Section 8.3. 2352 - If the Lifetime specified in the Binding Update is zero or the 2353 specified Care-of Address matches the home address for the 2354 binding, then this is a request to delete the mobile node's 2355 cached binding. If the Home Registration (H) bit is set in the 2356 Binding Update, the Binding Update is processed according to the 2357 procedure specified in Section 9.4; otherwise, it is processed 2358 according to the procedure specified in Section 8.4. 2360 8.3. Requests to Cache a Binding 2362 When a node receives a Binding Update, it MUST validate it and 2363 determine the type of Binding Update according to the steps described 2364 in Section 8.2. This section describes the processing of a valid 2365 Binding Update that requests a node to cache a mobile node's binding, 2366 for which the Home Registration (H) bit is not set in the Binding 2367 Update. 2369 In this case, the receiving node SHOULD create a new entry in its 2370 Binding Cache for this mobile node (or update its existing Binding 2371 Cache entry for this mobile node, if such an entry already exists). 2372 The home address of the mobile node is taken from the Home Address 2373 field in the packet's Home Address option. The new Binding Cache 2374 entry records the association between this home address and the 2375 care-of address for the binding, as specified in either the Care-of 2376 Address field of the Binding Update or in the Source Address field 2377 in the packet's IPv6 header. Any Binding Cache entry created or 2378 updated in response to processing this Binding Update MUST be deleted 2379 after the expiration of the Lifetime period specified in the Binding 2380 Update. 2382 8.4. Requests to Delete a Binding 2384 When a node receives a Binding Update, it MUST validate it and 2385 determine the type of Binding Update according to the steps described 2386 in Section 8.2. This section describes the processing of a valid 2387 Binding Update that requests a node to delete a mobile node's binding 2388 from its Binding Cache, for which the Home Registration (H) bit is 2389 not set in the Binding Update. 2391 In this case, the receiving node MUST delete any existing entry in 2392 its Binding Cache for this mobile node. The home address of the 2393 mobile node is taken from the Home Address field in the packet's Home 2394 Address option. 2396 8.5. Sending Binding Acknowledgements 2398 When any node receives a packet containing a Binding Update option 2399 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 2400 Acknowledgement option acknowledging receipt of the Binding Update. 2401 If the node accepts the Binding Update and creates or updates an 2402 entry in its Binding Cache for this binding, the Status field in 2403 the Binding Acknowledgement MUST be set to a value less than 128; 2404 if the node rejects the Binding Update and does not create or 2405 update an entry for this binding, the Status field in the Binding 2406 Acknowledgement MUST be set to a value greater than or equal to 128. 2407 Specific values for the Status field are described in Section 5.2 and 2408 in the most recent "Assigned Numbers" [26]. 2410 The packet in which the Binding Acknowledgement is returned MUST meet 2411 the specific IPsec requirements for Binding Acknowledgements, defined 2412 in Section 5.2; and the packet MUST be sent using a Routing header 2413 in the same way as any other packet sent to a mobile node using a 2414 care-of address (even if the binding was rejected), as described 2415 in Section 8.9. The packet is routed first to the care-of address 2416 contained in the Binding Update being acknowledged, and then to the 2417 mobile node's home address. This use of the Routing header ensures 2418 that the Binding Acknowledgement will be routed to the current 2419 location of the node sending the Binding Update, whether the Binding 2420 Update was accepted or rejected. 2422 8.6. Sending Binding Requests 2424 Entries in a node's Binding Cache MUST be deleted when their lifetime 2425 expires. If such an entry is still in active use in sending packets 2426 to a mobile node, the next packet sent to the mobile node will be 2427 routed normally to the mobile node's home link, where it will be 2428 intercepted and tunneled to the mobile node. The mobile node will 2429 then return a Binding Update to the sender, allowing it to create 2430 a new Binding Cache entry for sending future packets to the mobile 2431 node. Communication with the mobile node continues uninterrupted, 2432 but the forwarding of this packet through the mobile node's home 2433 agent creates additional overhead and latency in delivering packets 2434 to the mobile node. 2436 If the sender knows that the Binding Cache entry is still in active 2437 use, it MAY send a Binding Request option to the mobile node in 2438 an attempt to avoid this overhead and latency due to deleting and 2439 recreating the Binding Cache entry. Since a Binding Request is a 2440 destination option, it may, for example, be included in any packet 2441 already being sent to the mobile node, such as a packet that is part 2442 of ongoing TCP communication with the mobile node. When the mobile 2443 node receives a packet from some sender containing a Binding Request 2444 option, it returns a Binding Update option to that sender, giving its 2445 current binding and a new lifetime. 2447 8.7. Cache Replacement Policy 2449 Any entry in a node's Binding Cache MUST be deleted after the 2450 expiration of the Lifetime specified in the Binding Update from 2451 which the entry was created or last updated. Conceptually, a node 2452 maintains a separate timer for each entry in its Binding Cache. When 2453 creating or updating a Binding Cache entry in response to a received 2454 and accepted Binding Update, the node sets the timer for this entry 2455 to the specified Lifetime period. When a Binding Cache entry's timer 2456 expires, the node deletes the entry. 2458 Each node's Binding Cache will, by necessity, have a finite size. 2459 A node MAY use any reasonable local policy for managing the space 2460 within its Binding Cache, except that any entry marked as a "home 2461 registration" (Section 9.3) MUST NOT be deleted from the cache until 2462 the expiration of its lifetime period. When attempting to add a 2463 new "home registration" entry in response to a Binding Update with 2464 the Home Registration (H) bit set, if insufficient space exists (or 2465 can be reclaimed) in the node's Binding Cache, the node MUST reject 2466 the Binding Update and SHOULD return a Binding Acknowledgement to 2467 the sending mobile node, in which the Status field is set to 131 2468 (insufficient resources). When otherwise attempting to add a new 2469 entry to its Binding Cache, a node MAY, if needed, choose to drop any 2470 entry already in its Binding Cache, other than a "home registration" 2471 entry, in order to make space for the new entry. For example, a 2472 "least-recently used" (LRU) strategy for cache entry replacement 2473 among entries not marked as a "home registration" is likely to work 2474 well. 2476 Any binding dropped from a node's Binding Cache due to lack of cache 2477 space will be rediscovered and a new cache entry created, if the 2478 binding is still in active use by the node for sending packets. If 2479 the node sends a packet to a destination for which it has dropped the 2480 entry from its Binding Cache, the packet will be routed normally, 2481 leading to the mobile node's home link. There, the packet will be 2482 intercepted by the mobile node's home agent and tunneled to the 2483 mobile node's current primary care-of address. As when a Binding 2484 Cache entry is initially created, this indirect routing to the mobile 2485 node through its home agent will result in the mobile node sending 2486 a Binding Update to this sending node when it receives the tunneled 2487 packet, allowing it to add an entry again for this destination mobile 2488 node to its Binding Cache. 2490 8.8. Receiving ICMP Error Messages 2492 When a correspondent node sends a packet to a mobile node, if the 2493 correspondent node has a Binding Cache entry for the destination 2494 address of the packet, then the correspondent node uses a Routing 2495 header to deliver the packet to the mobile node through the care-of 2496 address in the binding recorded in the Binding Cache entry. Any ICMP 2497 error message caused by the packet on its way to the mobile node will 2498 be returned normally to the correspondent node. 2500 On the other hand, if the correspondent node has no Binding Cache 2501 entry for the mobile node, the packet will be routed to the mobile 2502 node's home link. There, it will be intercepted by the mobile node's 2503 home agent, encapsulated, and tunneled to the mobile node's primary 2504 care-of address. Any ICMP error message caused by the packet on 2505 its way to the mobile node while in the tunnel, will be returned to 2506 the mobile node's home agent (the source of the tunnel). By the 2507 definition of IPv6 encapsulation [4], this encapsulating node MUST 2508 relay certain ICMP error messages back to the original sender of the 2509 packet, which in this case is the correspondent node. 2511 Likewise, if a packet for a mobile node arrives at the mobile node's 2512 previous link and is intercepted there by a home agent for the mobile 2513 node's previous care-of address as described in Section 10.9 (e.g., 2514 the mobile node moved after the packet was sent), that home agent 2515 will encapsulate and tunnel the packet to the mobile node's new 2516 care-of address. As above, any ICMP error message caused by the 2517 packet while in this tunnel will be returned to that home agent (the 2518 source of the tunnel), which MUST relay certain ICMP error messages 2519 back to the correspondent node [4]. 2521 Thus, in all cases, any meaningful ICMP error messages caused 2522 by packets from a correspondent node to a mobile node will be 2523 returned to the correspondent node. If the correspondent node 2524 receives persistent ICMP Destination Unreachable messages after 2525 sending packets to a mobile node based on an entry in its Binding 2526 Cache, the correspondent node SHOULD delete this Binding Cache 2527 entry. If the correspondent node subsequently transmits another 2528 packet to the mobile node, the packet will be routed to the mobile 2529 node's home link, intercepted by the mobile node's home agent, and 2530 tunneled to the mobile node's primary care-of address using IPv6 2531 encapsulation. The mobile node will then return a Binding Update to 2532 the correspondent node, allowing it to recreate a (correct) Binding 2533 Cache entry for the mobile node. 2535 8.9. Sending Packets to a Mobile Node 2537 Before sending any packet, the sending node SHOULD examine its 2538 Binding Cache for an entry for the destination address to which the 2539 packet is being sent. If the sending node has a Binding Cache entry 2540 for this address, the sending node SHOULD use a Routing header to 2541 route the packet to this mobile node (the destination node) by way 2542 of the care-of address in the binding recorded in that Binding Cache 2543 entry. For example, assuming use of a Type 0 Routing header [6], if 2544 no other use of a Routing header is involved in the routing of this 2545 packet, the mobile node sets the fields in the packet's IPv6 header 2546 and Routing header as follows: 2548 - The Destination Address in the packet's IPv6 header is set to 2549 the mobile node's care-of address copied from the Binding Cache 2550 entry. 2552 - The Routing header is initialized to contain a single route 2553 segment, with an Address of the mobile node's home address (the 2554 original destination address to which the packet was being sent). 2556 Following the definition of a Type 0 Routing header [6], this packet 2557 will be routed to the mobile node's care-of address, where it will 2558 be delivered to the mobile node (the mobile node has associated the 2559 care-of address with its network interface). Normal processing of 2560 the Routing header by the mobile node will then proceed as follows: 2562 - The mobile node swaps the Destination Address in the packet's 2563 IPv6 header and the Address specified in the Routing header. 2564 This results in the packet's IP Destination Address being set to 2565 the mobile node's home address. 2567 - The mobile node then resubmits the packet to its IPv6 module for 2568 further processing, "looping back" the packet inside the mobile 2569 node. Since the mobile node recognizes its own home address as 2570 one of its current IP addresses, the packet is processed further 2571 within the mobile node, in the same way then as if the mobile 2572 node was at home. 2574 If, instead, the sending node has no Binding Cache entry for the 2575 destination address to which the packet is being sent, the sending 2576 node simply sends the packet normally, with no Routing header. If 2577 the destination node is not a mobile node (or is a mobile node that 2578 is currently at home), the packet will be delivered directly to this 2579 node and processed normally by it. If, however, the destination node 2580 is a mobile node that is currently away from home, the packet will 2581 be intercepted by the mobile node's home agent and tunneled (using 2582 IPv6 encapsulation [4]) to the mobile node's current primary care-of 2583 address, as described in Section 9.6. The mobile node will then send 2584 a Binding Update to the sending node, as described in Section 10.8, 2585 allowing the sending node to create a Binding Cache entry for its use 2586 in sending subsequent packets to this mobile node. 2588 9. Home Agent Operation 2590 9.1. Receiving Router Advertisement Messages 2592 For each link on which a router provides service as a home agent, the 2593 router maintains a Home Agents List recording information about all 2594 other home agents on that link. This list is used in the dynamic 2595 home agent address discovery mechanism, described in Section 9.2. 2596 The information for the list is learned through receipt of the 2597 periodic unsolicited multicast Router Advertisements from each other 2598 home agent on the link, in which the Home Agent (H) bit is set, in a 2599 manner similar to the Default Router List conceptual data structure 2600 maintained by each host for Neighbor Discovery [17]. 2602 On receipt of a valid Router Advertisement, as defined in the 2603 processing algorithm specified for Neighbor Discovery [17], the home 2604 agent performs the following steps, in addition to any steps already 2605 required of it by Neighbor Discovery: 2607 - If the Home Agent (H) bit in the Router Advertisement is not set, 2608 skip all of the following steps. There are no special processing 2609 steps required by Mobile IP for this Router Advertisement, since 2610 the Advertisement was not sent by a home agent. 2612 - Otherwise, extract the Source Address from the IP header of the 2613 Router Advertisement. This is the link-local IP address on this 2614 link of the home agent sending this Advertisement [17]. 2616 - Determine from the Router Advertisement the preference for this 2617 home agent. If the Router Advertisement contains a Home Agent 2618 Information Option, then the preference is taken from the Home 2619 Agent Preference field in the option; otherwise, the default 2620 preference of 0 SHOULD be used. 2622 - Determine from the Router Advertisement the lifetime for 2623 this home agent. If the Router Advertisement contains a Home 2624 Agent Information Option, then the lifetime is taken from 2625 the Home Agent Lifetime field in the option; otherwise, the 2626 lifetime specified by the Router Lifetime field in the Router 2627 Advertisement SHOULD be used. 2629 - If the link-local address of the home agent sending this 2630 Advertisement is already present in this home agent's Home 2631 Agents List and the received home agent lifetime value is zero, 2632 immediately delete this entry in the Home Agents List. 2634 - Otherwise, if the link-local address of the home agent sending 2635 this Advertisement is already present in the receiving home 2636 agent's Home Agents List, reset its lifetime and preference to 2637 the values determined above. 2639 - If the link-local address of the home agent sending this 2640 Advertisement, as determined above, is not already present in 2641 the Home Agents List maintained by the receiving home agent, and 2642 the lifetime for the sending home agent, as determined above, 2643 is non-zero, create a new entry in the list, and initialize its 2644 lifetime and preference to the values determined above. 2646 - If the Home Agents List entry for the link-local address of 2647 the home agent sending this Advertisement was not deleted as 2648 described above, determine any global address(es) of the home 2649 agent based on each Prefix Information option received in 2650 this Advertisement in which the Router Address (R) bit is set 2651 (Section 6.2). For each such global address determined from this 2652 Advertisement, add this global address to the list of global 2653 addresses for this home agent in this Home Agents List entry. 2655 A home agent SHOULD maintain an entry in its Home Agents List for 2656 each such valid home agent address until that entry's lifetime 2657 expires, after which time the entry MUST be deleted. 2659 9.2. Dynamic Home Agent Address Discovery 2661 A mobile node, while away from home, MAY use the dynamic home agent 2662 address discovery mechanism to attempt to discover the address of 2663 one or more routers serving as home agents on its home link. This 2664 discovery may be necessary, for example, if some nodes on its home 2665 link have been reconfigured while the mobile node has been away from 2666 home, such that the router that was operating as the mobile node's 2667 home agent has been replaced by a different router serving this role. 2669 As described in Section 10.7, a mobile node attempts dynamic home 2670 agent address discovery by sending an ICMP Home Agent Address 2671 Discovery Request message to the "Mobile IPv6 Home-Agents" anycast 2672 address [10] for its home IP subnet prefix, using its care-of address 2673 as the Source Address of the packet. A home agent receiving such a 2674 Home Agent Address Discovery Request message that is serving this 2675 subnet (the home agent is configured with this anycast address on one 2676 of its network interfaces) SHOULD return an ICMP Home Agent Address 2677 Discovery Reply message to the mobile node (at its care-of address 2678 that was used as the Source Address of the Request message), with the 2679 Source Address of the Reply packet set to one of the global unicast 2680 addresses of the home agent. The Home Agent Addresses field in the 2681 Reply message is constructed as follows: 2683 - The Home Agent Addresses field SHOULD contain one global IP 2684 address for each home agent currently listed in this home 2685 agent's own Home Agents List (Section 4.3). However, if this 2686 home agent's own global IP address would be placed in the list 2687 (as described below) as the first entry in the list, then this 2688 home agent SHOULD NOT include its own address in the Home Agent 2689 Addresses field in the Reply message. Not placing this home 2690 agent's own IP address in the list will cause the receiving 2691 mobile node to consider this home agent as the most preferred 2692 home agent; otherwise, this home agent will be considered to be 2693 preferred in its order given by its place in the list returned. 2695 - The IP addresses in the Home Agent Addresses field should be 2696 listed in order of decreasing preference value, based either 2697 on the respective advertised preference from a Home Agent 2698 Information option or on the default preference of 0 if no 2699 preference is advertised (or on the configured home agent 2700 preference for this home agent itself). The home agent with 2701 the highest preference SHOULD be listed first in the Home Agent 2702 Addresses field, and the home agent with the lowest preference 2703 SHOULD be listed last. 2705 - Among home agents with equal preference, their IP addresses 2706 in the Home Agent Addresses field SHOULD be listed in an 2707 order randomized with respect to other home agents with equal 2708 preference, each time a Home Agent Address Discovery Reply 2709 message is returned by this home agent. 2711 - For each entry in this home agent's Home Agents List, if more 2712 than one global IP address is associated with this list entry, 2713 then one of these global IP addresses SHOULD be selected to 2714 include in the Home Agent Addresses field in the Reply message. 2715 As described in Section 4.3, one Home Agents List entry, 2716 identified by the home agent's link-local address, exists for 2717 each home agent on the link; associated with that list entry is 2718 one or more global IP addresses for this home agent, learned 2719 through Prefix Information options with the Router Address (R) 2720 bit is set, received in Router Advertisements from this 2721 link-local address. The selected global IP address for each home 2722 agent to include in forming the Home Agent Addresses field in the 2723 Reply message MUST be the global IP address of the respective 2724 home agent sharing a prefix with the mobile node's home address 2725 as indicated in the Home Address option in the Request message; 2726 if no such global IP address is known for some home agent, an 2727 entry for that home agent MUST NOT be included in the Home Agent 2728 Addresses field in the Reply message. 2730 - In order to avoid the possibility of the Reply message packet 2731 being fragmented (or rejected by an intermediate router with an 2732 ICMP Packet Too Big message [5]), if the resulting total packet 2733 size containing the complete list of home agents in the Home 2734 Agent Addresses field would exceed the minimum IPv6 MTU [6], the 2735 home agent SHOULD reduce the number of home agent IP addresses 2736 returned in the packet to the number of addresses that will fit 2737 without exceeding this limit. The home agent addresses returned 2738 in the packet SHOULD be those from the complete list with the 2739 highest preference. 2741 9.3. Primary Care-of Address Registration 2743 When a node receives a Binding Update, it MUST validate it and 2744 determine the type of Binding Update according to the steps described 2745 in Section 8.2. This section describes the processing of a valid 2746 Binding Update that requests the receiving node to serve as its home 2747 agent, registering its primary care-of address. 2749 To begin processing the Binding Update, the home agent MUST perform 2750 the following sequence of tests: 2752 - If the node is not a router that implements home agent 2753 functionality, then the node MUST reject the Binding Update and 2754 SHOULD return a Binding Acknowledgement to the mobile node, in 2755 which the Status field is set to 132 (home registration not 2756 supported). 2758 - Else, if the home address for the binding (the Home Address field 2759 in the packet's Home Address option) is not an on-link IPv6 2760 address with respect to the home agent's current Prefix List, 2761 then the home agent MUST reject the Binding Update and SHOULD 2762 return a Binding Acknowledgement to the mobile node, in which the 2763 Status field is set to 133 (not home subnet). 2765 - Else, if the Prefix Length field is nonzero in the Binding Update 2766 and this length differs from the length of the home agent's own 2767 knowledge of the corresponding subnet prefix on the home link, 2768 then the home agent MUST reject the Binding Update and SHOULD 2769 return a Binding Acknowledgement to the mobile node, in which the 2770 Status field is set to 136 (incorrect subnet prefix length). 2772 - Else, if the home agent chooses to reject the Binding Update for 2773 any other reason (e.g., insufficient resources to serve another 2774 mobile node as a home agent), then the home agent SHOULD return a 2775 Binding Acknowledgement to the mobile node, in which the Status 2776 field is set to an appropriate value to indicate the reason for 2777 the rejection. 2779 - Finally, if the Duplicate Address Detection (D) bit is set in the 2780 Binding Update, this home agent MUST perform Duplicate Address 2781 Detection [27] on the mobile node's home link for the home 2782 address in this binding. If this Duplicate Address Detection 2783 fails, then the home agent MUST reject the Binding Update and 2784 SHOULD return a Binding Acknowledgement to the mobile node, in 2785 which the Status field is set to 138 (Duplicate Address Detection 2786 failed). 2788 If the home agent does not reject the Binding Update as described 2789 above, then it becomes the home agent for the mobile node. The new 2790 home agent (the receiving node) MUST then create a new entry in its 2791 Binding Cache for this mobile node (or update its existing Binding 2792 Cache entry for this mobile node, if such an entry already exists) 2793 The home address of the mobile node is taken from the Home Address 2794 field in the packet's Home Address option. The care-of address for 2795 this Binding Cache entry is taken from the Alternate Care-of Address 2796 sub-option in the Binding Update option, if present, or from the 2797 Source Address field in the packet's IPv6 header, otherwise. 2799 The home agent MUST mark this Binding Cache entry as a "home 2800 registration" to indicate that the node is serving as a home 2801 agent for this binding. Binding Cache entries marked as a "home 2802 registration" MUST be excluded from the normal cache replacement 2803 policy used for the Binding Cache (Section 8.7) and MUST NOT be 2804 removed from the Binding Cache until the expiration of the Lifetime 2805 period. 2807 In addition, the home agent MUST copy the Router (R) bit from the 2808 Binding Update into the corresponding bit in this Binding Cache entry 2809 for this mobile node. 2811 The lifetime for the Binding Cache entry MUST NOT be greater than 2812 the remaining valid lifetime for the subnet prefix in the mobile 2813 node's home address specified with the Binding Update. The remaining 2814 valid lifetime for this prefix is determined by the home agent based 2815 on its own Prefix List entry for this prefix [17]. Furthermore, 2816 if the Prefix Length field in the Binding Update is nonzero, then 2817 the lifetime for the Binding Cache entry MUST NOT be greater than 2818 the minimum remaining valid lifetime for all subnet prefixes on 2819 the mobile node's home link. If the value of the Lifetime field 2820 specified by the mobile node in its Binding Update is greater than 2821 this prefix lifetime, the home agent MUST decrease the binding 2822 lifetime to less than or equal to the prefix valid lifetime. The 2823 home agent MAY further decrease the specified lifetime for the 2824 binding, for example based on a local policy implemented by the home 2825 agent. The resulting lifetime is stored by the home agent in the 2826 Binding Cache entry, and this Binding Cache entry MUST be deleted by 2827 the home agent after the expiration of this lifetime. 2829 The Prefix Length in the Binding Update MUST also be saved in the 2830 Binding Cache entry. 2832 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2833 be), then the home agent MUST return a Binding Acknowledgement to the 2834 mobile node, constructed as follows: 2836 - The Status field MUST be set to a value indicating success (the 2837 value MUST be less than 128). The only currently defined success 2838 Status value is 0, indicating simply that the Binding Update was 2839 accepted. 2841 - The Sequence Number field MUST be copied from the Sequence Number 2842 given in the Binding Update. 2844 - The Lifetime field MUST be set to the remaining lifetime for 2845 the binding as set by the home agent in its "home registration" 2846 Binding Cache entry for the mobile node. As described above, 2847 this lifetime MUST NOT be greater than the remaining valid 2848 lifetime for the subnet prefix in the mobile node's home address. 2850 - The Refresh field MUST be set to a value less than or equal to 2851 the Lifetime value being returned in the Binding Update. If the 2852 home agent stores the Binding Cache entry in nonvolatile storage 2853 (that survives the crash or other failure of the home agent), 2854 then the Refresh field SHOULD be set to the same value as the 2855 Lifetime field; otherwise, the home agent MAY set the Refresh 2856 field to a value less than the Lifetime field, to indicate that 2857 the mobile node SHOULD attempt to refresh its home registration 2858 at the indicated shorter interval (although the home agent will 2859 still retain the registration for the Lifetime period, even if 2860 the mobile node does not refresh its registration within the 2861 Refresh period). 2863 In addition, the home agent MUST follow the procedure defined in 2864 Section 9.5 to intercept packets on the mobile node's home link 2865 addressed to the mobile node, while the home agent is serving as the 2866 home agent for this mobile node. 2868 9.4. Primary Care-of Address De-registration 2870 When a node receives a Binding Update, it MUST validate it and 2871 determine the type of Binding Update according to the steps described 2872 in Section 8.2. This section describes the processing of a valid 2873 Binding Update that requests the receiving node to no longer serve as 2874 its home agent, de-registering its primary care-of address. 2876 To begin processing the Binding Update, the home agent MUST perform 2877 the following test: 2879 - If the receiving node has no entry in its Binding Cache for this 2880 mobile node that is marked as a "home registration", then this 2881 node MUST reject the Binding Update and SHOULD return a Binding 2882 Acknowledgement to the mobile node, in which the Status field is 2883 set to 137 (not home agent for this mobile node). 2885 If the home agent does not reject the Binding Update as described 2886 above, then it MUST delete any existing entry in its Binding Cache 2887 for this mobile node. 2889 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2890 be), then the home agent MUST return a Binding Acknowledgement to the 2891 mobile node, constructed as follows: 2893 - The Status field MUST be set to a value indicating success (the 2894 value MUST be less than 128). The only currently defined success 2895 Status value is 0, indicating simply that the Binding Update was 2896 accepted. 2898 - The Sequence Number field MUST be copied from the Sequence Number 2899 given in the Binding Update. 2901 - The Lifetime field MUST be set to zero. 2903 - The Refresh field MUST be set to zero. 2905 In addition, the home agent MUST stop intercepting packets on the 2906 mobile node's home link addressed to the mobile node (Section 9.5). 2908 9.5. Intercepting Packets for a Mobile Node 2910 While a node is serving as the home agent for mobile node (while the 2911 node has an entry in its Binding Cache for this mobile node that is 2912 marked as a "home registration"), this node MUST attempt to intercept 2913 packets on the mobile node's home link addressed to the mobile node, 2914 and MUST tunnel each intercepted packet to the mobile node using 2915 using IPv6 encapsulation [4]. 2917 In order to intercept such packets on the home link, when a node 2918 becomes the home agent for some mobile node (it did not already 2919 have a Binding Cache entry for this mobile node marked as a "home 2920 registration"), then the home agent MUST multicast onto the home link 2921 a "gratuitous" Neighbor Advertisement message [17] on behalf of the 2922 mobile node. Specifically, the home agent performs the following 2923 steps: 2925 - The home agent examines the value of the Prefix Length field 2926 in the new "home registration" Binding Cache entry. If this 2927 value is zero, the following step is carried out only for the 2928 individual home address specified for this binding. If, instead, 2929 this field is nonzero, then the following step is carried out 2930 for each address for the mobile node formed from the interface 2931 identifier in the mobile node's home address in this binding 2932 (the remaining low-order bits in the address after the indicated 2933 subnet prefix), together with each one of the subnet prefixes 2934 currently considered by the home agent to be on-link (including 2935 both the link-local and site-local prefix). 2937 - For each specific IP address for the mobile node determined 2938 in the first step above, the home agent multicasts onto the 2939 home link (to the all-nodes multicast address) a Neighbor 2940 Advertisement message [17] on behalf of the mobile node, to 2941 advertise the home agent's own link-layer address for this IP 2942 address. The Target Address in the Neighbor Advertisement 2943 message MUST be set to this IP address for the mobile node, and 2944 the Advertisement MUST include a Target Link-layer Address option 2945 specifying the home agent's link-layer address. In addition, 2946 the Router (R) bit in the Advertisement MUST be copied from the 2947 corresponding bit in the home agent's Binding Cache entry for 2948 the mobile node. The Solicited Flag (S) in the Advertisement 2949 MUST NOT be set, since it was not solicited by any Neighbor 2950 Solicitation message. The Override Flag (O) in the Advertisement 2951 MUST be set, indicating that the Advertisement SHOULD override 2952 any existing Neighbor Cache entry at any node receiving it. 2954 Any node on the home link receiving one of the Neighbor Advertisement 2955 messages described above will thus update its Neighbor Cache to 2956 associate the mobile node's address with the home agent's link 2957 layer address, causing it to transmit any future packets for the 2958 mobile node normally destined to this address instead to the mobile 2959 node's home agent. Since multicasts on the local link (such as 2960 Ethernet) are typically not guaranteed to be reliable, the home 2961 agent MAY retransmit this Neighbor Advertisement message up to 2962 MAX_ADVERT_REXMIT times to increase its reliability. It is still 2963 possible that some nodes on the home link will not receive any of 2964 these Neighbor Advertisements, but these nodes will eventually be 2965 able to detect the link-layer address change for the mobile node's 2966 home address, through use of Neighbor Unreachability Detection [17]. 2968 While a node is serving as a home agent for some mobile node (it 2969 still has a "home registration" entry for this mobile node in its 2970 Binding Cache), the home agent uses IPv6 Neighbor Discovery [17] 2971 to intercept unicast packets on the home link addressed the mobile 2972 node's home address. In order to intercept packets in this way, 2973 the home agent MUST act as a proxy for this mobile node to reply to 2974 any received Neighbor Solicitation messages for it. When a home 2975 agent receives a Neighbor Solicitation message, it MUST check if the 2976 Target Address specified in the message matches the home address 2977 of any mobile node for which it has a Binding Cache entry marked 2978 as a "home registration". This check MUST include all possible 2979 home addresses for the mobile node, based on the subnet prefixes 2980 currently considered to be on-link by the home agent (including the 2981 corresponding link-local address and site-local address), if the 2982 Prefix Length in the Binding Cache entry for this mobile node (from 2983 the Binding Update that created this Cache entry) is nonzero. 2985 If such an entry exists in the home agent's Binding Cache, the home 2986 agent MUST reply to the Neighbor Solicitation message with a Neighbor 2987 Advertisement message, giving the home agent's own link-layer address 2988 as the link-layer address for the specified Target Address. In 2989 addition, the Router (R) bit in the Advertisement MUST be copied from 2990 the corresponding bit in the home agent's Binding Cache entry for the 2991 mobile node. Acting as a proxy in this way allows other nodes on 2992 the mobile node's home link to resolve the mobile node's IPv6 home 2993 address, and allows the home agent to to defend these addresses on 2994 the home link for Duplicate Address Detection [17]. 2996 9.6. Tunneling Intercepted Packets to a Mobile Node 2998 For any packet sent to a mobile node from the mobile node's home 2999 agent (for which the home agent is the original sender of the 3000 packet), the home agent is operating as a correspondent node of 3001 the mobile node for this packet and the procedures described in 3002 Section 8.9 apply. The home agent (as a correspondent node) uses a 3003 Routing header to route the packet to the mobile node by way of the 3004 care-of address in the home agent's Binding Cache (the mobile node's 3005 primary care-of address, in this case). 3007 While the mobile node is away from home and this node is acting 3008 as the mobile node's home agent, the home agent intercepts any 3009 packets on the home link addressed to the mobile node's home address 3010 (including addresses formed from other on-link prefixes, if the 3011 Prefix Length field was nonzero in the Binding Update), as described 3012 in Section 9.5. The home agent cannot use a Routing header to 3013 forward these intercepted packets to the mobile node, since it cannot 3014 modify the packet in flight without invalidating any existing IPv6 3015 AH [11] or ESP [12] header present in the packet. 3017 For forwarding each intercepted packet to the mobile node, the 3018 home agent MUST tunnel the packet to the mobile node using IPv6 3019 encapsulation [4]; the tunnel entry point node is the home agent, 3020 and the tunnel exit point node is the primary care-of address as 3021 registered with the home agent (which is an address of the mobile 3022 node itself). When a home agent encapsulates an intercepted packet 3023 for forwarding to the mobile node, the home agent sets the Source 3024 Address in the prepended tunnel IP header to the home agent's own IP 3025 address, and sets the Destination Address in the tunnel IP header 3026 to the mobile node's primary care-of address. When received by the 3027 mobile node (using its primary care-of address), normal processing of 3028 the tunnel header [4] will result in decapsulation and processing of 3029 the original packet by the mobile node. 3031 However, packets addressed to the mobile node's link-local address 3032 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 3033 be discarded, and the home agent SHOULD return an ICMP Destination 3034 Unreachable, Code 3, message to the packet's Source Address (unless 3035 this Source Address is a multicast address). Packets addressed to 3036 the mobile node's site-local address SHOULD be tunneled to the mobile 3037 node by default, but this behavior MUST be configurable to disable 3038 it; currently, the exact definition and semantics of a "site" and a 3039 site-local address are undefined in IPv6, and this default behavior 3040 might change at some point in the future. 3042 Tunneling of multicast packets to a mobile node follows similar 3043 limitations to those defined above for unicast packets addressed to 3044 the mobile node's link-local and site-local addresses. Multicast 3045 packets addressed to a multicast address with link-local scope [9], 3046 to which the mobile node is subscribed, MUST NOT be tunneled 3047 to the mobile node; such packets SHOULD be silently discarded 3048 (after delivering to other local multicast recipients). Multicast 3049 packets addressed to a multicast address with scope larger 3050 than link-local but smaller than global (e.g., site-local and 3051 organization-local) [9], to which the mobile node is subscribed, 3052 SHOULD be tunneled to the mobile node by default, but this behavior 3053 MUST be configurable to disable it; this default behavior might 3054 change at some point in the future as the definition of these scopes 3055 become better defined in IPv6. 3057 9.7. Renumbering the Home Subnet 3059 IPv6 provides mechanisms through Neighbor Discovery [17] and Address 3060 Autoconfiguration [27] to aid in renumbering a subnet, such as when a 3061 site switches to a new network service provider. In renumbering, new 3062 prefixes and addresses can be introduced for the subnet and old ones 3063 can be deprecated and removed. These mechanisms are defined to work 3064 while all nodes using the old prefixes are at home, connected to the 3065 link using these prefixes. Mobile IPv6 extends these mechanisms for 3066 the case in which one or more mobile nodes using the old prefixes are 3067 away from home while the renumbering takes place. 3069 The IPv6 renumbering mechanisms are based on nodes on the link 3070 receiving Prefix Information options in Router Advertisement 3071 messages giving the valid lifetime and preferred lifetime for 3072 different prefixes on the link [17]. Mobile IPv6 arranges to 3073 tunnel certain Router Advertisements giving "important" Prefix 3074 Information options to mobile nodes while away from home. To avoid 3075 the need to tunnel all Router Advertisements from the home link to 3076 a mobile node away from home, those Router Advertisements that are 3077 tunneled to the mobile node are retransmitted until acknowledged. To 3078 avoid possible security attacks from forged Router Advertisements 3079 tunneled to the mobile node, all such tunneled Router Advertisements 3080 must be authenticated to the mobile node by its home agent using 3081 IPsec [13, 11, 12]. 3083 Specifically, a home agent serving some mobile node SHOULD construct 3084 and tunnel to the mobile node a new Router Advertisement when any of 3085 the following conditions occur: 3087 - The preferred or valid lifetime for an existing prefix on the 3088 home link is reduced. 3090 - A new prefix is introduced on the home link. 3092 - The state of the home agent's AdvManagedFlag flag [17] changes 3093 from FALSE to TRUE or from TRUE to FALSE. 3095 The home agent determines these conditions based on its own 3096 configuration as a router and based on the Router Advertisements 3097 that it receives on the home link. The home agent constructs a new 3098 Router Advertisement message containing no options other than the 3099 Prefix Information options describing the prefixes for which one of 3100 the conditions above has occurred since the last Router Advertisement 3101 tunneled to and acknowledged by the mobile node. When multiple 3102 conditions occur at or near the same time, the home agent SHOULD 3103 attempt to combine them into a single Router Advertisement message to 3104 the mobile node. 3106 In tunneling each such Router Advertisement to the mobile node, the 3107 home agent MUST construct the packet as follows: 3109 - The Source Address in the packet's IPv6 header MUST be set to the 3110 home agent's IP address to which the mobile node addressed its 3111 current home registration. 3113 - The packet MUST be protected by IPsec [13, 11, 12] to guard 3114 against malicious Router Advertisements. The IPsec protection 3115 MUST provide sender authentication, data integrity protection, 3116 and replay protection, covering the Router Advertisement. 3118 - The packet MUST include a Binding Request destination option. 3120 - The Binding Request destination option MUST include a Unique 3121 Identifier Sub-Option (Section 5.5), with the unique identifier 3122 in the sub-option data set to a value different than that in 3123 any other Binding Request sent recently by this node. The word 3124 "recently" here means within the maximum likely lifetime of a 3125 packet, including transit time from source to destination and 3126 time spent awaiting reassembly with other fragments of the same 3127 packet, if fragmented. However, it is not required that a source 3128 node know the maximum packet lifetime. Rather, it is assumed 3129 that the requirement can be met by maintaining a simple 16-bit 3130 "wrap-around" counter to generate unique identifiers for Binding 3131 Requests that contain a Unique Identifier Sub-Option, incremented 3132 each time a Binding Request containing a Unique Identifier 3133 Sub-Option is sent. 3135 - The packet MUST be tunneled to the mobile node's primary care-of 3136 address using a Routing header, in the same way as any packet 3137 sent to the mobile node originated by the home agent (rather than 3138 using IPv6 encapsulation, as would be used by the home agent for 3139 intercepted packets). 3141 The home agent SHOULD periodically continue to retransmit this 3142 tunneled packet to the mobile node, until it is acknowledged by 3143 the receipt from the mobile node of a Binding Update matching 3144 the Binding Request in the packet (i.e., with matching Sequence 3145 Number). A Binding Update matches a Binding Request if it specifies 3146 a binding for the mobile node to which the Binding Request was sent 3147 and contains a Unique Identifier Sub-Option matching the unique 3148 identifier sent in the Unique Identifier Sub-Option in the Binding 3149 Request. 3151 If while the home agent is still retransmitting a Router 3152 Advertisement to the mobile node, another condition as described 3153 above occurs on the home link causing another Router Advertisement 3154 to be tunneled to the mobile node, the home agent SHOULD combine any 3155 Prefix Information options in the unacknowledged Router Advertisement 3156 into the new Router Advertisement and then begin retransmitting the 3157 new Router Advertisement rather than the old one. When tunneling 3158 a new Router Advertisement, even if it contains Prefix Information 3159 options sent previously in an unacknowledged tunneled Router 3160 Advertisement, the home agent MUST generate a new unique identifer 3161 for use in the Unique Identifier Sub-Option in the Binding Request 3162 tunneled with the new Router Advertisement. 3164 In addition, as described in Section 9.3, the lifetime returned by a 3165 mobile node's home agent in its Binding Acknowledgement in response 3166 to registration of a new primary care-of address by the mobile node 3167 MUST be no greater than the remaining valid lifetime for the subnet 3168 prefix in the mobile node's home address. Furthermore, as described 3169 in Section 10.8, Binding Updates sent by the mobile node to other 3170 nodes MUST use a lifetime no greater than the remaining lifetime of 3171 its home registration of its primary care-of address. These limits 3172 on a binding lifetimes ensure that no node uses a mobile node's home 3173 address beyond the time that it becomes invalid. The mobile node 3174 SHOULD further limit the lifetimes that it sends on any Binding 3175 Updates to be within the remaining preferred lifetime for the prefix 3176 in its home address. 3178 10. Mobile Node Operation 3180 10.1. Sending Packets While Away from Home 3182 While a mobile node is away from home, it continues to use its home 3183 address as well as also using one or more care-of addresses. When 3184 sending a packet while away from home, a mobile node MAY choose among 3185 these in selecting the address that it will use as the source of the 3186 packet, as follows: 3188 - From the point of view of protocol layers and applications above 3189 Mobile IP (e.g., transport protocols), the mobile node will 3190 generally use its home address as the source of the packet for 3191 most packets, even while away from home, since Mobile IP is 3192 designed to make mobility transparent to such software. Doing 3193 so also makes the node's mobility---and the fact that it is 3194 currently away from home---transparent to the correspondent nodes 3195 with which it communicates. For packets sent that are part of 3196 transport-level connections established while the mobile node 3197 was at home, the mobile node MUST use its home address in this 3198 way. Likewise, for packets sent that are part of transport-level 3199 connections that the mobile node may still be using after moving 3200 to a new location, the mobile node SHOULD use its home address 3201 in this way. When sending such packets, Mobile IP will modify 3202 the packet to move the home address into a Home Address option 3203 and will set the IPv6 header's Source Address field to one of 3204 the mobile node's care-of addresses; these modifications to 3205 the packet are then reversed in the node receiving the packet, 3206 restoring the mobile node's home address to be the packet's 3207 Source Address before processing by higher protocol layers and 3208 applications. 3210 - For short-term communication, particularly for communication that 3211 may easily be retried if it fails, the mobile node MAY choose 3212 to directly use one of its care-of addresses as the source of 3213 the packet, thus not requiring the use of a Home Address option 3214 in the packet. An example of this type of communication might 3215 be DNS queries sent by the mobile node [15, 16]. Using the 3216 mobile node's care-of address as the source for such queries will 3217 generally have a lower overhead than using the mobile node's 3218 home address, since no extra options need be used in either the 3219 query or its reply, and all packets can be routed normally, 3220 directly between their source and destination without relying 3221 on Mobile IP. If the mobile node has no particular knowledge 3222 that the communication being sent fits within this general type 3223 of communication, however, the mobile node SHOULD NOT use its 3224 care-of address as the source of the packet in this way. 3226 For packets sent by a mobile node while it is at home, no special 3227 Mobile IP processing is required for sending this packet. Likewise, 3228 if the mobile node uses any address other than its home address as 3229 the source of a packet sent while away from home (from the point of 3230 view of higher protocol layers or applications, as described above), 3231 no special Mobile IP processing is required for sending that packet. 3232 In each case, the packet is simply addressed and transmitted in the 3233 same way as any normal IPv6 packet. 3235 For each other packet sent by the mobile node (i.e., packets sent 3236 while away from home, using the mobile node's home address as 3237 the source, from the point of view of higher protocol layers and 3238 applications), special Mobile IP processing of the packet is required 3239 for the insertion of the Home Address option. Specifically: 3241 - Construct the packet using the mobile node's home address as the 3242 packet's Source Address, in the same way as if the mobile node 3243 were at home. This preserves the transparency of Mobile IP to 3244 higher protocol layers (e.g., to TCP). 3246 - Insert a Home Address option into the packet, with the Home 3247 Address field copied from the original value of the Source 3248 Address field in the packet. 3250 - Change the Source Address field in the packet's IPv6 header to 3251 one of the mobile node's care-of addresses. This will typically 3252 be the mobile node's current primary care-of address, but MUST 3253 be a care-of address with a subnet prefix that is on-link on the 3254 network interface on which the mobile node will transmit the 3255 packet. 3257 By using the care-of address as the Source Address in the IPv6 3258 header, with the mobile node's home address instead in the Home 3259 Address option, the packet will be able to safely pass through any 3260 router implementing ingress filtering [7]. 3262 10.2. Interaction with Outbound IPsec Processing 3264 As a guidance to implementors, this section sketches the interaction 3265 between outbound Mobile IP processing and outbound IP Security 3266 (IPsec) processing for packets sent by a mobile node while away 3267 from home. Any specific implementation MAY use algorithms and data 3268 structures other than those suggested here, but its processing MUST 3269 be consistent with the effect of the operation described here and 3270 with the relevant IPsec specifications. In the steps described 3271 below, it is assumed that IPsec is being used in transport mode [13] 3272 and that the mobile node is using its home address as the source 3273 for the packet (from the point of view of higher protocol layers or 3274 applications, as described in Section 10.1): 3276 - The packet is created by higher layer protocols and applications 3277 (e.g., by TCP) as if the mobile node were at home and Mobile IP 3278 were not being used. Mobile IP is transparent to such higher 3279 layers. 3281 - As part of outbound packet processing in IP, the packet is 3282 compared against the IPsec Security Policy Database (SPD) to 3283 determine what processing is required for the packet [13]. 3285 - As a special case for Mobile IP, if a Binding Update or 3286 Binding Acknowledgement is being included in the packet, IPsec 3287 authentication, integrity protection, and replay protection MUST 3288 be applied to the packet [13, 11, 12], as defined in Sections 5.1 3289 and 5.2. If the SPD check above has already indicated that 3290 authentication and replay protection are required, this 3291 processing is sufficient for the Mobile IP requirement that all 3292 packets containing Binding Updates or Binding Acknowledgements be 3293 authenticated and covered by replay protection. Otherwise, an 3294 implementation can force the required IPsec processing on this 3295 individual packet by, for example, creating a temporary SPD entry 3296 for the handling of this packet. 3298 - If IPsec processing is required, the packet is either mapped to 3299 an existing Security Association (or SA bundle), or a new SA (or 3300 SA bundle) is created for the packet, according to the procedures 3301 defined for IPsec. 3303 - Since the mobile node is away from home, the mobile node inserts 3304 a Home Address option into the packet, replacing the Source 3305 Address in the packet's IP header with a care-of address suitable 3306 for the link on which the packet is being sent, as described in 3307 Section 10.1. The Destination Options header in which the Home 3308 Address option is inserted MUST appear in the packet before the 3309 AH [11] (or ESP [12]) header, so that the Home Address option is 3310 processed by the destination node before the AH or ESP header is 3311 processed. 3313 - If a Binding Update is being included in the packet, it is 3314 also added to a Destination Options header in the packet. The 3315 Destination Options header in which the Binding Update option is 3316 inserted MAY appear either before or after the AH or ESP header. 3317 If it is inserted before the AH or ESP header, it SHOULD be 3318 placed in the same Destination Options header in which the Home 3319 Address option was inserted. 3321 - Finally, once the packet is fully assembled, the necessary IPsec 3322 authentication (and encryption, if required) processing is 3323 performed on the packet, initializing the Authentication Data in 3324 the AH or ESP header. 3326 In addition, when using any automated key management protocol [13] 3327 (such as IKE [8]) to create any new SA (or SA bundle) while away from 3328 home (whether due to the inclusion of a Binding Update or Binding 3329 Acknowledgement in an outgoing packet, or otherwise), a mobile node 3330 MUST take special care in its processing of the key management 3331 protocol. Otherwise, other nodes with which the mobile node 3332 must communicate as part of the automated key management protocol 3333 processing may be unable to correctly deliver packets to the mobile 3334 node if they and/or the mobile node's home agent do not then have a 3335 current Binding Cache entry for the mobile node. For the default 3336 case of using IKE as the automated key management protocol [8, 13], 3337 such problems can be avoided by the following requirements on the use 3338 of IKE by a mobile node while away from home: 3340 - The mobile node MUST use its care-of address as the Source 3341 Address of all packets it sends as part of the key management 3342 protocol (without use of Mobile IP for these packets, as 3343 suggested in Section 10.1). 3345 - In addition, the mobile node MUST include an ISAKMP 3346 Identification Payload [14] in the IKE exchange, giving the 3347 mobile node's home address as the initiator of the Security 3348 Association [22]. 3350 10.3. Receiving Packets While Away from Home 3352 While away from home, a mobile node will receive packets addressed to 3353 its home address, by one of three methods: 3355 - Packets sent by a correspondent node that does not have a 3356 Binding Cache entry for the mobile node, will be sent by the 3357 correspondent node in the same way as any normal IP packet. Such 3358 packets will then be intercepted by the mobile node's home agent, 3359 encapsulated using IPv6 encapsulation [4], and tunneled to the 3360 mobile node's primary care-of address. 3362 - Packets sent by a correspondent node that has a Binding Cache 3363 entry for the mobile node that contains the mobile node's current 3364 care-of address, will be sent by the correspondent node using 3365 a Routing header. The packet will be addressed to the mobile 3366 node's care-of address, with the final hop in the Routing header 3367 directing the packet to the mobile node's home address; the 3368 processing of this last hop of the Routing header is entirely 3369 internal to the mobile node, since the care-of address and home 3370 address are both addresses within the mobile node. 3372 - Packets sent by a correspondent node that has a Binding Cache 3373 entry for the mobile node that contains an out-of-date care-of 3374 address for the mobile node, will be sent by the correspondent 3375 node using a Routing header, as described above. If the mobile 3376 node sent a Binding Update to a home agent on the link on which 3377 its previous care-of address is located (Section 10.9), and 3378 if this home agent is still serving as a home agent for the 3379 mobile node's previous care-of address, then such a packet will 3380 be intercepted by this home agent, encapsulated using IPv6 3381 encapsulation [4], and tunneled to the mobile node's new care-of 3382 address (registered with this home agent). 3384 For packets received by either the first or last of these three 3385 methods, the mobile node SHOULD send a Binding Update to the original 3386 sender of the packet, as described in Section 10.8, subject to the 3387 rate limiting defined in Section 10.11. The mobile node SHOULD 3388 also process the received packet in the manner defined for IPv6 3389 encapsulation [4], which will result in the encapsulated (inner) 3390 packet being processed normally by upper-layer protocols within the 3391 mobile node, as if it had been addressed (only) to the mobile node's 3392 home address. 3394 For packets received by the second method above (using a Routing 3395 header), the mobile node SHOULD process the received packet in the 3396 manner defined for the type of IPv6 Routing header used [6], which 3397 will result in the packet being processed normally by upper-layer 3398 protocols within the mobile node, as if it had been addressed (only) 3399 to the mobile node's home address. 3401 In addition, the general procedures defined by IPv6 for Routing 3402 headers suggest that a received Routing header MAY be automatically 3403 "reversed" to construct a Routing header for use in any response 3404 packets sent by upper-layer protocols, if the received packet is 3405 authenticated [6]. If this is done for upper-layer protocol response 3406 packets sent by a mobile node while away from home, the mobile 3407 node SHOULD NOT include its own care-of address, which appears in 3408 the Routing header of the received packet, in the reversed route 3409 for the response packet. If the received Routing header contained 3410 no additional hops (other than the mobile node's home address and 3411 care-of address), then any upper-layer protocol response packet 3412 SHOULD NOT include a Routing header. 3414 10.4. Movement Detection 3416 A mobile node MAY use any combination of mechanisms available to it 3417 to detect when it has moved from one link to another. The primary 3418 movement detection mechanism for Mobile IPv6 defined here uses the 3419 facilities of IPv6 Neighbor Discovery, including Router Discovery and 3420 Neighbor Unreachability Detection. The description here is based on 3421 the conceptual model of the organization and data structures defined 3422 by Neighbor Discovery [17]. 3424 Mobile nodes SHOULD use Router Discovery to discover new routers and 3425 on-link subnet prefixes; a mobile node MAY send Router Solicitation 3426 messages, or MAY wait for unsolicited (periodic) multicast Router 3427 Advertisement messages, as specified for Router Discovery [17]. 3428 Based on received Router Advertisement messages, a mobile node (in 3429 the same way as any other node) maintains an entry in its Default 3430 Router List for each router, and an entry in its Prefix List for each 3431 subnet prefix, that it currently considers to be on-link. Each entry 3432 in these lists has an associated invalidation timer value (extracted 3433 from the Router Advertisement) used to expire the entry when it 3434 becomes invalid. 3436 While away from home, a mobile node SHOULD select one router from 3437 its Default Router List to use as its default router, and one subnet 3438 prefix advertised by that router from its Prefix List to use as 3439 the subnet prefix in its primary care-of address. A mobile node 3440 MAY also have associated additional care-of addresses, using other 3441 subnet prefixes from its Prefix List. The method by which a mobile 3442 node selects and forms a care-of address from the available subnet 3443 prefixes is described in Section 10.5. The mobile node registers 3444 its primary care-of address with its home agent, as described in 3445 Section 10.6. 3447 While a mobile node is away from home and using some router as its 3448 default router, it is important for the mobile node to be able to 3449 quickly detect when that router becomes unreachable, so that it can 3450 switch to a new default router and to a new primary care-of address. 3451 Since some links (notably wireless) do not necessarily work equally 3452 well in both directions, it is likewise important for the mobile 3453 node to detect when it becomes unreachable to packets sent from its 3454 default router, so that the mobile node can take steps to ensure that 3455 any correspondent nodes attempting to communicate with it can still 3456 reach it through some other route. 3458 To detect when its default router becomes unreachable, a mobile 3459 node SHOULD use Neighbor Unreachability Detection. As specified in 3460 Neighbor Discovery [17], while the mobile node is actively sending 3461 packets to (or through) its default router, the mobile node can 3462 detect that the router (as its neighbor) is still reachable either 3463 through indications from upper layer protocols on the mobile node 3464 that a connection is making "forward progress" (e.g., receipt of TCP 3465 acknowledgements for new data transmitted), or through receipt of a 3466 Neighbor Advertisement message from its default router in response 3467 to an explicit Neighbor Solicitation messages to it. Note that 3468 although this mechanism detects that the mobile node's default router 3469 has become unreachable to the mobile node only while the mobile node 3470 is actively sending packets to it, this is the only time that this 3471 direction of reachability confirmation is needed. Confirmation 3472 that the mobile node is still reachable from the router is handled 3473 separately, as described below. 3475 For a mobile node to detect when it has become unreachable from its 3476 default router, the mobile node cannot efficiently rely on Neighbor 3477 Unreachability Detection alone, since the network overhead would be 3478 prohibitively high in many cases for a mobile node to continually 3479 probe its default router with Neighbor Solicitation messages even 3480 when it is not otherwise actively sending packets to it. Instead, 3481 a mobile node SHOULD consider receipt of any IPv6 packets from its 3482 current default router as an indication that it is still reachable 3483 from the router. Both packets from the router's IP address and 3484 (IPv6) packets from its link-layer address (e.g., those forwarded but 3485 not originated by the router) SHOULD be considered. 3487 Since the router SHOULD be sending periodic unsolicited multicast 3488 Router Advertisement messages, the mobile node will have frequent 3489 opportunity to check if it is still reachable from its default 3490 router, even in the absence of other packets to it from the router. 3491 If Router Advertisements that the mobile node receives include 3492 an Advertisement Interval option, the mobile node MAY use its 3493 Advertisement Interval field as an indication of the frequency with 3494 which it should expect to continue to receive future Advertisements 3495 from that router. This field specifies the minimum rate (the maximum 3496 amount of time between successive Advertisements) that the mobile 3497 node should expect. If this amount of time elapses without the 3498 mobile node receiving any Advertisement from this router, the mobile 3499 node can be sure that at least one Advertisement sent by the router 3500 has been lost. It is thus possible for the mobile node to implement 3501 its own policy for determining the number of Advertisements from 3502 its current default router it is willing to tolerate losing before 3503 deciding to switch to a different router from which it may currently 3504 be correctly receiving Advertisements. 3506 On some types of network interfaces, the mobile node MAY also 3507 supplement this monitoring of Router Advertisements, by setting its 3508 network interface into "promiscuous" receive mode, so that it is able 3509 to receive all packets on the link, including those not link-level 3510 addressed to it (i.e., disabling link-level address filtering). The 3511 mobile node will then be able to detect any packets sent by the 3512 router, in order to to detect reachability from the router. This 3513 use of promiscuous mode may be useful on very low bandwidth (e.g., 3514 wireless) links, but its use MUST be configurable on the mobile node. 3516 If the above means do not provide indication that the mobile node is 3517 still reachable from its current default router (i.e., the mobile 3518 node receives no packets from the router for a period of time), then 3519 the mobile node SHOULD attempt to actively probe the router with 3520 Neighbor Solicitation messages, even if it is not otherwise actively 3521 sending packets to the router. If it receives a solicited Neighbor 3522 Advertisement message in response from the router, then the mobile 3523 node can deduce that it is still reachable. It is expected that the 3524 mobile node will in most cases be able to determine its reachability 3525 from the router by listening for packets from the router as described 3526 above, and thus, such extra Neighbor Solicitation probes should 3527 rarely be necessary. 3529 With some types of networks, it is possible that additional 3530 indications about link-layer mobility can be obtained from 3531 lower-layer protocol or device driver software within the mobile 3532 node. However, a mobile node MUST NOT assume that all link-layer 3533 mobility indications from lower layers indicate a movement of the 3534 mobile node to a new link, such that the mobile node would need to 3535 switch to a new default router and primary care-of address. For 3536 example, movement of a mobile node from one cell to another in many 3537 wireless LANs can be made transparent to the IP level through use of 3538 a link-layer "roaming" protocol, as long as the different wireless 3539 LAN cells all operate as part of the same IP link with the same 3540 subnet prefix. Upon lower-layer indication of link-layer mobility, 3541 the mobile node MAY send Router Solicitation messages to determine if 3542 new routers (and new on-link subnet prefixes) are present on its new 3543 link. 3545 Such lower-layer information might also be useful to a mobile node in 3546 deciding to switch its primary care-of address to one of the other 3547 care-of addresses it has formed from the on-link subnet prefixes 3548 currently available through different routers from which the mobile 3549 node is reachable. For example, a mobile node MAY use signal 3550 strength or signal quality information (with suitable hysteresis) for 3551 its link with the available routers to decide when to switch to a new 3552 primary care-of address using that router rather than its current 3553 default router (and current primary care-of address). Even though 3554 the mobile node's current default router may still be reachable in 3555 terms of Neighbor Unreachability Detection, the mobile node MAY use 3556 such lower-layer information to determine that switching to a new 3557 default router would provide a better connection. 3559 10.5. Forming New Care-of Addresses 3561 After detecting that it has moved from one link to another (i.e., its 3562 current default router has become unreachable and it has discovered 3563 a new default router), a mobile node SHOULD form a new primary 3564 care-of address using one of the on-link subnet prefixes advertised 3565 by the new router. A mobile node MAY form a new primary care-of 3566 address at any time, except that it MUST NOT do so too frequently. 3567 Specifically, a mobile node MUST NOT send a Binding Update about a 3568 new care-of address to its home agent (which is required to register 3569 the new address as its primary care-of address) more often than once 3570 per MAX_UPDATE_RATE seconds. 3572 In addition, after discovering a new on-link subnet prefix, a mobile 3573 node MAY form a new (non-primary) care-of address using that subnet 3574 prefix, even when it has not switched to a new default router. A 3575 mobile node can have only one primary care-of address at a time 3576 (which is registered with its home agent), but it MAY have an 3577 additional care-of address for any or all of the prefixes on its 3578 current link. Furthermore, since a wireless network interface may 3579 actually allow a mobile node to be reachable on more than one link at 3580 a time (i.e., within wireless transmitter range of routers on more 3581 than one separate link), a mobile node MAY have care-of addresses 3582 on more than one link at a time. The use of more than one care-of 3583 address at a time is described in Section 10.17. 3585 As described in Section 4, in order to form a new care-of address, 3586 a mobile node MAY use either stateless [27] or stateful (e.g., 3587 DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to 3588 send packets as part of the method of address autoconfiguration, 3589 it MUST use an IPv6 link-local address rather than its own IPv6 3590 home address as the Source Address in the IPv6 header of each such 3591 autoconfiguration packet. 3593 In some cases, a mobile node may already know a (constant) IPv6 3594 address that has been assigned to it for its use only while 3595 visiting a specific foreign link. For example, a mobile node may be 3596 statically configured with an IPv6 address assigned by the system 3597 administrator of some foreign link, for its use while visiting that 3598 link. If so, rather than using Address Autoconfiguration to form a 3599 new care-of address using this subnet prefix, the mobile node MAY use 3600 its own pre-assigned address as its care-of address on this link. 3602 10.6. Sending Binding Updates to the Home Agent 3604 After deciding to change its primary care-of address as described 3605 in Sections 10.4 and 10.5, a mobile node MUST register this care-of 3606 address with its home agent in order to make this its primary care-of 3607 address. To do so, the mobile node sends a packet to its home agent 3608 containing a Binding Update option, with the packet constructed as 3609 follows: 3611 - The Home Registration (H) bit MUST be set in the Binding Update. 3613 - The Acknowledge (A) bit MUST be set in the Binding Update. 3615 - The packet MUST contain a Home Address option, giving the mobile 3616 node's home address for the binding. 3618 - The care-of address for the binding MUST be used as the Source 3619 Address in the packet's IPv6 header, unless an Alternate Care-of 3620 Address sub-option is included in the Binding Update option. 3622 - The Prefix Length field SHOULD be set to the length of the mobile 3623 node's subnet prefix in its home address, to request the mobile 3624 node's home agent to serve as a home agent for all home addresses 3625 for the mobile node based on all on-link subnet prefixes on the 3626 home link. Otherwise, this field MUST be set to zero. 3628 The Acknowledge (A) bit in the Binding Update requests the home 3629 agent to return a Binding Acknowledgement in response to this 3630 Binding Update. As described in Section 5.2, the mobile node SHOULD 3631 retransmit this Binding Update to its home agent until it receives 3632 a matching Binding Acknowledgement. Once reaching a retransmission 3633 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 3634 continue to periodically retransmit the Binding Update at this rate 3635 until acknowledged (or until it begins attempting to register a 3636 different primary care-of address). 3638 The Prefix Length field in the Binding Update allows the mobile node 3639 to request its home agent to serve all home addresses for the mobile 3640 node, as indicated by the interface identifier in the mobile node's 3641 home address (the remaining low-order bits after the indicated subnet 3642 prefix), together with each on-link subnet prefix on the home link. 3643 Until the lifetime of this registration expires, the home agent 3644 considers itself the home agent for each such home address of the 3645 mobile node. As the set of on-link subnet prefixes on the home link 3646 changes over time, the home agent changes the set of home addresses 3647 for this mobile node for which it is serving as the home agent. 3649 If the mobile node has additional home addresses using a different 3650 interface identifier, then the mobile node SHOULD send an additional 3651 packet containing a Binding Update to its home agent to register the 3652 care-of address for each such other home address (or set of home 3653 addresses sharing an interface identifier). These additional Binding 3654 Updates MUST each be sent as a separate packet, since each MUST be 3655 protected by IPsec [13, 11, 12] to authenticate the Binding Update as 3656 coming from the home address being bound, as defined in Section 5.1. 3658 10.7. Dynamic Home Agent Address Discovery 3660 It is possible that when the mobile node needs to send a Binding 3661 Update to its home agent to register its new primary care-of address, 3662 as described in Section 10.6, the mobile node may not know the 3663 address of any router on its home link that can serve as a home agent 3664 for it. For example, some nodes on its home link may have been 3665 reconfigured while the mobile node has been away from home, such that 3666 the router that was operating as the mobile node's home agent has 3667 been replaced by a different router serving this role. 3669 In this case, the mobile node MAY use the dynamic home agent address 3670 discovery mechanism to find the address of a suitable home agent on 3671 its home link. To do so, the mobile node sends an ICMP Home Agent 3672 Address Discovery Request message to the "Mobile IPv6 Home-Agents" 3673 anycast address [10] for its home subnet prefix. This packet MUST 3674 NOT a Home Address option and must be sent using the mobile node's 3675 care-of address as the Source Address in the packet's IP header 3676 (the packet is sent from the care-of address, not using Mobile IP). 3677 As described in Section 9.2, the home agent on its home link that 3678 receives this Request message will return an ICMP Home Agent Address 3679 Discovery Reply message, giving this home agent's own global unicast 3680 IP address along with a list of the global unicast IP address of each 3681 other home agent operating on the home link. 3683 The mobile node, upon receiving this Home Agent Address Discovery 3684 Reply message, MAY then send its home registration Binding Update to 3685 the home agent address given as the IP Source Address of the packet 3686 carrying the Reply message or to any of the unicast IP addresses 3687 listed in the Home Agent Addresses field in the Reply. For example, 3688 if necessary, the mobile node MAY attempt its home registration 3689 with each of these home agents, in turn, by sending each a Binding 3690 Update and waiting for the matching Binding Acknowledgement, until 3691 its registration is accepted by one of these home agents. In trying 3692 each of the returned home agent addresses, the mobile node SHOULD try 3693 each in the order listed in the Home Agent Addresses field in the 3694 received Home Agent Address Discovery Reply message. If the home 3695 agent identified by the Source Address field in the IP header of the 3696 packet carrying the Home Agent Address Discovery Reply message is 3697 not listed in the Home Agent Addresses field in the Reply, it SHOULD 3698 be tried before the first address given in the list; otherwise, it 3699 SHOULD be tried in its listed order. 3701 If the mobile node has a current registration with some home agent 3702 on its home link (the Lifetime for that registration has not yet 3703 expired), then the mobile node MUST attempt any new registration 3704 first with that home agent. If that registration attempt fails 3705 (e.g., times out or is rejected), the mobile node SHOULD then 3706 reattempt this registration with another home agent on its home link. 3707 If the mobile node knows of no other suitable home agent, then it MAY 3708 attempt the dynamic home agent address discovery mechanism described 3709 above. 3711 10.8. Sending Binding Updates to Correspondent Nodes 3713 A mobile node MAY send a Binding Update to any correspondent node at 3714 any time to allow the correspondent node to cache the mobile node's 3715 current care-of address (subject to the rate limiting defined in 3716 Section 10.11). In any Binding Update sent by a mobile node, the 3717 care-of address (either the Source Address in the packet's IPv6 3718 header or the Care-of Address field in the Binding Update) MUST be 3719 set to one of the care-of addresses currently in use by the mobile 3720 node or to the mobile node's home address. 3722 If set to one of the mobile node's current care-of addresses (the 3723 care-of address given MAY differ from the mobile node's primary 3724 care-of address), the Binding Update requests the correspondent node 3725 to create or update an entry for the mobile node in the correspondent 3726 node's Binding Cache to record this care-of address for use in 3727 sending future packets to the mobile node. In this case, the 3728 Lifetime value sent in the Binding Update MUST be no greater than 3729 the remaining lifetime of the mobile node's home registration of its 3730 primary care-of address at its home agent. 3732 If, instead, the care-of address is set to the mobile node's home 3733 address, the Binding Update requests the correspondent node to delete 3734 any existing Binding Cache entry that it has for the mobile node. 3735 A mobile node MAY set the care-of address differently for sending 3736 Binding Updates to different correspondent nodes. 3738 When sending any Binding Update, the mobile node MUST record in its 3739 Binding Update List the following fields from the Binding Update: 3741 - The IP address of the node to which the Binding Update was sent. 3743 - The home address for which the Binding Update was sent (the value 3744 in the Home Address option in the packet carrying the Binding 3745 Update). 3747 - The remaining lifetime of the binding, initialized from the 3748 Lifetime field sent in the Binding Update. 3750 The mobile node MUST retain in its Binding Update List information 3751 about all Binding Updates sent, for which the lifetime of the binding 3752 has not yet expired. However, when sending a Binding Update, if an 3753 entry already exists in the mobile node's Binding Update List for 3754 an earlier Binding Update sent to that same destination node, the 3755 existing Binding Update List entry is updated to reflect the new 3756 Binding Update rather than creating a new Binding Update List entry. 3758 In general, when a mobile node sends a Binding Update to its home 3759 agent to register a new primary care-of address (as described in 3760 Section 10.6), the mobile node will also send a Binding Update to 3761 each other node for which an entry exists in the mobile node's 3762 Binding Update List. Thus, other relevant nodes are generally kept 3763 updated about the mobile node's binding and can send packets directly 3764 to the mobile node using the mobile node's current care-of address. 3766 The mobile node, however, need not send these Binding Updates 3767 immediately after configuring a new care-of address. For example, 3768 since the Binding Update is a destination option and can be included 3769 in any packet sent by a mobile node, the mobile node MAY delay 3770 sending a new Binding Update to any correspondent node for a 3771 short period of time, in hopes that the needed Binding Update 3772 can be included in some packet that the mobile node sends to that 3773 correspondent node for some other reason (for example, as part of 3774 some TCP connection in use). In this case, when sending a packet 3775 to some correspondent node, the mobile node SHOULD check in its 3776 Binding Update List to determine if a new Binding Update to this 3777 correspondent node is needed, and SHOULD include the new Binding 3778 Update in this packet as necessary. 3780 In addition, when a mobile node receives a packet for which the 3781 mobile node can deduce that the original sender of the packet has 3782 no Binding Cache entry for the mobile node, or for which the mobile 3783 node can deduce that the original sender of the packet has an 3784 out-of-date care-of address for the mobile node in its Binding Cache, 3785 the mobile node SHOULD return a Binding Update to the sender giving 3786 its current care-of address (subject to the rate limiting defined 3787 in Section 10.11). In particular, the mobile node SHOULD return a 3788 Binding Update in response to receiving a packet that meets all of 3789 the following tests: 3791 - The packet was tunneled using IPv6 encapsulation. 3793 - The Destination Address in the tunnel (outer) IPv6 header is 3794 equal to any of the mobile node's care-of addresses. 3796 - The Destination Address in the original (inner) IPv6 header 3797 is equal to one of the mobile node's home addresses; or this 3798 Destination Address is equal to one of the mobile node's previous 3799 care-of addresses, if the mobile node has an entry in its Binding 3800 Update List representing an unexpired Binding Update sent to a 3801 home agent on the link on which its previous care-of address is 3802 located (Section 10.9). 3804 - The Source Address in the tunnel (outer) IPv6 header differs from 3805 the Source Address in the original (inner) IPv6 header. 3807 The destination address to which the Binding Update should be sent 3808 in response to receiving a packet meeting all of the above tests is 3809 the Source Address in the original (inner) IPv6 header of the packet. 3810 The home address for which this Binding Update is sent should be the 3811 Destination Address of the original (inner) packet. 3813 Binding Updates sent to correspondent nodes are not generally 3814 required to be acknowledged. However, if the mobile node wants 3815 to be sure that its new care-of address has been entered into a 3816 correspondent node's Binding Cache, the mobile node MAY request an 3817 acknowledgement by setting the Acknowledge (A) bit in the Binding 3818 Update. In this case, however, the mobile node SHOULD NOT continue 3819 to retransmit the Binding Update once the retransmission timeout 3820 period has reached MAX_BINDACK_TIMEOUT. 3822 A mobile node MAY choose to keep its location private from certain 3823 correspondent nodes, and thus need not send new Binding Updates to 3824 those correspondents. A mobile node MAY also send a Binding Update 3825 to such a correspondent node to instruct it to delete any existing 3826 binding for the mobile node from its Binding Cache, as described in 3827 Section 5.1. No other IPv6 nodes are authorized to send Binding 3828 Updates on behalf of a mobile node. 3830 10.9. Establishing Forwarding from a Previous Care-of Address 3832 When a mobile node connects to a new link and forms a new care-of 3833 address, it MAY establish forwarding of packets from a previous 3834 care-of address to this new care-of address. To do so, the mobile 3835 node sends a Binding Update to any home agent on the link on which 3836 the previous care-of address is located, indicating this previous 3837 care-of address as the home address for the binding, and giving its 3838 new care-of address as the binding's care-of address. Such packet 3839 forwarding allows packets destined to the mobile node from nodes that 3840 have not yet learned the mobile node's new care-of address, to be 3841 forwarded to the mobile node rather than being lost once the mobile 3842 node is no longer reachable at this previous care-of address. 3844 In constructing this Binding Update, the mobile node utilizes the 3845 following specific steps: 3847 - The Home Address field in the Home Address option in the packet 3848 carrying the Binding Update MUST be set to the previous care-of 3849 address for which packet forwarding is being established. 3851 - The care-of address for the new binding MUST be set to the new 3852 care-of address to which packets destined to the previous care-of 3853 address are to be forwarded. Normally, this care-of address for 3854 the binding is specified by setting the Source Address of the 3855 packet carrying the Binding Update, to this address. However, 3856 the mobile node MAY instead include an Alternate Care-of Address 3857 sub-option in the Binding Update option, with its Alternate 3858 Care-of Address field set to the care-of address for the binding. 3860 - The Home Registration (H) bit MUST also be set in this Binding 3861 Update, to request this home agent to temporarily act as a home 3862 agent for this previous care-of address. 3864 This home agent will thus tunnel packets for the mobile node (packets 3865 destined to its specified previous care-of address) to its new 3866 care-of address. All of the procedures defined for home agent 3867 operation MUST be followed by this home agent for this registration. 3869 Note that this home agent does not necessarily know (and need not 3870 know) the mobile node's (permanent) home address as part of this 3871 registration. 3873 The packet carrying the Binding Update MUST be addressed to 3874 this home agent's global unicast address. Normally, this global 3875 unicast address is learned by the mobile node based on the Router 3876 Advertisements received by the mobile node (Section 6.2) while 3877 attached to the link on which this previous care-of address and this 3878 home agent are located; the mobile node obtains this home agent 3879 address from its Home Agents List (Section 4.3). Alternatively, 3880 the mobile node MAY use dynamic home agent address discovery 3881 (Section 10.7) to discover the global unicast address of a home agent 3882 on this previous link, but it SHOULD use an address from its Home 3883 Agents List if available for the prefix it used in this previous 3884 care-of address. 3886 As with any packet containing a Binding Update 5.1, the Binding 3887 Update packet to this home agent MUST meet the IPsec requirements for 3888 Binding Updates, defined in Section 5.1. 3890 10.10. Retransmitting Binding Updates 3892 If, after sending a Binding Update in which the Acknowledge (A) 3893 bit is set, a mobile node fails to receive a valid, matching 3894 Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the 3895 mobile node SHOULD retransmit the Binding Update, until a Binding 3896 Acknowledgement is received. Such a retransmitted Binding Update 3897 MUST use a Sequence Number value greater than that used for the 3898 previous transmission of this Binding Update. The retransmissions by 3899 the mobile node MUST use an exponential back-off process, in which 3900 the timeout period is doubled upon each retransmission until either 3901 the node receives a Binding Acknowledgement or the timeout period 3902 reaches the value MAX_BINDACK_TIMEOUT. 3904 10.11. Rate Limiting for Sending Binding Updates 3906 A mobile node MUST NOT send Binding Updates about the same binding to 3907 any individual node more often than once per MAX_UPDATE_RATE seconds. 3908 After sending MAX_FAST_UPDATES consecutive Binding Updates to a 3909 particular node with the same care-of address, the mobile node SHOULD 3910 reduce its rate of sending Binding Updates to that node, to the rate 3911 of SLOW_UPDATE_RATE per second. The mobile node MAY continue to send 3912 Binding Updates at this slower rate indefinitely, in hopes that the 3913 node will eventually be able to process a Binding Update and begin 3914 to route its packets directly to the mobile node at its new care-of 3915 address. 3917 10.12. Receiving Binding Acknowledgements 3919 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 3920 node MUST validate the packet according to the following tests: 3922 - The packet meets the specific IPsec requirements for Binding 3923 Acknowledgements, defined in Section 5.2. 3925 - The Option Length field in the option is greater than or equal to 3926 11 octets. 3928 - The Sequence Number field matches the Sequence Number sent by the 3929 mobile node to this destination address in an outstanding Binding 3930 Update. 3932 Any Binding Acknowledgement not satisfying all of these tests MUST be 3933 silently ignored, although the remainder of the packet (i.e., other 3934 options, extension headers, or payload) SHOULD be processed normally 3935 according to any procedure defined for that part of the packet. 3937 When a mobile node receives a packet carrying a valid Binding 3938 Acknowledgement, the mobile node MUST examine the Status field as 3939 follows: 3941 - If the Status field indicates that the Binding Update was 3942 accepted (the Status field is less than 128), then the mobile 3943 node MUST update the corresponding entry in its Binding Update 3944 List to indicate that the Binding Update has been acknowledged. 3945 The mobile node MUST then stop retransmitting the Binding Update. 3947 - If the Status field indicates that the Binding Update was 3948 rejected (the Status field is greater than or equal to 128), then 3949 the mobile node MUST delete the corresponding Binding Update List 3950 entry (and MUST also stop retransmitting the Binding Update). 3951 Optionally, the mobile node MAY then take steps to correct the 3952 cause of the error and retransmit the Binding Update (with a new 3953 Sequence Number value), subject to the rate limiting restriction 3954 specified in Section 10.11. 3956 10.13. Receiving Binding Requests 3958 When a mobile node receives a packet containing a Binding Request, 3959 it SHOULD return to the sender a packet containing a Binding Update. 3960 The Lifetime field in this Binding Update SHOULD be set to a new 3961 lifetime, extending any current lifetime remaining from a previous 3962 Binding Update sent to this node (as indicated in any existing 3963 Binding Update List entry for this node), except that this lifetime 3964 MUST NOT exceed the remaining lifetime for the mobile node's primary 3965 care-of address registration at its home agent. When sending this 3966 Binding Update, the mobile node MUST update its Binding Update List 3967 in the same way as for any other Binding Update sent by the mobile 3968 node. 3970 Note, however, that the mobile node MAY choose to keep its current 3971 binding private from the sender of the Binding Request. In this 3972 case, the mobile node instead SHOULD returns a Binding Update to the 3973 sender, in which the Lifetime field is set to zero and the care-of 3974 address is set to the mobile node's home address. 3976 If the Binding Request for which the Binding Update is being returned 3977 contains a Unique Identifer Sub-Option, the Binding Update MUST also 3978 include a Unique Identifier Sub-Option. The unique identifier in the 3979 SUb-Option Data field of the Unique Identifier Sub-Option MUST be 3980 copied from the unique identifier carried in the Binding Request. 3982 10.14. Receiving ICMP Error Messages 3984 The Option Type value for a Binding Update option specifies that 3985 any node receiving this option that does not recognize the Option 3986 Type SHOULD return an ICMP Parameter Problem, Code 2, message to 3987 the sender of the packet containing the Binding Update option. If 3988 a node sending a Binding Update receives such an ICMP error message 3989 in response, it should record in its Binding Update List that future 3990 Binding Updates should not be sent to this destination. 3992 Likewise, although ALL IPv6 nodes (whether host or router, whether 3993 mobile or stationary) MUST implement the ability to correctly process 3994 received packets containing a Home Address option, all Option Type 3995 values in IPv6 include a specification of the behavior that a node 3996 receiving a packet containing this option performs if it does not 3997 implement receipt of that type of option. For the Home Address 3998 option, the Option Type value specifies that any node receiving 3999 this option that does not recognize the Option Type SHOULD return 4000 an ICMP Parameter Problem, Code 2, message to the sender of the 4001 packet containing the Home Address option. If a mobile node receives 4002 such an ICMP error message from some node indicating that it does 4003 not recognize the mobile node's Home Address option, the mobile 4004 node SHOULD log the error and then discard the ICMP message; this 4005 error message indicates that the node to which the original packet 4006 was addressed (the node returning the ICMP error message) does not 4007 correctly implement this required part of the IPv6 protocol. 4009 10.15. Receiving Local Router Advertisement Messages 4011 Each mobile node maintains a Home Agents List recording information 4012 about all home agents from which it receives a Router Advertisement, 4013 for which the home agent lifetime indicated in that Router 4014 Advertisement has not yet expired. This list is used by the mobile 4015 node to enable it to send a Binding Update to the global unicast 4016 address of a home agent on its previous link when it moves to a new 4017 link, as described in Section 10.9. On receipt of a valid Router 4018 Advertisement, as defined in the processing algorithm specified for 4019 Neighbor Discovery [17], the mobile node performs the following 4020 steps, in addition to any steps already required of it by Neighbor 4021 Discovery and by other procedures described in this document: 4023 - If the Home Agent (H) bit in the Router Advertisement is not 4024 set, skip all of the following steps. There are no special 4025 processing steps required by this aspect of Mobile IP for this 4026 Router Advertisement, since the Advertisement was not sent by a 4027 home agent. 4029 - Otherwise, extract the Source Address from the IP header of the 4030 Router Advertisement. This is the link-local IP address on this 4031 link of the home agent sending this Advertisement [17]. 4033 - Determine from the Router Advertisement the preference for this 4034 home agent. If the Router Advertisement contains a Home Agent 4035 Information Option, then the preference is taken from the Home 4036 Agent Preference field in the option; otherwise, the default 4037 preference of 0 SHOULD be used. 4039 - Determine from the Router Advertisement the lifetime for 4040 this home agent. If the Router Advertisement contains a Home 4041 Agent Information Option, then the lifetime is taken from 4042 the Home Agent Lifetime field in the option; otherwise, the 4043 lifetime specified by the Router Lifetime field in the Router 4044 Advertisement SHOULD be used. 4046 - If the link-local address of the home agent sending this 4047 Advertisement is already present in this mobile node's Home 4048 Agents List and the received home agent lifetime value is zero, 4049 immediately delete this entry in the Home Agents List. 4051 - Otherwise, if the link-local address of the home agent sending 4052 this Advertisement is already present in the receiving mobile 4053 node's Home Agents List, reset its lifetime and preference to the 4054 values determined above. 4056 - If the link-local address of the home agent sending this 4057 Advertisement, as determined above, is not already present in the 4058 Home Agents List maintained by the receiving mobile node, and 4059 the lifetime for the sending home agent, as determined above, 4060 is non-zero, create a new entry in the list, and initialize its 4061 lifetime and preference to the values determined above. 4063 - If the Home Agents List entry for the link-local address of 4064 the home agent sending this Advertisement was not deleted as 4065 described above, determine any global address(es) of the home 4066 agent based on each Prefix Information option received in 4067 this Advertisement in which the Router Address (R) bit is set 4068 (Section 6.2). For each such global address determined from this 4069 Advertisement, add this global address to the list of global 4070 addresses for this home agent in this Home Agents List entry. 4072 A mobile node SHOULD maintain an entry in its Home Agents List for 4073 each such valid home agent address until that entry's lifetime 4074 expires, after which time the entry MUST be deleted. 4076 10.16. Receiving Tunneled Router Advertisements 4078 Section 9.7 describes the operation of a home agent to support 4079 renumbering a mobile node's home subnet while the mobile node is 4080 away from home. The home agent tunnels certain Router Advertisement 4081 messages to the mobile node while away from home, giving "important" 4082 Prefix Information options that describe changes in the prefixes in 4083 use on the mobile node's home link. 4085 When a mobile node receives a tunneled Router Advertisement, it MUST 4086 validate it according to the following tests: 4088 - The Source Address of the IP packet carrying the Router 4089 Advertisement is the same as the home agent address to which the 4090 mobile node last sent an accepted "home registration" Binding 4091 Update to register its primary care-of address. 4093 - The packet MUST be protected by IPsec [13, 11, 12] to guard 4094 against malicious Router Advertisements. The IPsec protection 4095 MUST provide sender authentication, data integrity protection, 4096 and replay protection, covering the Router Advertisement. 4098 - The packet contains a Binding Request destination option. 4100 - The Binding Request option contains a Unique Identifier 4101 Sub-Option. 4103 Any received tunneled Router Advertisement not meeting all of these 4104 tests MUST be silently discarded. 4106 If a received tunneled Router Advertisement is not discarded 4107 according to the tests listed above, the mobile node MUST process the 4108 Router Advertisement as if it were connected to its home link [17]. 4109 Such processing may result in the mobile node configuring a new home 4110 address, although due to separation between preferred lifetime and 4111 valid lifetime, such changes should not affect most communication by 4112 the mobile node, in the same way as for nodes that are at home. 4114 In processing the packet containing this Router Advertisement, the 4115 mobile node SHOULD return to the home agent a Binding Update in 4116 response to the Binding Request carried in the packet. The correct 4117 formation of this Binding Update by the mobile node and processing 4118 of it by the home agent will be viewed by the home agent as an 4119 acknowledgement of this Router Advertisement, confirming to it that 4120 this Router Advertisement was received by the mobile node. 4122 In addition, if processing of this Router Advertisement resulted in 4123 the mobile node configuring a new home address, and if the method 4124 used for this new home address configuration would require the mobile 4125 node to perform Duplicate Address Detection [27] for the new address 4126 if the mobile node were located at home, then the mobile node MUST 4127 set the Duplicate Address Detection (D) bit in this Binding Update to 4128 its home agent, to request the home agent to perform this Duplicate 4129 Address Detection on behalf of the mobile node. 4131 10.17. Using Multiple Care-of Addresses 4133 As described in Section 10.5, a mobile node MAY use more than one 4134 care-of address at a time. Particularly in the case of many wireless 4135 networks, a mobile node effectively might be reachable through 4136 multiple links at the same time (e.g., with overlapping wireless 4137 cells), on which different on-link subnet prefixes may exist. A 4138 mobile node SHOULD select a primary care-of address from among those 4139 care-of addresses it has formed using any of these subnet prefixes, 4140 based on the movement detection mechanism in use, as described in 4141 Section 10.4. When the mobile node selects a new primary care-of 4142 address, it MUST register it with its home agent by sending it a 4143 Binding Update with the Home Registration (H) and Acknowledge (A) 4144 bits set, as described in Section 10.6. 4146 To assist with smooth handoffs, a mobile node SHOULD retain 4147 its previous primary care-of address as a (non-primary) care-of 4148 address, and SHOULD still accept packets at this address, even after 4149 registering its new primary care-of address with its home agent. 4150 This is reasonable, since the mobile node could only receive packets 4151 at its previous primary care-of address if it were indeed still 4152 connected to that link. If the previous primary care-of address was 4153 allocated using stateful Address Autoconfiguration [2], the mobile 4154 node may not wish to release the address immediately upon switching 4155 to a new primary care-of address. 4157 10.18. Routing Multicast Packets 4159 A mobile node that is connected to its home link functions in the 4160 same way as any other (stationary) node. Thus, when it is at home, 4161 a mobile node functions identically to other multicast senders and 4162 receivers. This section therefore describes the behavior of a mobile 4163 node that is not on its home link. 4165 In order to receive packets sent to some multicast group, a mobile 4166 node must join that multicast group. One method by which a mobile 4167 node MAY join the group is via a (local) multicast router on the 4168 foreign link being visited. The mobile node SHOULD use its care-of 4169 address sharing a subnet prefix with the multicast router, as 4170 the source IPv6 address of its multicast group membership control 4171 messages. 4173 Alternatively, a mobile node MAY join multicast groups via a 4174 bi-directional tunnel to its home agent. The mobile node tunnels its 4175 multicast group membership control packets to its home agent, and the 4176 home agent forwards multicast packets down the tunnel to the mobile 4177 node. 4179 A mobile node that wishes to send packets to a multicast group 4180 also has two options: (1) send directly on the foreign link being 4181 visited; or (2) send via a tunnel to its home agent. Because 4182 multicast routing in general depends upon the Source Address used in 4183 the IPv6 header of the multicast packet, a mobile node that tunnels a 4184 multicast packet to its home agent MUST use its home address as the 4185 IPv6 Source Address of the inner multicast packet. 4187 10.19. Returning Home 4189 A mobile node detects that it has returned to its home link through 4190 the movement detection algorithm in use (Section 10.4), when the 4191 mobile node detects that its home subnet prefix is again on-link. 4192 The mobile node SHOULD then send a Binding Update to its home agent, 4193 to instruct its home agent to no longer intercept or tunnel packets 4194 for it. In this Binding Update, the mobile node MUST set the care-of 4195 address for the binding (the Source Address field in the packet's 4196 IPv6 header) to the mobile node's own home address. As with other 4197 Binding Updates sent to register with its home agent, the mobile 4198 node MUST set the Acknowledge (A) and Home Registration (H) bits, 4199 and SHOULD retransmit the Binding Update until a matching Binding 4200 Acknowledgement is received. 4202 When sending this Binding Update to its home agent, the mobile 4203 node must be careful in how it uses Neighbor Soliciation [17] (if 4204 needed) to learn the home agent's link-layer address, since the home 4205 agent will be currently configured to defend the mobile node's home 4206 address for Duplicate Address Detection. In particular, a Neighbor 4207 Solicitation from the mobile node using its home address as the 4208 Source Address would be detected by the home agent as a duplicate 4209 address. In many cases, Neighbor Solicitation by the mobile node 4210 for the home agent's address will not be necessary, since the mobile 4211 node may have already learned the home agent's link-layer address, 4212 for example from a Source Link-Layer Address option in the Router 4213 Advertisement from which it learned that its home address was on-link 4214 and that the mobile node had thus returned home. If the mobile node 4215 does Neighbor Solicitation to learn the home agent's link-layer 4216 address, in this special case of the mobile node returning home, the 4217 mobile node MUST set the Source Address of this Neighbor Solicitation 4218 to the unspecified address. 4220 The mobile node then sends its Binding Update using the home agent's 4221 link-layer address, instructing its home agent to no longer serve 4222 as a home agent for it. By processing this Binding Update, the 4223 home agent will cease defending the mobile node's home address for 4224 Duplicate Address Detection and will no longer respond to Neighbor 4225 Solicitations for the mobile node's home address. The mobile node is 4226 then the only node on the link using the mobile node's home address. 4227 In addition, when returning home and configuring its home address 4228 on its network interface on its home link, the mobile node MUST NOT 4229 perform Duplicate Address Detection on its own home address, in order 4230 to avoid confusion or conflict with its home agent's use of the same 4231 address. 4233 After receiving the Binding Acknowledgement for its Binding Update 4234 to its home agent, the mobile node MUST multicast onto the home 4235 link (to the all-nodes multicast address) a Neighbor Advertisement 4236 message [17], to advertise the mobile node's own link-layer address 4237 for its own home address. The Target Address in this Neighbor 4238 Advertisement message MUST be set to the mobile node's home address, 4239 and the Advertisement MUST include a Target Link-layer Address option 4240 specifying the mobile node's link-layer address. The mobile node 4241 MUST multicast such a Neighbor Advertisement message for each of its 4242 home addresses, as defined by the current on-link prefixes, including 4243 its link-local address and site-local address. The Solicited 4244 Flag (S) in these Advertisements MUST NOT be set, since they were 4245 not solicited by any Neighbor Solicitation message. The Override 4246 Flag (O) in these Advertisements MUST be set, indicating that the 4247 Advertisements SHOULD override any existing Neighbor Cache entries at 4248 any node receiving them. 4250 Since multicasts on the local link (such as Ethernet) are typically 4251 not guaranteed to be reliable, the mobile node MAY retransmit these 4252 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 4253 increase their reliability. It is still possible that some nodes on 4254 the home link will not receive any of these Neighbor Advertisements, 4255 but these nodes will eventually be able to recover through use of 4256 Neighbor Unreachability Detection [17]. 4258 11. Protocol Constants 4260 INITIAL_BINDACK_TIMEOUT 1 second 4262 MAX_BINDACK_TIMEOUT 256 seconds 4264 MAX_UPDATE_RATE once per second 4266 SLOW_UPDATE_RATE once per 10 seconds 4268 MAX_FAST_UPDATES 5 transmissions 4270 MAX_ADVERT_REXMIT 3 transmissions 4272 12. IANA Considerations 4274 This document defines four new types of IPv6 destination options, 4275 each of which must be assigned an Option Type value: 4277 - The Binding Update option, described in Section 5.1; 4279 - The Binding Acknowledgement option, described in Section 5.2; 4281 - The Binding Request option, described in Section 5.3; and 4283 - The Home Address option, described in Section 5.4. 4285 In addition, this document defines two ICMP message types, used as 4286 part of the dynamic home agent address discovery mechanism: 4288 - The Home Agent Address Discovery Request message, described in 4289 Section 5.6; and 4291 - The Home Agent Address Discovery Reply message, described in 4292 Section 5.7. 4294 This document also defines two new Neighbor Discovery [17] options, 4295 which must be assigned Option Type values within the option numbering 4296 space for Neighbor Discovery messages: 4298 - The Advertisement Interval option, described in Section 6.3; and 4300 - The Home Agent Information option, described in Section 6.4. 4302 Finally, this document defines a new type of anycast address, which 4303 must be assigned a reserved value for use with any subnet prefix to 4304 define this anycast address on each subnet: 4306 - The "Mobile IPv6 Home-Agents" anycast address [10], used in the 4307 dynamic home agent address discovery mechanism described in 4308 Sections 9.2 and 10.7. 4310 13. Security Considerations 4312 13.1. Binding Updates, Acknowledgements, and Requests 4314 The Binding Update option described in this document will result 4315 in packets addressed to a mobile node being delivered instead to 4316 its care-of address. This ability to change the routing of these 4317 packets could be a significant vulnerability if any packet containing 4318 a Binding Update option was not authenticated. Such use of "remote 4319 redirection", for instance as performed by the Binding Update option, 4320 is widely understood to be a security problem in the current Internet 4321 if not authenticated [1]. 4323 The Binding Acknowledgement option also requires authentication, 4324 since, for example, an attacker could otherwise trick a mobile node 4325 into believing a different outcome from a registration attempt with 4326 its home agent. 4328 No authentication is required for the Binding Request option, since 4329 the use of this option does not modify or create any state in either 4330 the sender or the receiver. The Binding Request option does open 4331 some issues with binding privacy, but those issues can be dealt with 4332 either through existing IPsec encryption mechanisms or through use of 4333 firewalls. 4335 The existing IPsec replay protection mechanisms allow a "replay 4336 protection window" to support receiving packets out of order. 4337 Although appropriate for many forms of communication, Binding Updates 4338 MUST be applied only in the order sent. The Binding Update option 4339 thus includes a Sequence Number field to provide this necessary 4340 sequencing. The use of this Sequence Number together with IPsec 4341 replay protection is similar in many ways, for example, to the the 4342 sequence number in TCP. IPsec provides strong replay protection but 4343 no ordering, and the sequence number provides ordering but need not 4344 worry about replay protection such as through the sequence number 4345 wrapping around. 4347 13.2. Home Address Option 4349 No special authentication of the Home Address option is required, 4350 except that if the IPv6 header of a packet is covered by 4351 authentication, then that authentication MUST also cover the Home 4352 Address option; this coverage is achieved automatically by the 4353 definition of the Option Type code for the Home Address option 4354 (Section 5.4), since it indicates that the option is included in the 4355 authentication computation. Thus, even when authentication is used 4356 in the IPv6 header, the security of the Source Address field in the 4357 IPv6 header is not compromised by the presence of a Home Address 4358 option. Without authentication of the packet, then any field in the 4359 IPv6 header, including the Source Address field, and any other parts 4360 of the packet, including the Home Address option, can be forged or 4361 modified in transit. In this case, the contents of the Home Address 4362 option is no more suspect than any other part of the packet. 4364 The use of the Home Address option allows packets sent by a 4365 mobile node to pass normally through routers implementing ingress 4366 filtering [7]. Since the care-of address used in the Source Address 4367 field of the packet's IPv6 header is topologically correct for the 4368 sending location of the mobile node, ingress filtering can trace the 4369 location of the mobile node in the same way as can be done with any 4370 sender when ingress filtering is in use. 4372 However, if a node receiving a packet that includes a Home Address 4373 option implements the processing of this option by physically 4374 copying the Home Address field from the option into the IPv6 header, 4375 replacing the Source Address field there, then the ability to 4376 trace the true location of the sender is removed once this step 4377 in the processing is performed. This diminishing of the power of 4378 ingress filtering only occurs once the packet has been received at 4379 its ultimate destination, and does not affect the capability of 4380 ingress filtering while the packet is in transit. Furthermore, this 4381 diminishing can be entirely eliminated by appropriate implementation 4382 techniques in the receiving node. For example, the original contents 4383 of the Source Address field (the sending care-of address) could be 4384 saved elsewhere in memory with the packet, until all processing of 4385 the packet is completed. 4387 13.3. General Mobile Computing Issues 4389 The mobile computing environment is potentially very different from 4390 the ordinary computing environment. In many cases, mobile computers 4391 will be connected to the network via wireless links. Such links 4392 are particularly vulnerable to passive eavesdropping, active replay 4393 attacks, and other active attacks. Furthermore, mobile computers 4394 are more susceptible to loss or theft than stationary computers. 4395 Any secrets such as authentication or encryption keys stored on the 4396 mobile computer are thus subject to compromise in ways generally not 4397 common in the non-mobile environment. 4399 Users who have sensitive data that they do not wish others to have 4400 access to should use additional mechanisms (such as encryption) to 4401 provide privacy protection, but such mechanisms are beyond the scope 4402 of this document. Users concerned about traffic analysis should 4403 consider appropriate use of link encryption. If stronger location 4404 privacy is desired, the mobile node can create a tunnel to its home 4405 agent. Then, packets destined for correspondent nodes will appear 4406 to emanate from the home subnet, and it may be more difficult to 4407 pinpoint the location of the mobile node. Such mechanisms are all 4408 beyond the scope of this document. 4410 Changes from Previous Version of the Draft 4412 This appendix briefly lists some of the major changes in this 4413 draft relative to the previous version of this same draft, 4414 draft-ietf-mobileip-ipv6-10.txt: 4416 - Added material in Section 10.19 dealing with the problem of 4417 Duplicate Address Detection on the home link when the mobile node 4418 returns home. 4420 - Moved all specific requirements for use of IPsec with Binding 4421 Updates and Binding Acknowledgements to Sections 5.1 and 5.2, 4422 respectively. This avoids repeating the same requirements in 4423 possibly different ways in many places throughout the document. 4424 Instead, all such places now refer to Sections 5.1 or 5.2. 4426 - Defined in Sections 5.1 and 5.2 that all packets including a 4427 Binding Update or Binding Acknowledgement, respectively, MUST use 4428 AH to provide the required sender authentication, data integrity 4429 protection, and replay protection. Use of ESP for protecting the 4430 Binding Updates and Binding Acknowledgements is not currently 4431 defined in this document, since ESP does not protect the portion 4432 of the packet above the ESP header itself. 4434 - Corrected yet a few more minor typographical errors in places. 4436 Acknowledgements 4438 We would like to thank the members of the Mobile IP and IPng Working 4439 Groups for their comments and suggestions on this work. We would 4440 particularly like to thank (in alphabetical order) Fred Baker 4441 (Cisco), Josh Broch (Carnegie Mellon University), Rich Draves 4442 (Microsoft Research), Francis Dupont (INRIA), Jun-Ichiro Hagino (IIJ 4443 Research Laboratory), Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), 4444 Erik Nordmark (Sun Microsystems), Simon Nybroe (Ericsson Telebit), 4445 David Oran (Cisco), Basavaraj Patil (Nokia), Phil Roberts (Motorola), 4446 Patrice Romand (Bull S.A.), Tom Soderlund (Nokia Research), Hesham 4447 Soliman (Ericsson), Jim Solomon (RedBack Networks), Benny Van Houdt 4448 (University of Antwerp), and Xinhua Zhao (Stanford University) for 4449 their detailed reviews of earlier versions of this document. Their 4450 suggestions have helped to improve both the design and presentation 4451 of the protocol. 4453 We would also like to thank the participants in the Mobile IPv6 4454 testing event held at Nancy, France, September 15-17, 1999, for 4455 their valuable feedback as a result of interoperability testing 4456 of four Mobile IPv6 implementations coming from four different 4457 organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC 4458 (FreeBSD), and INRIA (FreeBSD). Finally, we would like to thank the 4459 feedback from the implementors who participated in the Mobile IPv6 4460 interoperability testing at Connectathon 2000 in San Jose, 4461 California, March 6-9, 2000. 4463 References 4465 [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 4466 ACM Computer Communications Review, 19(2), March 1989. 4468 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 4469 Protocol for IPv6 (DHCPv6), February 1999. Work in progress. 4471 [3] Scott Bradner. Key words for use in RFCs to indicate 4472 requirement levels. RFC 2119, March 1997. 4474 [4] Alex Conta and Stephen Deering. Generic packet tunneling in 4475 IPv6 specification. RFC 2473, December 1998. 4477 [5] Alex Conta and Stephen Deering. Internet Control Message 4478 Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6) 4479 specification. RFC 2463, December 1998. 4481 [6] Stephen E. Deering and Robert M. Hinden. Internet Protocol 4482 version 6 (IPv6) specification. RFC 2460, December 1998. 4484 [7] Paul Ferguson and Daniel Senie. Network ingress filtering: 4485 Defeating denial of service attacks which employ IP source 4486 address spoofing. RFC 2267, January 1998. 4488 [8] Dan Harkins and Dave Carrel. The Internet Key Exchange (IKE). 4489 RFC 2409, November 1998. 4491 [9] Robert M. Hinden and Stephen E. Deering. IP Version 6 4492 addressing architecture. RFC 2373, July 1998. 4494 [10] David B. Johnson and Stephen E. Deering. Reserved IPv6 subnet 4495 anycast addresses. RFC 2526, March 1999. 4497 [11] Stephen Kent and Randall Atkinson. IP Authentication header. 4498 RFC 2402, November 1998. 4500 [12] Stephen Kent and Randall Atkinson. IP Encapsulating Security 4501 Payload (ESP). RFC 2406, November 1998. 4503 [13] Stephen Kent and Randall Atkinson. Security architecture for 4504 the Internet Protocol. RFC 2401, November 1998. 4506 [14] Douglas Maughan, Mark Schneider, Mark Schertler, and Jeff 4507 Turner. Internet Security Association and Key Management 4508 Protocol (ISAKMP). RFC 2408, November 1998. 4510 [15] P. Mockapetris. Domain Names -- concepts and facilities. 4511 RFC 1034, November 1987. 4513 [16] P. Mockapetris. Domain Names -- implementation and 4514 specification. RFC 1035, November 1987. 4516 [17] Thomas Narten, Erik Nordmark, and William Allen Simpson. 4517 Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December 4518 1998. 4520 [18] Charles Perkins. IP encapsulation within IP. RFC 2003, October 4521 1996. 4523 [19] Charles Perkins, editor. IP mobility support. RFC 2002, 4524 October 1996. 4526 [20] Charles Perkins. Minimal encapsulation within IP. RFC 2004, 4527 October 1996. 4529 [21] Charles Perkins and David B. Johnson. Route optimization in 4530 Mobile IP, February 1999. Work in progress. 4532 [22] Derrell Piper. The Internet IP security domain of 4533 interpretation for ISAKMP. RFC 2407, November 1998. 4535 [23] David C. Plummer. An Ethernet address resolution protocol: 4536 Or converting network protocol addresses to 48.bit Ethernet 4537 addresses for transmission on Ethernet hardware. RFC 826, 4538 November 1982. 4540 [24] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 4542 [25] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 4543 September 1981. 4545 [26] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 4546 October 1994. See also http://www.iana.org/numbers.html. 4548 [27] Susan Thomson and Thomas Narten. IPv6 stateless address 4549 autoconfiguration. RFC 2462, December 1998. 4551 Chair's Address 4553 The Working Group can be contacted via its current chairs: 4555 Phil Roberts 4556 Motorola 4557 1501 West Shure Drive 4558 Arlington Heights, IL 60004 4560 Phone: +1 847 632-3148 4561 E-mail: qa3445@email.mot.com 4563 Basavaraj Patil 4564 Nokia 4565 6000 Connection Drive 4566 M/S M8-540 4567 Irving, TX 75039 4568 USA 4570 Phone: +1 972 894-6709 4571 Fax: +1 972 894-5349 4572 E-mail: raj.patil@nokia.com 4574 Authors' Addresses 4576 Questions about this document can also be directed to the authors: 4578 David B. Johnson 4579 Carnegie Mellon University 4580 Computer Science Department 4581 5000 Forbes Avenue 4582 Pittsburgh, PA 15213-3891 4583 USA 4585 Phone: +1 412 268-7399 4586 Fax: +1 412 268-5576 4587 E-mail: dbj@cs.cmu.edu 4589 Charles Perkins 4590 Nokia 4591 313 Fairchild Drive 4592 Mountain View, CA 94043 4593 USA 4595 Phone: +1 650 625-2986 4596 Fax: +1 650 691-2170 4597 E-mail: charliep@iprg.nokia.com