idnits 2.17.1 draft-ietf-mobileip-ipv6-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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. == 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: - Specified in Section 8 that in processing a Home Address option in a received packet, 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. This restriction prevents confusion in the meaning of these other destination options. -- 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 (18 November 1998) is 9262 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-10 == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-ipv6-spec-v2-00 ** Obsolete normative reference: RFC 2267 (ref. '6') (Obsoleted by RFC 2827) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-02 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-01 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-02 == Outdated reference: A later version (-02) exists of draft-ietf-ipngwg-discovery-v2-00 ** Obsolete normative reference: RFC 2002 (ref. '15') (Obsoleted by RFC 3220) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-07 -- Possible downref: Normative reference to a draft: ref. '17' ** Obsolete normative reference: RFC 793 (ref. '20') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '21') (Obsoleted by RFC 3232) == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-addrconf-v2-00 Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group David B. Johnson 2 INTERNET-DRAFT Carnegie Mellon University 3 Charles Perkins 4 Sun Microsystems 5 18 November 1998 7 Mobility Support in IPv6 9 11 Status of This Memo 13 This document is a submission by the Mobile IP Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of current Internet-Drafts, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 31 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 32 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 33 (US West Coast). 35 Abstract 37 This document specifies the operation of mobile computers using IPv6. 38 Each mobile node is always identified by its home address, regardless 39 of its current point of attachment to the Internet. While situated 40 away from its home, a mobile node is also associated with a care-of 41 address, which provides information about the mobile node's current 42 location. IPv6 packets addressed to a mobile node's home address are 43 transparently routed to its care-of address. The protocol enables 44 IPv6 nodes to cache the binding of a mobile node's home address with 45 its care-of address, and to then send any packets destined for the 46 mobile node directly to it at this care-of address. To support this 47 operation, Mobile IPv6 defines four new IPv6 destination options, 48 including one that MUST be supported in packets received by any node, 49 whether mobile or stationary. 51 Contents 53 Status of This Memo i 55 Abstract i 57 1. Introduction 1 59 2. Comparison with Mobile IP for IPv4 3 61 3. Terminology 6 62 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 64 3.3. Specification Language . . . . . . . . . . . . . . . . . 8 66 4. Overview of Mobile IPv6 9 67 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 68 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11 69 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 13 70 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 16 72 5. New IPv6 Destination Options 19 73 5.1. Binding Update Option Format . . . . . . . . . . . . . . 19 74 5.2. Binding Acknowledgement Option Format . . . . . . . . . . 23 75 5.3. Binding Request Option Format . . . . . . . . . . . . . . 27 76 5.4. Home Address Option Format . . . . . . . . . . . . . . . 29 77 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 31 79 6. Modifications to IPv6 Neighbor Discovery 33 80 6.1. Modified Router Advertisement Message Format . . . . . . 33 81 6.2. Modified Prefix Information Option Format . . . . . . . . 34 82 6.3. New Advertisement Interval Option Format . . . . . . . . 36 83 6.4. New Home Agent Information Option Format . . . . . . . . 37 84 6.5. Changes to Sending Router Advertisements . . . . . . . . 39 85 6.6. Changes to Sending Router Solicitations . . . . . . . . . 40 87 7. Requirements for IPv6 Nodes 42 88 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 42 89 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 42 90 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 42 91 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 43 93 8. Correspondent Node Operation 45 94 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 45 95 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 45 96 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 46 97 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 47 98 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 47 99 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 48 100 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 48 101 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 49 102 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 50 104 9. Home Agent Operation 52 105 9.1. Receiving Router Advertisement Messages . . . . . . . . . 52 106 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 53 107 9.3. Primary Care-of Address Registration . . . . . . . . . . 55 108 9.4. Primary Care-of Address De-registration . . . . . . . . . 57 109 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 58 110 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 60 111 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 61 113 10. Mobile Node Operation 64 114 10.1. Sending Packets While Away from Home . . . . . . . . . . 64 115 10.2. Receiving Packets While Away from Home . . . . . . . . . 66 116 10.3. Movement Detection . . . . . . . . . . . . . . . . . . . 67 117 10.4. Forming New Care-of Addresses . . . . . . . . . . . . . . 70 118 10.5. Sending Binding Updates to the Home Agent . . . . . . . . 71 119 10.6. Dynamic Home Agent Address Discovery . . . . . . . . . . 72 120 10.7. Sending Binding Updates to Correspondent Nodes . . . . . 73 121 10.8. Sending Binding Updates to the Previous Default Router . 75 122 10.9. Retransmitting Binding Updates . . . . . . . . . . . . . 76 123 10.10. Rate Limiting for Sending Binding Updates . . . . . . . . 76 124 10.11. Receiving Binding Acknowledgements . . . . . . . . . . . 76 125 10.12. Receiving Binding Requests . . . . . . . . . . . . . . . 77 126 10.13. Receiving ICMP Error Messages . . . . . . . . . . . . . . 78 127 10.14. Receiving Tunneled Router Advertisements . . . . . . . . 78 128 10.15. Using Multiple Care-of Addresses . . . . . . . . . . . . 79 129 10.16. Routing Multicast Packets . . . . . . . . . . . . . . . . 80 130 10.17. Returning Home . . . . . . . . . . . . . . . . . . . . . 80 132 11. Constants 82 134 12. IANA Considerations 83 136 13. Security Considerations 84 137 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 84 138 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 84 139 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 85 141 Changes from Previous Draft 87 143 Acknowledgements 89 145 References 90 147 Chair's Address 92 149 Authors' Addresses 93 150 1. Introduction 152 This document specifies the operation of mobile computers using 153 Internet Protocol Version 6 (IPv6) [5]. Without specific support 154 for mobility in IPv6, packets destined to a mobile node (host or 155 router) would not be able to reach it while the mobile node is away 156 from its home link (the link on which its home IPv6 subnet prefix is 157 in use), since routing is based on the subnet prefix in a packet's 158 destination IP address. In order to continue communication in spite 159 of its movement, a mobile node could change its IP address each time 160 it moves to a new link, but the mobile node would then not be able 161 to maintain transport and higher-layer connections when it changes 162 location. Mobility support in IPv6 is particularly important, as 163 mobile computers are likely to account for a majority or at least a 164 substantial fraction of the population of the Internet during the 165 lifetime of IPv6. 167 The protocol operation defined here, known as Mobile IPv6, allows a 168 mobile node to move from one link to another without changing the 169 mobile node's IP address. A mobile node is always addressable by 170 its "home address", an IP address assigned to the mobile node within 171 its home subnet prefix on its home link. Packets may be routed to 172 the mobile node using this address regardless of the mobile node's 173 current point of attachment to the Internet, and the mobile node may 174 continue to communicate with other nodes (stationary or mobile) after 175 moving to a new link. The movement of a mobile node away from its 176 home link is thus transparent to transport and higher-layer protocols 177 and applications. 179 The Mobile IPv6 protocol is just as suitable for mobility across 180 homogeneous media as for mobility across heterogeneous media. For 181 example, Mobile IPv6 facilitates node movement from one Ethernet 182 segment to another as well as it facilitates node movement from an 183 Ethernet segment to a wireless LAN cell, with the mobile node's IP 184 address remaining unchanged in spite of such movement. 186 One can think of the Mobile IPv6 protocol as solving the "macro" 187 mobility management problem. More "micro" mobility management 188 applications -- for example, handoff among wireless transceivers, 189 each of which covers only a very small geographic area -- are 190 possibly more suited to other solutions. For example, in many 191 current wireless LAN products, link-layer mobility mechanisms allow a 192 "handoff" of a mobile node from one cell to another, reestablishing 193 link-layer connectivity to the node in each new location. As long 194 as such handoff occurs only within cells of the mobile node's home 195 link, such link-layer mobility mechanisms are likely to offer faster 196 convergence and lower overhead than Mobile IPv6. Extensions to the 197 Mobile IPv6 protocol are also possible to support a more local, 198 hierarchical form of mobility management, but such extensions are 199 beyond the scope of this document. 201 The protocol specified in this document solves the problem of 202 transparently routing packets to and from mobile nodes while away 203 from home. However, it does not attempt to solve all general 204 problems related to the use of mobile computers or wireless networks. 205 In particular, this protocol does not attempt to solve: 207 - Handling links with partial reachability, such as typical 208 wireless networks. Some aspects of this problem are addressed 209 by the movement detection procedure described in Section 10.3, 210 but no attempt has been made to fully solve this problem in its 211 general form. Most aspects of this problem can be solved by the 212 workaround of restricting such networks to only one router per 213 link, although there are still possible hidden terminal problems 214 when two nodes on the same link (on opposite sides of the router) 215 attempt to communicate directly. 217 - Access control on a link being visited by a mobile node. This 218 is a general problem any time an untrusted node is allowed 219 to connect to any link layer. It is independent whether the 220 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 221 address on the link. 223 2. Comparison with Mobile IP for IPv4 225 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 226 natural combination of the experiences gained from the development 227 of Mobile IP support in IPv4 (Mobile IPv4) [15, 14, 16], together 228 with the opportunities provided by the design and deployment of a new 229 version of IP itself (IPv6) and the new protocol features offered 230 by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, 231 but the protocol is now fully integrated into IP and provides many 232 improvements over Mobile IPv4. This section summarizes the major 233 differences between Mobile IPv4 and Mobile IPv6: 235 - Support for what is known in Mobile IPv4 as "Route 236 Optimization" [17] is now built in as a fundamental part 237 of the protocol, rather than being added on as a optional 238 set of extensions that may not be supported by all nodes 239 as in Mobile IPv4. This integration of Route Optimization 240 functionality allows direct routing from any correspondent node 241 to any mobile node, without needing to pass through the mobile 242 node's home network and be forwarded by its home agent, and thus 243 eliminates the problem of "triangle routing" present in the base 244 Mobile IPv4 protocol [15]. This integration also allows the 245 Mobile IPv4 "registration" functionality and the Mobile IPv4 246 Route Optimization functionality to be performed by a single 247 protocol rather than two separate (and different) protocols. 249 - Support is also integrated into Mobile IPv6 -- and into IPv6 250 itself -- for allowing mobile nodes and Mobile IP to coexist 251 efficiently with routers that perform "ingress filtering" [6]. A 252 mobile node now uses its care-of address as the Source Address in 253 the IP header of packets it sends, allowing the packets to pass 254 normally through ingress filtering routers. The home address 255 of the mobile node is carried in the packet in a Home Address 256 destination option, allowing the use of the care-of address in 257 the packet to be transparent above the IP layer. The ability 258 to correctly process a Home Address option in a received packet 259 is required in all IPv6 nodes, whether mobile nor stationary, 260 whether host or router. 262 - The use of the care-of address as the Source Address in each 263 packet's IP header also simplifies routing of multicast packets 264 sent by a mobile node. With Mobile IPv4, the mobile node 265 had to tunnel multicast packets to its home agent in order to 266 transparently use its home address as the source of the multicast 267 packets. With Mobile IPv6, the use of the Home Address option 268 allows the home address to be used but still be compatible with 269 multicast routing that is based in part on the packet's Source 270 Address. 272 - There is no longer any need to deploy special routers as 273 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 274 mobile nodes make use of the enhanced features of IPv6, such 275 as Neighbor Discovery [13] and Address Autoconfiguration [22], 276 to operate in any location away from home without any special 277 support required from its local router. 279 - Unlike Mobile IPv4, Mobile IPv6 utilizes IPsec [8, 9, 10] for 280 all security requirements (sender authentication, data integrity 281 protection, and replay protection) for Binding Updates (which 282 serve the role of both registration and Route Optimization in 283 Mobile IPv4). Mobile IPv4 relies on its own security mechanisms 284 for these functions, based on statically configured "mobility 285 security associations". 287 - The movement detection mechanism in Mobile IPv6 provides 288 bidirectional confirmation of a mobile node's ability to 289 communicate with its default router in its current location 290 (packets that the router sends are reaching the mobile node, and 291 packets that the mobile node sends are reaching the router). 292 This confirmation provides a detection of the "black hole" 293 situation that may exist in some wireless environments where the 294 link to the router does not work equally well in both directions, 295 such as when the mobile node has moved out of good wireless 296 transmission range from the router. The mobile node may then 297 attempt to find a new router and begin using a new care-of 298 address if its link to its current router is not working well. 299 In contrast, in Mobile IPv4, only the forward direction (packets 300 from the router are reaching the mobile node) is confirmed, 301 allowing the black hole condition to persist. 303 - Most packets sent to a mobile node while away from home in 304 Mobile IPv6 are tunneled using an IPv6 Routing header rather than 305 IP encapsulation, whereas Mobile IPv4 must use encapsulation 306 for all packets. The use of a Routing header requires less 307 additional header bytes to be added to the packet, reducing the 308 overhead of Mobile IP packet delivery. To avoid modifying the 309 packet in flight, however, packets intercepted and tunneled 310 by a mobile node's home agent in Mobile IPv6 must still use 311 encapsulation for tunneling. 313 - While a mobile node is away from home, its home agent intercepts 314 any packets for the mobile node that arrive at the home network, 315 using IPv6 Neighbor Discovery [13] rather than ARP [18] as is 316 used in Mobile IPv4. The use of Neighbor Discovery improves 317 the robustness of the protocol (e.g., due to the Neighbor 318 Advertisement "override" bit) and simplifies implementation 319 of Mobile IP due to the ability to not be concerned with any 320 particular link layer as is required in ARP. 322 - The use of IPv6 encapsulation (and the Routing header) removes 323 the need in Mobile IPv6 to manage "tunnel soft state", which was 324 required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 325 to the definition of ICMP for IPv6, the use of tunnel soft state 326 is no longer required in IPv6 for correctly relaying ICMP error 327 messages from within the tunnel back to the original sender of 328 the packet. 330 - The dynamic home agent address discovery mechanism in Mobile IPv6 331 uses IPv6 anycast and returns a single reply to the mobile node, 332 rather than the corresponding Mobile IPv4 mechanism that used 333 IPv4 directed broadcast and returned a separate reply from each 334 home agent on the mobile node's home link. The Mobile IPv6 335 mechanism is more efficient and more reliable, since only 336 one packet need be sent back to the mobile node and since the 337 mobile node is less likely to lose one of the replies because no 338 "implosion" of replies is required by the protocol. 340 - Mobile IPv6 defines an Advertisement Interval option on 341 Router Advertisements (equivalent to Agent Advertisements in 342 Mobile IPv4), allowing a mobile node to decide for itself how 343 many Router Advertisements (Agent Advertisements) it is willing 344 to miss before declaring its current router unreachable. 346 - The use of IPv6 destination options allows all Mobile IPv6 347 control traffic to be piggybacked on any existing IPv6 packets, 348 whereas in Mobile IPv4 and its Route Optimization extensions, 349 separate UDP packets were required for each control message. 351 3. Terminology 353 3.1. General Terms 355 IP 357 Internet Protocol Version 6 (IPv6). 359 node 361 A device that implements IP. 363 router 365 A node that forwards IP packets not explicitly addressed to 366 itself. 368 host 370 Any node that is not a router. 372 link 374 A communication facility or medium over which nodes can 375 communicate at the link layer, such as an Ethernet (simple or 376 bridged). A link is the layer immediately below IP. 378 interface 380 A node's attachment to a link. 382 subnet prefix 384 A bit string that consists of some number of initial bits of an 385 IP address. 387 interface identifier 389 A number used to identify a node's interface on a link. The 390 interface identifier is the remaining low-order bits in the 391 node's IP address after the subnet prefix. 393 link-layer address 395 A link-layer identifier for an interface, such as IEEE 802 396 addresses on Ethernet links. 398 packet 400 An IP header plus payload. 402 3.2. Mobile IPv6 Terms 404 home address 406 An IP address assigned to a mobile node within its home link. 408 home subnet prefix 410 The IP subnet prefix corresponding to a mobile node's home 411 address. 413 home link 415 The link on which a mobile node's home subnet prefix is 416 defined. Standard IP routing mechanisms will deliver packets 417 destined for a mobile node's home address to its home link. 419 mobile node 421 A node that can change its point of attachment from one link to 422 another, while still being reachable via its home address. 424 movement 426 A change in a mobile node's point of attachment to the Internet 427 such that it is no longer connected to the same link as it was 428 previously. If a mobile node is not currently attached to its 429 home link, the mobile node is said to be "away from home". 431 correspondent node 433 A peer node with which a mobile node is communicating. The 434 correspondent node may be either mobile or stationary. 436 foreign subnet prefix 438 Any IP subnet prefix other than the mobile node's home subnet 439 prefix. 441 foreign link 443 Any link other than the mobile node's home link. 445 home agent 447 A router on a mobile node's home link with which the mobile 448 node has registered its current care-of address. While the 449 mobile node is away from home, the home agent intercepts 450 packets on the home link destined to the mobile node's home 451 address, encapsulates them, and tunnels them to the mobile 452 node's registered care-of address. 454 care-of address 456 An IP address associated with a mobile node while visiting a 457 foreign link; the subnet prefix of this IP address is a foreign 458 subnet prefix. Among the multiple care-of addresses that a 459 mobile node may have at a time (e.g., with different subnet 460 prefixes), the one registered with the mobile node's home agent 461 is called its "primary" care-of address. 463 binding 465 The association of the home address of a mobile node with a 466 care-of address for that mobile node, along with the remaining 467 lifetime of that association. 469 3.3. Specification Language 471 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 472 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 473 document are to be interpreted as described in RFC 2119 [3]. 475 4. Overview of Mobile IPv6 477 4.1. Basic Operation 479 A mobile node is always addressable by its home address, whether it 480 is currently attached to its home link or is away from home. While 481 a mobile node is at home, packets addressed to its home address are 482 routed to it using conventional Internet routing mechanisms in the 483 same way as if the node were never mobile. Since the subnet prefix 484 of a mobile node's home address is the subnet prefix (or one of the 485 subnet prefixes) on the mobile node's home link (it is the mobile 486 node's home subnet prefix), packets addressed to it will be routed to 487 its home link. 489 While a mobile node is attached to some foreign link away from home, 490 it is also addressable by one or more care-of addresses, in addition 491 to its home address. A care-of address is an IP address associated 492 with a mobile node while visiting a particular foreign link. The 493 subnet prefix of a mobile node's care-of address is the subnet prefix 494 (or one of the subnet prefixes) on the foreign link being visited by 495 the mobile node; if the mobile node is connected to this foreign link 496 while using that care-of address, packets addressed to this care-of 497 address will be routed to the mobile node in its location away from 498 home. 500 The association between a mobile node's home address and care-of 501 address is known as a "binding" for the mobile node. A mobile node 502 typically acquires its care-of address through stateless [22] or 503 stateful (e.g., DHCPv6 [2]) address autoconfiguration, according 504 to the methods of IPv6 Neighbor Discovery [13]. Other methods 505 of acquiring a care-of address are also possible, such as static 506 pre-assignment by the owner or manager of a particular foreign link, 507 but details of such other methods are beyond the scope of this 508 document. 510 While away from home, a mobile node registers one of its care-of 511 addresses with a router on its home link, requesting this router 512 to function as the "home agent" for the mobile node. This binding 513 registration is done by the mobile node sending to the home agent 514 a packet containing a "Binding Update" destination option; the 515 home agent then replies to the mobile node by returning a packet 516 containing a "Binding Acknowledgement" destination option. The 517 care-of address in this binding registered with its home agent is 518 known as the mobile node's "primary care-of address". The mobile 519 node's home agent thereafter uses proxy Neighbor Discovery to 520 intercept any IPv6 packets addressed to the mobile node's home 521 address (or home addresses) on the home link, and tunnels each 522 intercepted packet to the mobile node's primary care-of address. 523 To tunnel each intercepted packet, the home agent encapsulates the 524 packet using IPv6 encapsulation [4], with the outer IPv6 header 525 addressed to the mobile node's primary care-of address. 527 Section 10.15 discusses the reasons why it may be desirable for 528 a mobile node to use more than one care-of address at the same 529 time. However, a mobile node's primary care-of address is distinct 530 among these in that the home agent maintains only a single care-of 531 address registered for each mobile node, and always tunnels a mobile 532 node's packets intercepted from its home link to this mobile node's 533 registered primary care-of address. The home agent thus need not 534 implement any policy to determine which of possibly many care-of 535 addresses to which to tunnel each intercepted packet, leaving the 536 mobile node entirely in control of this policy by which of its 537 care-of addresses it registers with its home agent. 539 It is possible that while a mobile node is away from home, some nodes 540 on its home link may be reconfigured, such that the router that was 541 operating as the mobile node's home agent is replaced by a different 542 router serving this role. In this case, the mobile node may not 543 know the IP address of its own home agent. Mobile IPv6 provides a 544 mechanism, known as "dynamic home agent address discovery", that 545 allows a mobile node to dynamically discover the IP address of a home 546 agent on its home link with which it may register its care-of address 547 while away from home. The mobile node sends a Binding Update to the 548 "Home-Agents anycast address" for its own home subnet prefix and thus 549 reaches one of the (possibly many) routers on its home link currently 550 operating as a home agent. This home agent rejects the mobile 551 node's Binding Update, but returns in the Binding Acknowledgement 552 in response a list of all home agents on the home link. This list 553 of home agents is maintained by each home agent on the home link 554 through use of the Home Agent (H) bit in each home agent's periodic 555 unsolicited multicast Router Advertisements. 557 The Binding Update and Binding Acknowledgement destination options, 558 together with a "Binding Request" destination option, are also used 559 to allow IPv6 nodes communicating with a mobile node, to dynamically 560 learn and cache the mobile node's binding. When sending a packet 561 to any IPv6 destination, a node checks its cached bindings for an 562 entry for the packet's destination address. If a cached binding for 563 this destination address is found, the node uses an IPv6 Routing 564 header [5] (instead of IPv6 encapsulation) to route the packet to 565 the mobile node by way of the care-of address indicated in this 566 binding. If, instead, the sending node has no cached binding for 567 this destination address, the node sends the packet normally (with 568 no Routing header), and the packet is subsequently intercepted and 569 tunneled by the mobile node's home agent as described above. Any 570 node communicating with a mobile node is referred to in this document 571 as a "correspondent node" of the mobile node, and may itself be 572 either a stationary node or a mobile node. 574 Since a Binding Update, Binding Acknowledgement, and Binding Request 575 are each represented in a packet as an IPv6 destination option [5], 576 they may be included in any IPv6 packet. Any of these options can be 577 sent in either of two ways: 579 - A Binding Update, Binding Acknowledgement, or Binding Request can 580 be included within any IPv6 packet carrying any payload such as 581 TCP [20] or UDP [19]. 583 - A Binding Update, Binding Acknowledgement, or Binding Request can 584 be sent as a separate IPv6 packet containing no payload. In this 585 case, the Next Header field in the last extension header in the 586 packet is set to the value 59, to indicate "No Next Header" [5]. 588 Mobile IPv6 also defines one additional IPv6 destination option. 589 When a mobile node sends a packet while away from home, it will 590 generally set the Source Address in the packet's IPv6 header to one 591 of its current care-of addresses, and will also include a "Home 592 Address" destination option in the packet, giving the mobile node's 593 home address. Many routers implement security policies such as 594 "ingress filtering" [6] that do not allow forwarding of packets that 595 appear to have a Source Address that is not topologically correct. 596 By using the care-of address as the IPv6 header Source Address, 597 the packet will be able to pass normally through such routers, 598 yet ingress filtering rules will still be able to locate the true 599 topological source of the packet in the same way as packets from 600 non-mobile nodes. By also including the Home Address option in each 601 packet, the sending mobile node can communicate its home address to 602 the correspondent node receiving this packet, allowing the use of 603 the care-of address to be transparent above the Mobile IPv6 support 604 level (e.g., at the transport layer). The inclusion of a Home 605 Address option in a packet affects only the correspondent node's 606 receipt of this single packet; no state is created or modified in the 607 correspondent node as a result of receiving a Home Address option in 608 a packet. 610 4.2. New IPv6 Destination Options 612 As discussed in general in Section 4.1, the following four new IPv6 613 destination options are defined for Mobile IPv6: 615 Binding Update 617 A Binding Update option is used by a mobile node to notify 618 a correspondent node or the mobile node's home agent of 619 its current binding. The Binding Update sent to the mobile 620 node's home agent to register its primary care-of address is 621 marked as a "home registration". Any packet that includes a 622 Binding Update option MUST also include either an AH [8] or 623 ESP [9] header providing sender authentication, data integrity 624 protection, and replay protection. The Binding Update option 625 is described in detail in Section 5.1. 627 Binding Acknowledgement 629 A Binding Acknowledgement option is used to acknowledge receipt 630 of a Binding Update, if an acknowledgement was requested 631 in the Binding Update. Any packet that includes a Binding 632 Acknowledgement option MUST also include either an AH [8] or 633 ESP [9] header providing sender authentication, data integrity 634 protection, and replay protection. The Binding Acknowledgement 635 option is described in detail in Section 5.2. 637 Binding Request 639 A Binding Request option is used to request a mobile node to 640 send to the requesting node a Binding Update containing the 641 mobile node's current binding. This option is typically used 642 by a correspondent node to refresh a cached binding for a 643 mobile node, when the cached binding is in active use but the 644 binding's lifetime is close to expiration. No authentication 645 is required for the Binding Request option. The Binding 646 Request option is described in detail in Section 5.3. 648 Home Address 650 A Home Address option is used in a packet sent by a mobile 651 node to inform the recipient of that packet of the mobile 652 node's home address. For packets sent by a mobile node while 653 away from home, the mobile node generally uses one of its 654 care-of addresses as the Source Address in the packet's IPv6 655 header. By including a Home Address option in the packet, the 656 correspondent node receiving the packet is able to substitute 657 the mobile node's home address for this care-of address when 658 processing the packet, thus making the use of the care-of 659 address transparent to the correspondent node. If the IP 660 header of a packet carrying a Home Address option is covered 661 by authentication, then the Home Address option MUST also be 662 covered by this authentication, but no other authentication is 663 required for the Home Address option. The Home Address option 664 is described in detail in Section 5.4. 666 Sub-options within the format of these options MAY be included after 667 the fixed portion of the option data specified in this document. The 668 presence of such sub-options will be indicated by the Option Length 669 field within the option. When the Option Length is greater than the 670 length required for the option specified here, the remaining octets 671 are interpreted as sub-options. The encoding and format of defined 672 sub-options are described in Section 5.5. 674 4.3. Conceptual Data Structures 676 This document describes the Mobile IPv6 protocol in terms of the 677 following three conceptual data structures: 679 Binding Cache 681 A cache, maintained by each IPv6 node, of bindings for other 682 nodes. The Binding Cache MAY be implemented in any manner 683 consistent with the external behavior described in this 684 document, for example by being combined with the node's 685 Destination Cache as maintained by Neighbor Discovery [13]. 686 When sending a packet, the Binding Cache is searched before the 687 Neighbor Discovery conceptual Destination Cache [13] (i.e., any 688 Binding Cache entry for this destination SHOULD take precedence 689 over any Destination Cache entry for the same destination). 690 Each Binding Cache entry conceptually contains the following 691 fields: 693 - The home address of the mobile node for which this is the 694 Binding Cache entry. This field is used as the key for 695 searching the Binding Cache for the destination address of 696 a packet being sent. If the destination address of the 697 packet matches the home address in the Binding Cache entry, 698 this entry SHOULD be used in routing that packet. 700 - The care-of address for the mobile node indicated by 701 the home address field in this Binding Cache entry. If 702 the destination address of a packet being routed by a 703 node matches the home address in this entry, the packet 704 SHOULD be routed to this care-of address, as described in 705 Section 8.9, for packets originated by this node, or in 706 Section 9.6, if this node is the mobile node's home agent 707 and the packet was intercepted by it on the home link. 709 - A lifetime value, indicating the remaining lifetime 710 for this Binding Cache entry. The lifetime value is 711 initialized from the Lifetime field in the Binding Update 712 that created or last modified this Binding Cache entry. 713 Once the lifetime on this entry expires, the entry MUST be 714 deleted from the Binding Cache. 716 - A flag indicating whether or not this Binding Cache entry 717 is a "home registration" entry. 719 - The value of the Prefix Length field received in the 720 Binding Update that created or last modified this Binding 721 Cache entry. This field is only valid if the "home 722 registration" flag is set on this Binding Cache entry. 724 - The maximum value of the Sequence Number field received 725 in previous Binding Updates for this mobile node home 726 address. The Sequence Number field is 16 bits long, and 727 all comparisons between Sequence Number values MUST be 728 performed modulo 2**16. 730 - Recent usage information for this Binding Cache entry, as 731 needed to implement the cache replacement policy in use in 732 the Binding Cache and to assist in determining whether a 733 Binding Request should be sent when the lifetime on this 734 entry nears expiration. 736 - The time at which a Binding Request was last sent for this 737 entry, as needed to implement the rate limiting restriction 738 for sending Binding Requests. 740 An entry in a node's Binding Cache for which the node is 741 serving as a home agent is marked as a "home registration" 742 entry and SHOULD NOT be deleted by the home agent until the 743 expiration of its binding lifetime. Other Binding Cache 744 entries MAY be replaced at any time by any reasonable local 745 cache replacement policy but SHOULD NOT be unnecessarily 746 deleted. Any node's Binding Cache may contain at most one 747 entry for each mobile node home address. The contents of a 748 node's Binding Cache MUST NOT be changed in response to a Home 749 Address option in a received packet. 751 Binding Update List 753 A list, maintained by each mobile node, recording information 754 for each Binding Update sent by this mobile node, for which 755 the Lifetime sent in that Binding Update has not yet expired. 756 The Binding Update List includes all bindings sent by the 757 mobile node: those to correspondent nodes, to the mobile 758 node's home agent, and to a previous default router of the 759 mobile node. The Binding Update List MAY be implemented in any 760 manner consistent with the external behavior described in this 761 document. Each Binding Update List entry conceptually contains 762 the following fields: 764 - The IP address of the node to which a Binding Update was 765 sent. This node might still have a Binding Cache entry 766 created or updated from this Binding Update, if the Binding 767 Update was successfully received by that node (e.g., not 768 lost by the network) and if that node has not deleted the 769 entry before its expiration (e.g., to reclaim space in its 770 Binding Cache for other entries). 772 - The home address for which that Binding Update was sent. 773 This will be one of the mobile node's home addresses for 774 most Binding Updates (Sections 10.5 and 10.7), but will 775 be the mobile node's previous care-of address for Binding 776 Updates sent to the mobile node's previous default router 777 (Section 10.8). 779 - The care-of address sent in that Binding Update. This 780 value is necessary for the mobile node to determine if it 781 has sent a Binding Update giving its new care-of address to 782 this destination after changing its care-of address. 784 - The remaining lifetime of that binding. This lifetime is 785 initialized from the Lifetime value sent in the Binding 786 Update and is decremented until it reaches zero, at which 787 time this entry MUST be deleted from the Binding Update 788 List. 790 - The maximum value of the Sequence Number field sent in 791 previous Binding Updates to this destination. The Sequence 792 Number field is 16 bits long, and all comparisons between 793 Sequence Number values MUST be performed modulo 2**16. 795 - The time at which a Binding Update was last sent to this 796 destination, as needed to implement the rate limiting 797 restriction for sending Binding Updates. 799 - The state of any retransmissions needed for this Binding 800 Update, if the Acknowledge (A) bit was set in this Binding 801 Update. This state includes the time remaining until the 802 next retransmission attempt for the Binding Update, and the 803 current state of the exponential back-off mechanism for 804 retransmissions. 806 - A flag that, when set, indicates that future Binding 807 Updates should not be sent to this destination. The 808 mobile node sets this flag in the Binding Update List 809 entry when it receives an ICMP Parameter Problem, Code 2, 810 error message in response to a Binding Update sent to that 811 destination, as described in Section 10.13. 813 Home Agents List 815 A list, maintained by each home agent, recording information 816 about each other home agent on a link on which this node 817 is serving as a home agent; each home agent maintains a 818 separate Home Agents List for each such link on which it is 819 serving. This list is used in the dynamic home agent address 820 discovery mechanism. The information for the list is learned 821 through receipt of the periodic unsolicited multicast Router 822 Advertisements from each other home agent on the link, in which 823 the Home Agent (H) bit is set, in a manner similar to the 824 Default Router List conceptual data structure maintained by 825 each host for Neighbor Discovery [13]. The Home Agents List 826 MAY be implemented in any manner consistent with the external 827 behavior described in this document. Each Home Agents List 828 entry conceptually contains the following fields: 830 - The link-local IP address of another router on the home 831 link that this node currently believes is operating as 832 a home agent for this link. A new entry is created or 833 an existing entry is updated in the Home Agents List in 834 response to receipt of a valid Router Advertisement in 835 which the Home Agent (H) bit is set. The link-local 836 address of the home agent is learned through the Source 837 Address of the Router Advertisements received from it [13]. 839 - One or more global IP addresses for this home agent, 840 learned through Prefix Information options with the 841 Router Address (R) bit is set, received in Router 842 Advertisements from this link-local address. Global 843 addresses for the router in a Home Agents List entry MUST 844 be deleted once the prefix associated with that address is 845 no longer valid [13]. 847 - The remaining lifetime of this Home Agents List entry. If 848 a Home Agent Information Option is present in a Router 849 Advertisement received from a home agent, the lifetime of 850 the Home Agents List entry representing this home agent 851 is initialized from the Home Agent Lifetime field in the 852 option; otherwise, the lifetime is initialized from the 853 Router Lifetime field in the received Router Advertisement. 854 The Home Agents List entry lifetime is decremented until it 855 reaches zero, at which time this entry MUST be deleted from 856 the Home Agents List. 858 - The preference for this home agent, for use in ordering the 859 Home Agents List returned in a Binding Acknowledgement; 860 higher values indicate a more preferable home agent. The 861 preference value is taken from the Home Agent Preference 862 field (a signed, twos-complement integer) in the received 863 Router Advertisement, if the Router Advertisement contains 864 a Home Agent Information Option, and is otherwise set to 865 the default value of 0. 867 4.4. Binding Management 869 When a mobile node configures a new care-of address and decides to 870 use this new address as its primary care-of address, the mobile 871 node registers this new binding with its home agent by sending 872 the home agent a Binding Update. The mobile node indicates 873 that an acknowledgement is needed for this Binding Update and 874 continues to periodically retransmit it until acknowledged. The 875 home agent acknowledges the Binding Update by returning a Binding 876 Acknowledgement to the mobile node. 878 When a mobile node receives a packet tunneled to it from its 879 home agent, the mobile node assumes that the original sending 880 correspondent node has no Binding Cache entry for the mobile node, 881 since the correspondent node would otherwise have sent the packet 882 directly to the mobile node using a Routing header. The mobile node 883 thus returns a Binding Update to the correspondent node, allowing 884 it to cache the mobile node's binding for routing future packets to 885 it. Although the mobile node may request an acknowledgement for 886 this Binding Update, it need not, since subsequent packets from the 887 correspondent node will continue to be intercepted and tunneled by 888 the mobile node's home agent, effectively causing any needed Binding 889 Update retransmission. 891 A correspondent node with a Binding Cache entry for a mobile node 892 may refresh this binding, for example if the binding's lifetime 893 is near expiration, by sending a Binding Request to the mobile 894 node. Normally, a correspondent node will only refresh a Binding 895 Cache entry in this way if it is actively communicating with the 896 mobile node and has indications, such as an open TCP connection to 897 the mobile node, that it will continue this communication in the 898 future. When a mobile node receives a Binding Request, it replies by 899 returning a Binding Update to the node sending the Binding Request. 901 A mobile node may use more than one care-of address at the same 902 time, although only one care-of address may be registered for it at 903 its home agent as its primary care-of address. The mobile node's 904 home agent will tunnel all intercepted packets for the mobile node 905 to its (single) registered primary care-of address, but the mobile 906 node will accept packets that it receives at any of its current 907 care-of addresses. Use of more than one care-of address by a mobile 908 node may be useful, for example, to improve smooth handoff when the 909 mobile node moves from one wireless link to another. If each of 910 these wireless links is connected to the Internet through a separate 911 base station, such that the wireless transmission range from the 912 two base stations overlap, the mobile node may be able to remain 913 connected to both links while in the area of overlap. In this case, 914 the mobile node could acquire a new care-of address on the new link 915 before moving out of transmission range and disconnecting from the 916 old link. The mobile node may thus still accept packets at its 917 old care-of address while it works to update its home agent and 918 correspondent nodes, notifying them of its new care-of address on the 919 new link. 921 Since correspondent nodes cache bindings, it is expected that 922 correspondent nodes usually will route packets directly to the mobile 923 node's care-of address, so that the home agent is rarely involved 924 with packet transmission to the mobile node. This is essential for 925 scalability and reliability, and for minimizing overall network load. 926 By caching the care-of address of a mobile node, optimal routing of 927 packets can be achieved from the correspondent node to the mobile 928 node. Routing packets directly to the mobile node's care-of address 929 also eliminates congestion at the mobile node's home agent and home 930 link. In addition, the impact of any possible failure of the home 931 agent, the home link, or intervening networks leading to or from the 932 home link is reduced, since these nodes and links are not involved in 933 the delivery of most packets to the mobile node. 935 5. New IPv6 Destination Options 937 5.1. Binding Update Option Format 939 The Binding Update destination option is used by a mobile node 940 to notify other nodes of a new care-of address for itself. As a 941 destination option, it MAY be included in any existing packet being 942 sent to this same destination or MAY be sent in a packet by itself; 943 a packet containing a Binding Update is sent in the same way as any 944 packet sent by a mobile node (Section 10.1). 946 The Binding Update option is encoded in type-length-value (TLV) 947 format as follows: 949 0 1 2 3 950 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 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Option Type | Option Length | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 |A|H|C| Reserved| Prefix Length | Sequence Number | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Lifetime | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | | 959 + + 960 | | 961 + Care-of Address + 962 | (only present if C bit set) | 963 + + 964 | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Sub-Options... 967 +-+-+-+-+-+-+-+-+-+-+-+- 969 Option Type 971 195 ??? 973 Option Length 975 8-bit unsigned integer. Length of the option, in octets, 976 excluding the Option Type and Option Length fields. This field 977 MUST be set to 8 (or to 24 if the Care-of Address Present (C) 978 bit is set), plus the total length of all sub-options present, 979 including their Sub-Option Type and Sub-Option Len fields. 981 Acknowledge (A) 983 The Acknowledge (A) bit is set by the sending mobile node to 984 request a Binding Acknowledgement (Section 5.2) be returned 985 upon receipt of the Binding Update. 987 Home Registration (H) 989 The Home Registration (H) bit is set by the sending mobile node 990 to request the receiving node to act as this node's home agent. 991 The destination of the packet carrying this option MUST be that 992 of a router sharing the same subnet prefix as the home address 993 of the mobile node in the binding (given by the Home Address 994 field in the Home Address option in the packet). 996 Care-of Address Present (C) 998 The Care-of Address Present (C) bit indicates the presence of 999 the Care-of Address field in the Binding Update. The care-of 1000 address for this binding is either the address in the Care-of 1001 Address field in the Binding Update, if this bit is set, or the 1002 Source Address in the packet's IPv6 header, if this bit is not 1003 set. 1005 Reserved 1007 Sent as 0; ignored on reception. 1009 Prefix Length 1011 The Prefix Length field is valid only for a "home registration" 1012 Binding Update. This field MUST be zero if the Home 1013 Registration (H) bit is not set in the Binding Update. The 1014 Prefix Length field is set by the sending mobile node to the 1015 (nonzero) length of its subnet prefix in its home address 1016 (given in the Home Address option in the packet) to request 1017 its home agent to use the interface identifier in the mobile 1018 node's home address (the remaining low-order bits after the 1019 indicated subnet prefix) to form all other home addresses for 1020 the mobile node on the home link. The home agent becomes the 1021 home agent not only for the individual home address given in 1022 this binding, but also for all other home addresses for this 1023 mobile node formed from this interface identifier. That is, 1024 for each on-link prefix on the home link, the home agent uses 1025 the interface identifier to form other valid addresses for the 1026 mobile node on the home link, and acts as a home agent also 1027 for those addresses. In addition, the home agent forms the 1028 link-local address and site-local address corresponding to 1029 this interface identifier, and defends each for purposes of 1030 Duplicate Address Detection. Details of this operation are 1031 described in Section 9.3. 1033 Sequence Number 1035 Used by the receiving node to sequence Binding Updates and by 1036 the sending node to match a returned Binding Acknowledgement 1037 with this Binding Update. Each Binding Update sent by a mobile 1038 node MUST use a Sequence Number greater than the Sequence 1039 Number value sent in the previous Binding Update (if any) to 1040 the same destination address (modulo 2**16). 1042 Lifetime 1044 32-bit unsigned integer. The number of seconds remaining 1045 before the binding must be considered expired. A value of all 1046 one bits (0xffffffff) indicates infinity. A value of zero 1047 indicates that the Binding Cache entry for the mobile node 1048 should be deleted. 1050 Care-of Address 1052 This field in the Binding Update is optional and is only 1053 present when the Care-of Address Present (C) bit is set. If 1054 present, it gives the care-of address of the mobile node for 1055 this binding. For most Binding Updates sent, it is expected 1056 that this field will not be present, and instead that the 1057 care-of address for the binding will be given by the Source 1058 Address field in the packet's IPv6 header. 1060 Sub-Options 1062 Additional information, associated with this Binding Update 1063 option, that need not be present in all Binding Updates sent. 1064 This use of sub-options also allows for future extensions to 1065 the format of the Binding Update option to be defined. The 1066 encoding and format of defined sub-options are described in 1067 Section 5.5. The following sub-options are valid in a Binding 1068 Update option: 1070 - Unique Identifier Sub-Option 1072 Any packet that includes a Binding Update option MUST also include 1073 a Home Address option. The home address of the mobile node in the 1074 binding given in the Binding Update option is indicated by the Home 1075 Address field in the Home Address option in the packet. 1077 Any packet that includes a Binding Update option MUST also include 1078 either an AH [8] or ESP [9] header providing sender authentication, 1079 data integrity protection, and replay protection. 1081 If the care-of address in the binding (either the Care-of Address 1082 field in the Binding Update option or the Source Address field in 1083 the packet's IPv6 header) is equal to the home address of the mobile 1084 node, the Binding Update option indicates that any existing binding 1085 for the mobile node MUST be deleted. Likewise, if the Lifetime 1086 field in the Binding Update option is equal to 0, the Binding Update 1087 option indicates that any existing binding for the mobile node MUST 1088 be deleted. In each of these cases, a Binding Cache entry for the 1089 mobile node MUST NOT be created in response to receiving the Binding 1090 Update. 1092 The last Sequence Number value sent to a destination in a Binding 1093 Update is stored by the mobile node in its Binding Update List entry 1094 for that destination; the last Sequence Number value received from 1095 a mobile node in a Binding Update is stored by a correspondent node 1096 in its Binding Cache entry for that mobile node. Thus, the mobile 1097 node's and the correspondent node's knowledge of the last sequence 1098 number expire at the same time. If the sending mobile node has no 1099 Binding Update List entry, the Sequence Number may start at any 1100 value; if the receiving correspondent node has no Binding Cache entry 1101 for the sending mobile node, it MUST accept any Sequence Number value 1102 in a received Binding Update from this mobile node. 1104 The three highest-order bits of the Option Type are encoded to 1105 indicate specific processing of the option [5]. For the Binding 1106 Update option, these three bits are set to 110, indicating that any 1107 IPv6 node processing this option that does not recognize the Option 1108 Type must discard the packet and, only if the packet's Destination 1109 Address was not a multicast address, return an ICMP Parameter 1110 Problem, Code 2, message to the packet's Source Address; and that the 1111 data within the option cannot change en-route to the packet's final 1112 destination. 1114 5.2. Binding Acknowledgement Option Format 1116 The Binding Acknowledgement destination option is used to acknowledge 1117 receipt of a Binding Update option (Section 5.1). When a node 1118 receives a packet containing a Binding Update option, with this 1119 node being the destination of the packet (only the destination 1120 node processes the option since it is a destination option), 1121 this node MUST return a Binding Acknowledgement to the source 1122 of the packet, if the Acknowledge (A) bit is set in the Binding 1123 Update. As a destination option, this node MAY included the Binding 1124 Acknowledgement in any existing packet being sent to the mobile node 1125 or MAY send it in a packet by itself. A packet containing a Binding 1126 Acknowledgement is sent in the same way as any packet to a mobile 1127 node, using a Routing header to route the packet to the mobile node 1128 by way of the care-of address in the binding (Section 8.9). 1130 The Binding Acknowledgement option is encoded in type-length-value 1131 (TLV) format as follows: 1133 0 1 2 3 1134 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 1135 +-+-+-+-+-+-+-+-+ 1136 | Option Type | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Option Length | Status | Sequence Number | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Lifetime | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Refresh | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Sub-Options... 1145 +-+-+-+-+-+-+-+-+-+-+-+- 1147 Option Type 1149 2 ??? 1151 Option Length 1153 8-bit unsigned integer. Length of the option, in octets, 1154 excluding the Option Type and Option Length fields. This field 1155 MUST be set to 11 plus the total length of all sub-options 1156 present, including their Sub-Option Type and Sub-Option Len 1157 fields. 1159 Status 1161 8-bit unsigned integer indicating the disposition of the 1162 Binding Update. Values of the Status field less than 128 1163 indicate that the Binding Update was accepted by the receiving 1164 node. The following such Status values are currently defined: 1166 0 Binding Update accepted 1168 Values of the Status field greater than or equal to 128 1169 indicate that the Binding Update was rejected by the receiving 1170 node. The following such Status values are currently defined: 1172 128 Reason unspecified 1173 129 Poorly formed Binding Update 1174 130 Administratively prohibited 1175 131 Insufficient resources 1176 132 Home registration not supported 1177 133 Not home subnet 1178 134 Sequence Number field value too small 1179 135 Dynamic home agent address discovery response 1180 136 Incorrect interface identifier length 1181 137 Not home agent for this mobile node 1183 Up-to-date values of the Status field are to be specified in 1184 the most recent "Assigned Numbers" [21]. 1186 Sequence Number 1188 The Sequence Number in the Binding Acknowledgement is copied 1189 from the Sequence Number field in the Binding Update being 1190 acknowledged, for use by the mobile node in matching this 1191 Acknowledgement with an outstanding Binding Update. 1193 Lifetime 1195 The granted lifetime for which this node will attempt to retain 1196 the entry for this mobile node in its Binding Cache. If the 1197 node sending the Binding Acknowledgement is serving as the 1198 mobile node's home agent, the Lifetime period also indicates 1199 the period for which this node will continue this service; if 1200 the mobile node requires home agent service from this node 1201 beyond this period, the mobile node MUST send a new Binding 1202 Update to it before the expiration of this period (even if 1203 it is not changing its primary care-of address), in order to 1204 extend the lifetime. The value of this field is undefined 1205 if the Status field indicates that the Binding Update was 1206 rejected. 1208 Refresh 1210 The recommended interval at which the mobile node SHOULD send 1211 a new Binding Update to this node in order to "refresh" the 1212 mobile node's binding in this node's Binding Cache. This 1213 refreshing of the binding is useful in case the node fails and 1214 loses its cache state. The Refresh period is determined by 1215 the node sending the Binding Acknowledgement (the node caching 1216 the binding). If this node is serving as the mobile node's 1217 home agent, the Refresh value may be set, for example, based on 1218 whether the node stores its Binding Cache in volatile storage 1219 or in nonvolatile storage. If the node sending the Binding 1220 Acknowledgement is not serving as the mobile node's home agent, 1221 the Refresh period SHOULD be set equal to the Lifetime period 1222 in the Binding Acknowledgement; even if this node loses this 1223 cache entry due to a failure of the node, packets from it can 1224 still reach the mobile node through the mobile node's home 1225 agent, causing a new Binding Update to this node to allow it 1226 to recreate this cache entry. The value of this field is 1227 undefined if the Status field indicates that the Binding Update 1228 was rejected. 1230 Sub-Options 1232 Additional information, associated with this Binding 1233 Acknowledgement option, that need not be present in all Binding 1234 Acknowledgements sent. This use of sub-options also allows for 1235 future extensions to the format of the Binding Acknowledgement 1236 option to be defined. The encoding and format of defined 1237 sub-options are described in Section 5.5. The following 1238 sub-options are valid in a Binding Acknowledgement option: 1240 - Home Agents List Sub-Option 1242 Any packet that includes a Binding Acknowledgement option MUST 1243 also include either an AH [8] or ESP [9] header providing sender 1244 authentication, data integrity protection, and replay protection. 1246 If the node returning the Binding Acknowledgement accepted the 1247 Binding Update for which the Acknowledgement is being returned (the 1248 value of the Status field in the Acknowledgement is less than 128), 1249 this node will have an entry for the mobile node in its Binding Cache 1250 and MUST use this entry (which includes the care-of address received 1251 in the Binding Update) in sending the packet containing the Binding 1252 Acknowledgement to the mobile node. The details of sending this 1253 packet to the mobile node are the same as for sending any packet to a 1254 mobile node using a binding, and are described in Section 8.9. The 1255 packet is sent using a Routing header, routing the packet to the 1256 mobile node by way of its care-of address recorded in the Binding 1257 Cache entry. 1259 If the node returning the Binding Acknowledgement instead 1260 rejected the Binding Update (the value of the Status field in the 1261 Acknowledgement is greater than or equal to 128), this node MUST 1262 similarly use a Routing header in sending the packet containing the 1263 Binding Acknowledgement, as described in Section 8.9, but MUST NOT 1264 use its Binding Cache in forming the IP header or Routing header 1265 in this packet. Rather, the care-of address used by this node in 1266 sending the packet containing the Binding Acknowledgement MUST be 1267 copied from the care-of address received in the rejected Binding 1268 Update; this node MUST NOT modify its Binding Cache in response 1269 to receiving this rejected Binding Update and MUST ignore its 1270 Binding Cache in sending the packet in which it returns this Binding 1271 Acknowledgement. The packet is sent using a Routing header, routing 1272 the packet to the home address of the rejected Binding Update by 1273 way of the care-of address indicated in the packet containing the 1274 Binding Update. When sending a Binding Acknowledgement to reject a 1275 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 1276 packet containing no payload (with the Next Header field in the last 1277 extension header in the packet set to indicate "No Next Header" [5]). 1279 The three highest-order bits of the Option Type are encoded to 1280 indicate specific processing of the option [5]. For the Binding 1281 Acknowledgement option, these three bits are set to 000, indicating 1282 that any IPv6 node processing this option that does not recognize the 1283 Option Type must skip over this option and continue processing the 1284 header, and that the data within the option cannot change en-route to 1285 the packet's final destination. 1287 5.3. Binding Request Option Format 1289 The Binding Request destination option is used to request a mobile 1290 node's binding from the mobile node. As a destination option, it 1291 MAY be included in any existing packet being sent to the mobile 1292 node or MAY be sent in a packet by itself; a packet containing a 1293 Binding Request option is sent in the same way as any packet to a 1294 mobile node (Section 8.9). When a mobile node receives a packet 1295 containing a Binding Request option, it SHOULD return a Binding 1296 Update (Section 5.1) to the source of the Binding Request. 1298 The Binding Request option is encoded in type-length-value (TLV) 1299 format as follows: 1301 0 1 1302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1304 | Option Type | Option Length | Sub-Options... 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1307 Option Type 1309 3 ??? 1311 Option Length 1313 8-bit unsigned integer. Length of the option, in octets, 1314 excluding the Option Type and Option Length fields. This field 1315 MUST be set to 0 plus the total length of all sub-options 1316 present, including their Sub-Option Type and Sub-Option Len 1317 fields. 1319 Sub-Options 1321 Additional information, associated with this Binding Request 1322 option, that need not be present in all Binding Requests sent. 1323 This use of sub-options also allows for future extensions to 1324 the format of the Binding Request option to be defined. The 1325 encoding and format of defined sub-options are described in 1326 Section 5.5. The following sub-options are valid in a Binding 1327 Request option: 1329 - Unique Identifier Sub-Option 1331 The three highest-order bits of the Option Type are encoded to 1332 indicate specific processing of the option [5]. For the Binding 1333 Request option, these three bits are set to 000, indicating that any 1334 IPv6 node processing this option that does not recognize the Option 1335 Type must skip over this option and continue processing the header, 1336 and that the data within the option cannot change en-route to the 1337 packet's final destination. 1339 5.4. Home Address Option Format 1341 The Home Address destination option is used in a packet sent by a 1342 mobile node while away from home, to inform the recipient of that 1343 packet of the mobile node's home address. For packets sent by a 1344 mobile node while away from home, the mobile node generally uses 1345 one of its care-of addresses as the Source Address in the packet's 1346 IPv6 header. By including a Home Address option in the packet, the 1347 correspondent node receiving the packet is able to substitute the 1348 mobile node's home address for this care-of address when processing 1349 the packet, thus making the use of the care-of address transparent to 1350 the correspondent node. 1352 The Home Address option is encoded in type-length-value (TLV) format 1353 as follows: 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Option Type | Option Length | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | | 1361 + + 1362 | | 1363 + Home Address + 1364 | | 1365 + + 1366 | | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Sub-Options... 1369 +-+-+-+-+-+-+-+-+-+-+-+- 1371 Option Type 1373 196 ??? 1375 Option Length 1377 8-bit unsigned integer. Length of the option, in octets, 1378 excluding the Option Type and Option Length fields. This field 1379 MUST be set to 16 plus the total length of all sub-options 1380 present, including their Sub-Option Type and Sub-Option Len 1381 fields. 1383 Home Address 1385 The home address of the mobile node sending the packet. 1387 Sub-Options 1389 Additional information, associated with this Home Address 1390 option, that need not be present in all Home Address options 1391 sent. This use of sub-options also allows for future 1392 extensions to the format of the Home Address option to be 1393 defined. The encoding and format of defined sub-options are 1394 described in Section 5.5. Currently, no valid sub-options are 1395 defined for use in a Home Address option. 1397 The inclusion of a Home Address option in a packet affects the 1398 receiving node's processing of only this single packet; no state is 1399 created or modified in the receiving node as a result of receiving a 1400 Home Address option in a packet. In particular, the presence of a 1401 Home Address option in a received packet MUST NOT alter the contents 1402 of the receiver's Binding Cache and MUST NOT cause any changes in the 1403 routing of subsequent packets sent by this receiving node. 1405 No authentication of the Home Address option is required, except that 1406 if the IPv6 header of a packet is covered by authentication, then 1407 that authentication MUST also cover the Home Address option; this 1408 coverage is achieved automatically by the definition of the Option 1409 Type code for the Home Address option, since it indicates that the 1410 data within the option cannot change en-route to the packet's final 1411 destination, and thus the option is included in the authentication 1412 computation. If the packet carries no IP authentication, then the 1413 contents of the Home Address option, as well as the Source Address 1414 field or any other field in the IPv6 header, may have been forged or 1415 altered during transit. 1417 Upon receipt of a packet containing a Home Address option, the 1418 receiving node replaces the Source Address in the IPv6 header with 1419 the Home Address in the Home Address option. By requiring that any 1420 authentication of the IPv6 header also cover the Home Address option, 1421 the security of the Source Address field in the IPv6 header is not 1422 compromised by the presence of a Home Address option. Security 1423 issues related to the Home Address option are discussed further in 1424 Section 13. 1426 The three highest-order bits of the Option Type are encoded to 1427 indicate specific processing of the option [5]. For the Home Address 1428 option, these three bits are set to 110, indicating that any IPv6 1429 node processing this option that does not recognize the Option Type 1430 must discard the packet and, only if the packet's Destination Address 1431 was not a multicast address, return an ICMP Parameter Problem, 1432 Code 2, message to the packet's Source Address; and that the data 1433 within the option cannot change en-route to the packet's final 1434 destination. 1436 5.5. Mobile IPv6 Destination Option Sub-Options 1438 In order to allow optional fields that may not be needed in most uses 1439 of any given Mobile IPv6 destination option, and to allow future 1440 extensions to the format of these destination options to be defined, 1441 any of the Mobile IPv6 destination options defined in this document 1442 MAY include one or more sub-options. 1444 Such sub-options are included in the data portion of the destination 1445 option itself, after the fixed portion of the option data specified 1446 for that particular destination option (Sections 5.1 through 5.4). 1447 The presence of such sub-options will be indicated by the Option 1448 Length field. When the Option Length is greater than the standard 1449 length defined for that destination option, the remaining octets are 1450 interpreted as sub-options. 1452 These sub-options are encoded within the remaining space of the 1453 option data for that option, using a type-length-value (TLV) format 1454 as follows: 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 |Sub-Option Type| Sub-Option Len| Sub-Option Data... 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 Sub-Option Type 1464 8-bit identifier of the type of sub-option. In processing a 1465 Mobile IPv6 destination option containing a sub-option for 1466 which the Sub-Option Type value is not recognized by the 1467 receiver, the receiver SHOULD quietly ignore and skip over the 1468 sub-option, correctly handling any remaining sub-options in the 1469 option. 1471 Sub-Option Length 1473 8-bit unsigned integer. Length of the Sub-Option Data field 1474 of this sub-option, in octets. The Sub-Option Len does not 1475 include the length of the Sub-Option Type and Sub-Option Len 1476 fields. 1478 Sub-Option Data 1480 Variable-length field. Sub-Option-Type-specific data. 1482 Each section above defining the Mobile IPv6 destination options 1483 specifies which of the defined sub-options is valid for that 1484 destination option. 1486 Currently, the following two sub-option types are defined for use in 1487 Mobile IPv6 destination options: 1489 Unique Identifier Sub-Option 1491 This sub-option is valid only in Binding Request and Binding 1492 Update destination options. The Sub-Option Data contains a 1493 single 16-bit value that serves to uniquely identify a Binding 1494 Request among those sent by this Source Address, and to allow 1495 the Binding Update to identify the specific Binding Request to 1496 which it responds. This matching of Binding Updates to Binding 1497 Requests is required in the procedure for renumbering the home 1498 subnet while a mobile node is away from home (Section 9.7). 1499 The Sub-Option Type and Sub-Option Len fields for this 1500 sub-option MUST be set as follows: 1502 - Sub-Option Type: 1 1504 - Sub-Option Len: 2 1506 Home Agents List Sub-Option 1508 This sub-option is valid only in a Binding Acknowledgement 1509 destination option. The Sub-Option Data contains a list of 1510 home agents on the home link for the mobile node to which 1511 this Binding Acknowledgement is sent. This sub-option MUST 1512 NOT be present unless the Binding Acknowledgement is sent in 1513 response to an anycast Binding Update sent by a mobile node 1514 attempting dynamic home agent address discovery. In this case, 1515 the Status field in the Binding Acknowledgement MUST be set 1516 to 135 (dynamic home agent address discovery response). The 1517 specific construction of the Sub-Option Data field for this 1518 sub-option is defined in Section 9.2. The Sub-Option Type 1519 and Sub-Option Len fields for this sub-option MUST be set as 1520 follows: 1522 - Sub-Option Type: 2 1524 - Sub-Option Len: 16 * N, where N is the number of home 1525 agent addresses included in the Sub-Option Data. 1527 6. Modifications to IPv6 Neighbor Discovery 1529 6.1. Modified Router Advertisement Message Format 1531 Mobile IPv6 modifies the format of the Router Advertisement 1532 message [13] by the addition of a single flag bit for use in the 1533 dynamic home agent address discovery mechanism (Sections 9.2 1534 and 10.6). The format of the Router Advertisement message is 1535 as follows: 1537 0 1 2 3 1538 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 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | Type | Code | Checksum | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | Reachable Time | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Retrans Timer | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Options ... 1549 +-+-+-+-+-+-+-+-+-+-+-+- 1551 This format represents the following changes over that originally 1552 specified for Neighbor Discovery [13]: 1554 Home Agent (H) 1556 The Home Agent (H) bit is set in a Router Advertisement to 1557 indicate that the router sending this Router Advertisement is 1558 also functioning as a Mobile IP home agent. 1560 Reserved 1562 Reduced from a 6-bit field to a 5-bit field to account for the 1563 addition of the Home Agent (H) bit. 1565 6.2. Modified Prefix Information Option Format 1567 Mobile IPv6 requires knowledge of a router's global address for two 1568 reasons: 1570 - To allow a home agent (a router) to learn the address of all 1571 other home agents on the link for which it is providing home 1572 agent service, for use in building its Home Agents List as 1573 part of the dynamic home agent address discovery mechanism 1574 (Sections 9.2 and 10.6). 1576 - To allow a mobile node to send a Binding Update to its previous 1577 default router, after moving to a new subnet and acquiring a new 1578 care-of address (Section 10.8). 1580 However, Neighbor Discovery [13] only advertises a router's 1581 link-local address, by requiring this address to be used as the IP 1582 Source Address of each Router Advertisement. 1584 Mobile IPv6 extends Neighbor Discovery to allow a router to easily 1585 and efficiently advertise its global address, by the addition of a 1586 single flag bit in the format of a Prefix Information option for 1587 use in Router Advertisement messages. The format of the Prefix 1588 Information option is as follows: 1590 0 1 2 3 1591 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 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Type | Length | Prefix Length |L|A|R|Reserved1| 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Valid Lifetime | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Preferred Lifetime | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Reserved2 | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | | 1602 + + 1603 | | 1604 + Prefix + 1605 | | 1606 + + 1607 | | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 This format represents the following changes over that originally 1611 specified for Neighbor Discovery [13]: 1613 Router Address (R) 1615 1-bit router address flag. When set, indicates that the 1616 Prefix field, in addition to advertising the indicated prefix, 1617 contains a complete IP address assigned to the sending router. 1618 This router IP address has the same scope and conforms to the 1619 same lifetime values as the advertised prefix. This use of 1620 the Prefix field is compatible with its use in advertising 1621 the prefix itself, since prefix advertisement uses only the 1622 leading number Prefix bits specified by the Prefix Length 1623 field. Interpretation of this flag bit is thus independent 1624 of the processing required for the On-Link (L) and Autonomous 1625 Address-Configuration (A) flag bits. 1627 Reserved1 1629 Reduced from a 6-bit field to a 5-bit field to account for the 1630 addition of the Router Address (R) bit. 1632 In a solicited Router Advertisement, a router MUST include at least 1633 one Prefix Information option with the Router Address (R) bit set. 1634 Neighbor Discovery specifies that, if including all options in a 1635 Router Advertisement causes the size of the Advertisement to exceed 1636 the link MTU, multiple Advertisements can be sent, each containing 1637 a subset of the options [13]. In this case, at least one of these 1638 multiple Advertisements being sent instead of a single larger 1639 solicited Advertisement, MUST include a Prefix Information option 1640 with the Router Address (R) bit set. 1642 All routers SHOULD include at least on Prefix Information option with 1643 the Router Address (R) bit set, in each unsolicited multicast Router 1644 Advertisement that they send. If multiple Advertisements are being 1645 sent instead of a single larger unsolicited multicast Advertisement, 1646 at least one of these multiple Advertisements SHOULD include a Prefix 1647 Information option with the Router Address (R) bit set. 1649 6.3. New Advertisement Interval Option Format 1651 Mobile IPv6 defines a new Advertisement Interval option, used in 1652 Router Advertisement messages to advertise the interval at which the 1653 sending router sends unsolicited multicast Router Advertisements. 1654 The format of the Advertisement Interval option is as follows: 1656 0 1 2 3 1657 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 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | Type | Length | Reserved | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Advertisement Interval | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 Type 1666 6 ??? 1668 Length 1670 8-bit unsigned integer. The length of the option (including 1671 the type and length fields) in units of 8 octets. The value of 1672 this field MUST be 1. 1674 Reserved 1676 This field is unused. It MUST be initialized to zero by the 1677 sender and MUST be ignored by the receiver. 1679 Advertisement Interval 1681 32-bit unsigned integer. The maximum time, in milliseconds, 1682 between successive unsolicited router Router Advertisement 1683 messages sent by this router on this network interface. Using 1684 the conceptual router configuration variables defined by 1685 Neighbor Discovery [13], this field MUST be equal to the value 1686 MaxRtrAdvInterval, expressed in milliseconds. 1688 Routers MAY include this option in their Router Advertisements. A 1689 mobile node receiving a Router Advertisement containing this option 1690 SHOULD utilize the specified Advertisement Interval for that router 1691 in its movement detection algorithm, as described in Section 10.3. 1693 This option MUST be silently ignored for other Neighbor Discovery 1694 messages. 1696 6.4. New Home Agent Information Option Format 1698 Mobile IPv6 defines a new Home Agent Information option, used in 1699 Router Advertisement messages sent by a home agent to advertise 1700 information specific to this router's functionality as a home agent. 1701 The format of the Home Agent Information option is as follows: 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Type | Length | Reserved | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Home Agent Preference | Home Agent Lifetime | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 Type 1713 7 ??? 1715 Length 1717 8-bit unsigned integer. The length of the option (including 1718 the type and length fields) in units of 8 octets. The value of 1719 this field MUST be 1. 1721 Reserved 1723 This field is unused. It MUST be initialized to zero by the 1724 sender and MUST be ignored by the receiver. 1726 Home Agent Preference 1728 16-bit signed, twos-complement integer. The preference for 1729 the home agent sending this Router Advertisement, for use 1730 in ordering the addresses contained in the Home Agents List 1731 Sub-Option returned in a Binding Acknowledgement; higher values 1732 mean more preferable. If this option is not included in a 1733 Router Advertisement in which the Home Agent (H) bit is set, 1734 the preference value for this home agent SHOULD be considered 1735 to be 0. Values greater than 0 indicate a home agent more 1736 preferable than this default value, and values less than 0 1737 indicate a less preferable home agent. 1739 Home Agent Lifetime 1741 16-bit unsigned integer. The lifetime associated with the home 1742 agent in units of seconds. The maximum value corresponds to 1743 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 1744 Lifetime applies only to this router's usefulness as a home 1745 agent; it does not apply to information contained in other 1746 message fields or options. If this option is not included in 1747 a Router Advertisement in which the Home Agent (H) bit is set, 1748 the lifetime for this home agent SHOULD be considered to be the 1749 same as the Router Lifetime specified in the main body of the 1750 Router Advertisement message. 1752 Home agents MAY include this option in their Router Advertisements. 1753 This option MUST NOT be included in a Router Advertisement in which 1754 the Home Agent (H) bit (Section 6.1) is not set. 1756 This option MUST be silently ignored for other Neighbor Discovery 1757 messages. 1759 If both the Home Agent Preference and Home Agent Lifetime are set 1760 to their default values specified above, this option SHOULD NOT be 1761 included in the Router Advertisement messages sent by this home 1762 agent. 1764 6.5. Changes to Sending Router Advertisements 1766 The Neighbor Discovery protocol specification [13] limits routers to 1767 a minimum interval of 3 seconds between sending unsolicited multicast 1768 Router Advertisement messages from any given network interface 1769 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 1771 "Routers generate Router Advertisements frequently enough 1772 that hosts will learn of their presence within a few 1773 minutes, but not frequently enough to rely on an absence 1774 of advertisements to detect router failure; a separate 1775 Neighbor Unreachability Detection algorithm provides failure 1776 detection." 1778 This limitation, however, is not suitable to providing timely 1779 movement detection for mobile nodes. Mobile nodes detect their 1780 own movement by learning the presence of new routers as the mobile 1781 node moves into wireless transmission range of them (or physically 1782 connects to a new wired network), and by learning that previous 1783 routers are no longer reachable. Mobile nodes MUST be able to 1784 quickly detect when they move to a link served by a new router, so 1785 that they can acquire a new care-of address and send Binding Updates 1786 to register this care-of address with their home agent and to notify 1787 correspondent nodes as needed. 1789 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 1790 this limit such that routers MAY send unsolicited multicast Router 1791 Advertisements more frequently. In particular, on network interfaces 1792 where the router is expecting to provide service to visiting mobile 1793 nodes (e.g., wireless network interfaces), or on which it is serving 1794 as a home agent to one or more mobile nodes (who may return home and 1795 need to hear its Advertisements), the home agent SHOULD be configured 1796 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 1797 to allow sending of unsolicited multicast Router Advertisements more 1798 often. Recommended values for these limits are: 1800 - MinRtrAdvInterval 0.5 seconds 1802 - MaxRtrAdvInterval 1.5 seconds 1804 Use of these modified limits MUST be configurable, and specific 1805 knowledge of the type of network interface in use SHOULD be taken 1806 into account in configuring these limits for each network interface. 1808 When sending unsolicited multicast Router Advertisements more 1809 frequently than the standard limit on unsolicited multicast 1810 Advertisement frequency, the sending router need not include all 1811 options in each of these Advertisements, but it SHOULD include at 1812 least one Prefix Information option with the Router Address (R) bit 1813 set (Section 6.2) in each. 1815 6.6. Changes to Sending Router Solicitations 1817 In addition to the limit on routers sending unsolicited multicast 1818 Router Advertisement messages (Section 6.5), Neighbor Discovery 1819 defines limits on nodes sending Router Solicitation messages, such 1820 that a node SHOULD send no more than 3 Router Solicitations, and that 1821 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 1822 However, these limits prevent a mobile node from finding a new 1823 default router (and thus a new care-of address) quickly as it moves 1824 about. 1826 Mobile IPv6 relaxes this limit such that, while a mobile node is away 1827 from home, it MAY send Router Solicitations more frequently. The 1828 following limits for sending Router Solicitations are recommended for 1829 mobile nodes while away from home: 1831 - A mobile node that is not configured with any current care-of 1832 address (e.g., the mobile node has moved since its previous 1833 care-of address was configured), MAY send more than the defined 1834 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 1835 Solicitations. 1837 - The rate at which a mobile node sends Router Solicitations MUST 1838 be limited, although a mobile node MAY send Router Solicitations 1839 more frequently than the defined Neighbor Discovery limit of 1840 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 1841 be configurable, and specific knowledge of the type of network 1842 interface in use SHOULD be taken into account in configuring this 1843 limit for each network interface. A recommended minimum interval 1844 is 1 second. 1846 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 1847 a mobile node MUST reduce the rate at which it sends subsequent 1848 Router Solicitations. Subsequent Router Solicitations SHOULD 1849 be sent using a binary exponential backoff mechanism, doubling 1850 the interval between consecutive Router Solicitations, up to a 1851 maximum interval. The maximum interval MUST be configurable and 1852 SHOULD be chosen appropriately based on the characteristics of 1853 the type of network interface in use. 1855 - While still searching for a new default router and care-of 1856 address, a mobile node MUST NOT increase the rate at which it 1857 sends Router Solicitations unless it has received a positive 1858 indication (such as from lower network layers) that it has moved 1859 to a new link. After successfully acquiring a new care-of 1860 address, the mobile node SHOULD also increase the rate at which 1861 it will send Router Solicitations when it next begins searching 1862 for a new default router and care-of address. 1864 - A mobile node that is currently configured with a care-of 1865 address SHOULD NOT send Router Solicitations, until its movement 1866 detection algorithm (Section 10.3) determines that it has moved 1867 and that its current care-of address might no longer be valid. 1869 7. Requirements for IPv6 Nodes 1871 Mobile IPv6 places some special requirements on the functions 1872 provided by different types of IPv6 nodes. This section summarizes 1873 those requirements, identifying the functionality each requirement 1874 is intended to support. Further details on this functionality is 1875 provided in the following sections. 1877 7.1. Requirements for All IPv6 Hosts and Routers 1879 Since any IPv6 node may at any time be a correspondent node of a 1880 mobile node, either sending a packet to a mobile node or receiving a 1881 packet from a mobile node, the following requirements apply to ALL 1882 IPv6 nodes (whether host or router, whether mobile or stationary): 1884 - Every IPv6 node MUST be able to process a Home Address option 1885 received in any IPv6 packet. 1887 - Every IPv6 node SHOULD be able to process a Binding Update option 1888 received in a packet, and to return a Binding Acknowledgement 1889 option if the Acknowledge (A) bit is set in the received Binding 1890 Update. 1892 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 1893 bindings received in accepted Binding Updates. 1895 7.2. Requirements for All IPv6 Routers 1897 The following requirements apply to all IPv6 routers, even those not 1898 serving as a home agent for Mobile IPv6: 1900 - Every IPv6 router SHOULD be able to send an Advertisement 1901 Interval option in its Router Advertisements, to aid movement 1902 detection by mobile nodes. The use of this option in Router 1903 Advertisements MUST be configurable. 1905 - Every IPv6 router SHOULD be able to support sending unsolicited 1906 multicast Router Advertisements at the faster rate described in 1907 Section 6.5. The use of this faster rate MUST be configurable. 1909 7.3. Requirements for IPv6 Home Agents 1911 In order for a mobile node to operate correctly while away from home, 1912 at least one IPv6 router on the mobile node's home link must function 1913 as a home agent for the mobile node. The following additional 1914 requirements apply to all IPv6 routers capable of serving as a home 1915 agent: 1917 - Every home agent MUST be able to maintain an entry in its Binding 1918 Cache for each mobile node for which it is serving as the home 1919 agent. Each such Binding Cache entry records the mobile node's 1920 binding with its primary care-of address and is marked as a "home 1921 registration". 1923 - Every home agent MUST be able to intercept packets (using proxy 1924 Neighbor Discovery) addressed to a mobile node for which it is 1925 currently serving as the home agent, on that mobile node's home 1926 link, while the mobile node is away from home. 1928 - Every home agent MUST be able to encapsulate such intercepted 1929 packets in order to tunnel them to the primary care-of address 1930 for the mobile node indicated in its binding in the home agent's 1931 Binding Cache. 1933 - Every home agent MUST be able to return a Binding Acknowledgement 1934 option in response to a Binding Update option received with the 1935 Acknowledge (A) bit set. 1937 - Every home agent MUST be able to accept packets addressed to the 1938 Home-Agents anycast address for the subnet on which it is serving 1939 as a home agent, and MUST be able to participate in dynamic home 1940 agent address discovery (Section 9.2). 1942 7.4. Requirements for IPv6 Mobile Nodes 1944 Finally, the following requirements apply to all IPv6 nodes capable 1945 of functioning as mobile nodes: 1947 - Every IPv6 mobile node MUST be able to perform IPv6 1948 decapsulation [4]. 1950 - Every IPv6 mobile node MUST support sending Binding Update 1951 options, as specified in Sections 10.5, 10.7, and 10.8; and MUST 1952 be able to receive and process Binding Acknowledgement options, 1953 as specified in Section 10.11. 1955 - Every IPv6 mobile node MUST support use of the dynamic home agent 1956 address discovery mechanism, as described in Section 10.6. 1958 - Every IPv6 mobile node MUST maintain a Binding Update List in 1959 which it records the IP address of each other node to which it 1960 has sent a Binding Update, for which the Lifetime sent in that 1961 binding has not yet expired. 1963 - Every IPv6 mobile node MUST support receiving a Binding Request 1964 option, by responding with a Binding Update option. 1966 - Every IPv6 mobile node MUST support sending packets containing a 1967 Home Address option; this option MUST be included in all packets 1968 sent while away from home, if the packet would otherwise have 1969 been sent with the mobile node's home address as the IP Source 1970 Address. 1972 8. Correspondent Node Operation 1974 A correspondent node is any node communicating with a mobile node. 1975 The correspondent node, itself, may be stationary or mobile, and may 1976 possibly also be functioning as a home agent for Mobile IPv6. The 1977 procedures in this section thus apply to all IPv6 nodes. 1979 8.1. Receiving Packets from a Mobile Node 1981 Packets sent by a mobile node while away from home generally include 1982 a Home Address option. When any node receives a packet containing 1983 a Home Address option, it MUST process the option in a manner 1984 consistent with copying the Home Address field from the Home Address 1985 option into the IPv6 header, replacing the original value of the 1986 Source Address field there. However, any actual modifications to 1987 the Source Address field in the packet's IPv6 header MUST not be 1988 performed until after all processing of other options contained in 1989 this same Destination Options extension header is completed. 1991 Further processing of such a packet after option processing (e.g., 1992 at the transport layer) thus need not know that the original Source 1993 Address was a care-of address, or that the Home Address option was 1994 used in the packet. Since the sending mobile node uses its home 1995 address at the transport layer when sending such a packet, the use of 1996 the care-of address and Home Address option is transparent to both 1997 the mobile node and the correspondent node above the level of the 1998 Home Address option generation and processing. 2000 8.2. Receiving Binding Updates 2002 Upon receiving a Binding Update option in some packet, the receiving 2003 node MUST validate the Binding Update according to the following 2004 tests: 2006 - The packet contains a valid AH [8] or ESP [9] header that 2007 provides sender authentication, integrity protection, and replay 2008 protection. 2010 - The packet MUST contain a valid Home Address option. The home 2011 address for the binding is specified by the Home Address field of 2012 the Home Address option. 2014 - The Option Length field in the Binding Update option is greater 2015 than or equal to the length specified in Section 5.1. 2017 - The Sequence Number field in the Binding Update option is greater 2018 than the Sequence Number received in the previous Binding Update 2019 for this home address, if any. The Sequence Number comparison is 2020 performed modulo 2**16. 2022 Any Binding Update not satisfying all of these tests MUST be 2023 silently ignored, and the packet carrying the Binding Update MUST be 2024 discarded. 2026 If the Binding Update is valid according to the tests above, then the 2027 Binding Update is processed further as follows: 2029 - If the Destination Address in the packet's IPv6 header is the 2030 Home-Agents anycast address for an on-local prefix and this 2031 address is assigned to one of this node's network interfaces, 2032 then the mobile node sending this Binding Update is attempting 2033 dynamic home agent address discovery. Processing for this type 2034 of received Binding Update is described in Section 9.2. (If the 2035 Destination Address is not assigned to one of this node's network 2036 interfaces, then the packet would have been forwarded as a normal 2037 packet and the Binding Update, as a destination option, would not 2038 be processed in any way by this node.) 2040 - If the Lifetime specified in the Binding Update is nonzero and 2041 the specified Care-of Address is not equal to the home address 2042 for the binding (as given in the Home Address option in the 2043 packet), then this is a request to cache a binding for the 2044 mobile node. If the Home Registration (H) bit is set in the 2045 Binding Update, the Binding Update is processed according to the 2046 procedure specified in Section 9.3; otherwise, it is processed 2047 according to the procedure specified in Section 8.3. 2049 - If the Lifetime specified in the Binding Update is zero or the 2050 specified Care-of Address matches the home address for the 2051 binding, then this is a request to delete the mobile node's 2052 cached binding. If the Home Registration (H) bit is set in the 2053 Binding Update, the Binding Update is processed according to the 2054 procedure specified in Section 9.4; otherwise, it is processed 2055 according to the procedure specified in Section 8.4. 2057 8.3. Requests to Cache a Binding 2059 When a node receives a Binding Update, it MUST validate it and 2060 determine the type of Binding Update according to the steps described 2061 in Section 8.2. This section describes the processing of a valid 2062 Binding Update that requests a node to cache a mobile node's binding, 2063 for which the Home Registration (H) bit is not set in the Binding 2064 Update. 2066 In this case, the receiving node SHOULD create a new entry in its 2067 Binding Cache for this mobile node (or update its existing Binding 2068 Cache entry for this mobile node, if such an entry already exists). 2069 The home address of the mobile node is taken from the Home Address 2070 field in the packet's Home Address option. The new Binding Cache 2071 entry records the association between this home address and the 2072 care-of address for the binding, as specified in either the Care-of 2073 Address field of the Binding Update or in the Source Address field 2074 in the packet's IPv6 header. Any Binding Cache entry created or 2075 updated in response to processing this Binding Update MUST be deleted 2076 after the expiration of the Lifetime period specified in the Binding 2077 Update. 2079 8.4. Requests to Delete a Binding 2081 When a node receives a Binding Update, it MUST validate it and 2082 determine the type of Binding Update according to the steps described 2083 in Section 8.2. This section describes the processing of a valid 2084 Binding Update that requests a node to delete a mobile node's binding 2085 from its Binding Cache, for which the Home Registration (H) bit is 2086 not set in the Binding Update. 2088 In this case, the receiving node MUST delete any existing entry in 2089 its Binding Cache for this mobile node. The home address of the 2090 mobile node is taken from the Home Address field in the packet's Home 2091 Address option. 2093 8.5. Sending Binding Acknowledgements 2095 When any node receives a packet containing a Binding Update option 2096 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 2097 Acknowledgement option acknowledging receipt of the Binding Update. 2098 If the node accepts the Binding Update and creates or updates an 2099 entry in its Binding Cache for this binding, the Status field in 2100 the Binding Acknowledgement MUST be set to a value less than 128; 2101 if the node rejects the Binding Update and does not create or 2102 update an entry for this binding, the Status field in the Binding 2103 Acknowledgement MUST be set to a value greater than or equal to 128. 2104 Specific values for the Status field are described in Section 5.2 and 2105 in the most recent "Assigned Numbers" [21]. 2107 As described in Section 5.2, the packet in which the Binding 2108 Acknowledgement is returned MUST include either an AH [8] or ESP [9] 2109 header providing sender authentication, data integrity protection, 2110 and replay protection; and the packet MUST be sent using a Routing 2111 header in the same way as any other packet sent to a mobile node 2112 using a care-of address (even if the binding was rejected), as 2113 described in Section 8.9. The packet is routed first to the care-of 2114 address contained in the Binding Update being acknowledged, and 2115 then to the mobile node's home address. This use of the Routing 2116 header ensures that the Binding Acknowledgement will be routed to the 2117 current location of the node sending the Binding Update, whether the 2118 Binding Update was accepted or rejected. 2120 8.6. Sending Binding Requests 2122 Entries in a node's Binding Cache MUST be deleted when their lifetime 2123 expires. If such an entry is still in active use in sending packets 2124 to a mobile node, the next packet sent to the mobile node will be 2125 routed normally to the mobile node's home link, where it will be 2126 intercepted and tunneled to the mobile node. The mobile node will 2127 then return a Binding Update to the sender, allowing it to create 2128 a new Binding Cache entry for sending future packets to the mobile 2129 node. Communication with the mobile node continues uninterrupted, 2130 but the forwarding of this packet through the mobile node's home 2131 agent creates additional overhead and latency in delivering packets 2132 to the mobile node. 2134 If the sender knows that the Binding Cache entry is still in active 2135 use, it MAY send a Binding Request option to the mobile node in 2136 an attempt to avoid this overhead and latency due to deleting and 2137 recreating the Binding Cache entry. Since a Binding Request is a 2138 destination option, it may, for example, be included in any packet 2139 already being sent to the mobile node, such as a packet that is part 2140 of ongoing TCP communication with the mobile node. When the mobile 2141 node receives a packet from some sender containing a Binding Request 2142 option, it returns a Binding Update option to that sender, giving its 2143 current binding and a new lifetime. 2145 8.7. Cache Replacement Policy 2147 Any entry in a node's Binding Cache MUST be deleted after the 2148 expiration of the Lifetime specified in the Binding Update from 2149 which the entry was created or last updated. Conceptually, a node 2150 maintains a separate timer for each entry in its Binding Cache. When 2151 creating or updating a Binding Cache entry in response to a received 2152 and accepted Binding Update, the node sets the timer for this entry 2153 to the specified Lifetime period. When a Binding Cache entry's timer 2154 expires, the node deletes the entry. 2156 Each node's Binding Cache will, by necessity, have a finite size. 2157 A node MAY use any reasonable local policy for managing the space 2158 within its Binding Cache, except that any entry marked as a "home 2159 registration" (Section 9.3) MUST NOT be deleted from the cache until 2160 the expiration of its lifetime period. When attempting to add a 2161 new "home registration" entry in response to a Binding Update with 2162 the Home Registration (H) bit set, if insufficient space exists (or 2163 can be reclaimed) in the node's Binding Cache, the node MUST reject 2164 the Binding Update and SHOULD return a Binding Acknowledgement to 2165 the sending mobile node, in which the Status field is set to 131 2166 (insufficient resources). When otherwise attempting to add a new 2167 entry to its Binding Cache, a node MAY, if needed, choose to drop any 2168 entry already in its Binding Cache, other than a "home registration" 2169 entry, in order to make space for the new entry. For example, a 2170 "least-recently used" (LRU) strategy for cache entry replacement 2171 among entries not marked as a "home registration" is likely to work 2172 well. 2174 Any binding dropped from a node's Binding Cache due to lack of cache 2175 space will be rediscovered and a new cache entry created, if the 2176 binding is still in active use by the node for sending packets. If 2177 the node sends a packet to a destination for which it has dropped the 2178 entry from its Binding Cache, the packet will be routed normally, 2179 leading to the mobile node's home link. There, the packet will be 2180 intercepted by the mobile node's home agent and tunneled to the 2181 mobile node's current primary care-of address. As when a Binding 2182 Cache entry is initially created, this indirect routing to the mobile 2183 node through its home agent will result in the mobile node sending 2184 a Binding Update to this sending node when it receives the tunneled 2185 packet, allowing it to add an entry again for this destination mobile 2186 node to its Binding Cache. 2188 8.8. Receiving ICMP Error Messages 2190 When a correspondent node sends a packet to a mobile node, if the 2191 correspondent node has a Binding Cache entry for the destination 2192 address of the packet, then the correspondent node uses a Routing 2193 header to deliver the packet to the mobile node through the care-of 2194 address in the binding recorded in the Binding Cache entry. Any ICMP 2195 error message caused by the packet on its way to the mobile node will 2196 be returned normally to the correspondent node. 2198 On the other hand, if the correspondent node has no Binding Cache 2199 entry for the mobile node, the packet will be routed to the mobile 2200 node's home link. There, it will be intercepted by the mobile node's 2201 home agent, encapsulated, and tunneled to the mobile node's primary 2202 care-of address. Any ICMP error message caused by the packet on 2203 its way to the mobile node while in the tunnel, will be returned to 2204 the mobile node's home agent (the source of the tunnel). By the 2205 definition of IPv6 encapsulation [4], this encapsulating node MUST 2206 relay certain ICMP error messages back to the original sender of the 2207 packet, which in this case is the correspondent node. 2209 Likewise, if a packet for a mobile node arrives at the mobile node's 2210 previous default router (e.g., the mobile node moved after the packet 2211 was sent), the router will encapsulate and tunnel the packet to the 2212 mobile node's new care-of address (if it has a Binding Cache entry 2213 for the mobile node). As above, any ICMP error message caused by the 2214 packet while in this tunnel will be returned to the previous default 2215 router (the source of the tunnel), which MUST relay certain ICMP 2216 error messages back to the correspondent node [4]. 2218 Thus, in all cases, any meaningful ICMP error messages caused 2219 by packets from a correspondent node to a mobile node will be 2220 returned to the correspondent node. If the correspondent node 2221 receives persistent ICMP Destination Unreachable messages after 2222 sending packets to a mobile node based on an entry in its Binding 2223 Cache, the correspondent node SHOULD delete this Binding Cache 2224 entry. If the correspondent node subsequently transmits another 2225 packet to the mobile node, the packet will be routed to the mobile 2226 node's home link, intercepted by the mobile node's home agent, and 2227 tunneled to the mobile node's primary care-of address using IPv6 2228 encapsulation. The mobile node will then return a Binding Update to 2229 the correspondent node, allowing it to recreate a (correct) Binding 2230 Cache entry for the mobile node. 2232 8.9. Sending Packets to a Mobile Node 2234 Before sending any packet, the sending node SHOULD examine its 2235 Binding Cache for an entry for the destination address to which the 2236 packet is being sent. If the sending node has a Binding Cache entry 2237 for this address, the sending node SHOULD use a Routing header to 2238 route the packet to this mobile node (the destination node) by way 2239 of the care-of address in the binding recorded in that Binding Cache 2240 entry. For example, assuming use of a Type 0 Routing header [5], if 2241 no other use of a Routing header is involved in the routing of this 2242 packet, the mobile node sets the fields in the packet's IPv6 header 2243 and Routing header as follows: 2245 - The Destination Address in the packet's IPv6 header is set to 2246 the mobile node's care-of address copied from the Binding Cache 2247 entry. 2249 - The Routing header is initialized to contain a single route 2250 segment, with an Address of the mobile node's home address (the 2251 original destination address to which the packet was being sent). 2253 Following the definition of a Type 0 Routing header [5], this packet 2254 will be routed to the mobile node's care-of address, where it will 2255 be delivered to the mobile node (the mobile node has associated the 2256 care-of address with its network interface). Normal processing of 2257 the Routing header by the mobile node will then proceed as follows: 2259 - The mobile node swaps the Destination Address in the packet's 2260 IPv6 header and the Address specified in the Routing header. 2262 This results in the packet's IP Destination Address being set to 2263 the mobile node's home address. 2265 - The mobile node then resubmits the packet to its IPv6 module for 2266 further processing, "looping back" the packet inside the mobile 2267 node. Since the mobile node recognizes its own home address as 2268 one of its current IP addresses, the packet is processed further 2269 within the mobile node, in the same way then as if the mobile 2270 node was at home. 2272 If, instead, the sending node has no Binding Cache entry for the 2273 destination address to which the packet is being sent, the sending 2274 node simply sends the packet normally, with no Routing header. If 2275 the destination node is not a mobile node (or is a mobile node that 2276 is currently at home), the packet will be delivered directly to this 2277 node and processed normally by it. If, however, the destination node 2278 is a mobile node that is currently away from home, the packet will 2279 be intercepted by the mobile node's home agent and tunneled (using 2280 IPv6 encapsulation [4]) to the mobile node's current primary care-of 2281 address, as described in Section 9.6. The mobile node will then send 2282 a Binding Update to the sending node, as described in Section 10.7, 2283 allowing the sending node to create a Binding Cache entry for its use 2284 in sending subsequent packets to this mobile node. 2286 9. Home Agent Operation 2288 9.1. Receiving Router Advertisement Messages 2290 For each link on which a router provides service as a home agent, the 2291 router maintains a Home Agents List recording information about all 2292 other home agents on that link. This list is used in the dynamic 2293 home agent address discovery mechanism, described in Section 9.2. 2294 The information for the list is learned through receipt of the 2295 periodic unsolicited multicast Router Advertisements from each other 2296 home agent on the link, in which the Home Agent (H) bit is set, in a 2297 manner similar to the Default Router List conceptual data structure 2298 maintained by each host for Neighbor Discovery [13]. 2300 On receipt of a valid Router Advertisement, as defined in the 2301 processing algorithm specified for Neighbor Discovery [13], the home 2302 agent performs the following steps, in addition to any steps already 2303 required of it by Neighbor Discovery: 2305 - If the Home Agent (H) bit in the Router Advertisement is not set, 2306 skip all of the following steps. There are no special processing 2307 steps required by Mobile IP for this Router Advertisement, since 2308 the Advertisement was not sent by a home agent. 2310 - Otherwise, extract the Source Address from the IP header of the 2311 Router Advertisement. This is the link-local IP address on this 2312 link of the home agent sending this Advertisement [13]. 2314 - Determine from the Router Advertisement the preference for this 2315 home agent. If the Router Advertisement contains a Home Agent 2316 Information Option, then the preference is taken from the Home 2317 Agent Preference field in the option; otherwise, the default 2318 preference of 0 SHOULD be used. 2320 - Determine from the Router Advertisement the lifetime for 2321 this home agent. If the Router Advertisement contains a Home 2322 Agent Information Option, then the lifetime is taken from 2323 the Home Agent Lifetime field in the option; otherwise, the 2324 lifetime specified by the Router Lifetime field in the Router 2325 Advertisement SHOULD be used. 2327 - If the link-local address of the home agent sending this 2328 Advertisement is already present in this home agent's Home 2329 Agents List and the received home agent lifetime value is zero, 2330 immediately delete this entry in the Home Agents List. 2332 - Otherwise, if the link-local address of the home agent sending 2333 this Advertisement is already present in the receiving home 2334 agent's Home Agents List, reset its lifetime and preference to 2335 the values determined above. 2337 - If the link-local address of the home agent sending this 2338 Advertisement, as determined above, is not already present in 2339 the Home Agents List maintained by the receiving home agent, and 2340 the lifetime for the sending home agent, as determined above, 2341 is non-zero, create a new entry in the list, and initialize its 2342 lifetime and preference to the values determined above. 2344 - If the Home Agents List entry for the link-local address of 2345 the home agent sending this Advertisement was not deleted as 2346 described above, determine any global address(es) of the home 2347 agent based on each Prefix Information option received in 2348 this Advertisement in which the Router Address (R) bit is set 2349 (Section 6.2). For each such global address determined from this 2350 Advertisement, add this global address to the list of global 2351 addresses for this home agent in this Home Agents List entry. 2353 A home agent SHOULD maintain an entry in its Home Agents List for 2354 each such valid home agent address until that entry's lifetime 2355 expires, after which time the entry MUST be deleted. 2357 9.2. Dynamic Home Agent Address Discovery 2359 When a node receives a Binding Update, it MUST validate it and 2360 determine the type of Binding Update according to the steps described 2361 in Section 8.2. This section describes the processing of a valid 2362 Binding Update that indicates that the mobile node sending it is 2363 attempting dynamic home agent address discovery. 2365 As described in Section 10.6, a mobile node attempts dynamic home 2366 agent address discovery by sending its "home registration" Binding 2367 Update to the Home-Agents anycast address for its home IP subnet 2368 prefix (the packet MUST also include a Home Address option). A home 2369 agent receiving such a Binding Update that is serving this subnet 2370 (the home agent is configured with this anycast address on one of its 2371 network interfaces) MUST reject the Binding Update and SHOULD return 2372 a Binding Acknowledgement indicating this rejection, with the Source 2373 Address of the packet carrying the Binding Acknowledgement set to one 2374 of the global unicast addresses of the home agent. The Status field 2375 in the Binding Acknowledgement MUST be set to 135 (dynamic home agent 2376 address discovery response). 2378 In this Binding Acknowledgement rejecting the dynamic home agent 2379 address discovery Binding Update, this home agent SHOULD include a 2380 Home Agents List Sub-Option as follows: 2382 - The Home Agents List Sub-Option in this Binding Acknowledgement 2383 SHOULD contain one global IP address for each home agent 2384 currently listed in this home agent's own Home Agents List 2385 (Section 4.3). However, if this home agent's own global IP 2386 address would be placed in the list (as described below) as the 2387 first entry in the list, then this home agent SHOULD NOT include 2388 its own address in the list in the sub-option in the Binding 2389 Acknowledgement. Not placing this home agent's own IP address in 2390 the list will cause the receiving mobile node to consider this 2391 home agent as the most preferred home agent; otherwise, this home 2392 agent will be considered to be preferred in its order given by 2393 its place in the list returned. 2395 - The IP addresses in the Home Agents List should be placed in 2396 the Home Agents List Sub-Option in the Binding Acknowledgement 2397 in order of decreasing preference value, based either on the 2398 respective advertised preference from a Home Agent Information 2399 option or on the default preference of 0 if no preference is 2400 advertised (or on the configured home agent preference for this 2401 home agent itself). The home agent with the highest preference 2402 SHOULD be listed first, and the home agent with the lowest 2403 preference SHOULD be listed last. 2405 - Among home agents with equal preference, their IP addresses in 2406 the Home Agents List SHOULD be listed in an order randomized with 2407 respect to other home agents with equal preference, each time a 2408 Binding Acknowledgement with a Home Agents List Sub-Option is 2409 returned by this home agent. 2411 - For each entry in this home agent's Home Agents List, if more 2412 than one global IP address is associated with this list entry, 2413 then one of these global IP addresses SHOULD be selected to 2414 include in the Home Agents List Sub-Option to be returned in the 2415 Binding Acknowledgement. As described in Section 4.3, one Home 2416 Agents List entry, identified by the home agent's link-local 2417 address, exists for each home agent on the link; associated with 2418 that list entry is one or more global IP addresses for this 2419 home agent, learned through Prefix Information options with the 2420 Router Address (R) bit is set, received in Router Advertisements 2421 from this link-local address. The selected global IP address 2422 for each home agent to include in forming the Home Agents List 2423 Sub-Option to be returned in the Binding Acknowledgement MUST 2424 be the global IP address of the respective home agent sharing a 2425 prefix with the mobile node's home address for which the Binding 2426 Acknowledgement is being returned; if no such global IP address 2427 is known for some home agent, an entry for that home agent MUST 2428 NOT be included in the Home Agents List Sub-Option returned in 2429 the Binding Acknowledgement. 2431 - In order to avoid the possibility of the packet carrying the 2432 Binding Acknowledgement being fragmented, if the resulting 2433 total packet size containing the complete Home Agents List 2434 Sub-Option would exceed the minimum IPv6 MTU [5], the home agent 2435 SHOULD reduce the number of home agent IP addresses returned 2436 in the packet to the number of addresses that will fit without 2437 exceeding this limit. The home agent addresses returned in the 2438 packet SHOULD be those from the complete list with the highest 2439 preference. 2441 The mobile node, upon receiving this Binding Acknowledgement, MAY 2442 then resend its Binding Update to the home agent address given as the 2443 IP Source Address of the packet carrying the Binding Acknowledgement 2444 or to any of the unicast IP addresses listed in the Home Agents List 2445 Sub-Option in the Acknowledgement. For example, the mobile node may 2446 re-attempt its home registration with each of these home agents in 2447 turn, by sending each a Binding Update and waiting for the matching 2448 Binding Acknowledgement, until its registration is accepted by one 2449 of these home agents. In trying each of the returned home agent 2450 addresses, the mobile node SHOULD try each in the order listed in the 2451 Home Agents List Sub-Option in the Binding Acknowledgement. If the 2452 home agent identified by the Source Address field in the IP header 2453 of the packet carrying the Binding Acknowledgement is not listed in 2454 the Home Agents List Sub-Option, it SHOULD be tried before the first 2455 address given in the list; otherwise, it SHOULD be tried in the in 2456 its listed order. 2458 9.3. Primary Care-of Address Registration 2460 When a node receives a Binding Update, it MUST validate it and 2461 determine the type of Binding Update according to the steps described 2462 in Section 8.2. This section describes the processing of a valid 2463 Binding Update that requests the receiving node to serve as its home 2464 agent, registering its primary care-of address. 2466 To begin processing the Binding Update, the home agent MUST perform 2467 the following sequence of tests: 2469 - If the node is not a router that implements home agent 2470 functionality, then the node MUST reject the Binding Update and 2471 SHOULD return a Binding Acknowledgement to the mobile node, in 2472 which the Status field is set to 132 (home registration not 2473 supported). 2475 - Else, if the home address for the binding (the Home Address field 2476 in the packet's Home Address option) is not an on-link IPv6 2477 address with respect to the home agent's current Prefix List, 2478 then the home agent MUST reject the Binding Update and SHOULD 2479 return a Binding Acknowledgement to the mobile node, in which the 2480 Status field is set to 133 (not home subnet). 2482 - Else, if the Prefix Length field is nonzero in the Binding Update 2483 and this length differs from the length of the home agent's own 2484 knowledge of the corresponding subnet prefix on the home link, 2485 then the home agent MUST reject the Binding Update and SHOULD 2486 return a Binding Acknowledgement to the mobile node, in which the 2487 Status field is set to 136 (incorrect subnet prefix length). 2489 - Else, if the home agent chooses to reject the Binding Update for 2490 any other reason (e.g., insufficient resources to serve another 2491 mobile node as a home agent), then the home agent SHOULD return a 2492 Binding Acknowledgement to the mobile node, in which the Status 2493 field is set to an appropriate value to indicate the reason for 2494 the rejection. 2496 If the home agent does not reject the Binding Update as described 2497 above, then it becomes the home agent for the mobile node. The new 2498 home agent (the receiving node) MUST then create a new entry in its 2499 Binding Cache for this mobile node (or update its existing Binding 2500 Cache entry for this mobile node, if such an entry already exists) 2501 The home address of the mobile node is taken from the Home Address 2502 field in the packet's Home Address option. The care-of address for 2503 this Binding Cache entry is taken from the Care-of Address field of 2504 the Binding Update (if the Care-of Address Present (C) bit is set in 2505 the Binding Update) or from the Source Address field in the packet's 2506 IPv6 header (otherwise). 2508 The home agent MUST mark this Binding Cache entry as a "home 2509 registration" to indicate that the node is serving as a home 2510 agent for this binding. Binding Cache entries marked as a "home 2511 registration" MUST be excluded from the normal cache replacement 2512 policy used for the Binding Cache (Section 8.7) and MUST NOT be 2513 removed from the Binding Cache until the expiration of the Lifetime 2514 period. 2516 The lifetime for the Binding Cache entry MUST NOT be greater than 2517 the remaining valid lifetime for the subnet prefix in the mobile 2518 node's home address specified with the Binding Update. The remaining 2519 valid lifetime for this prefix is determined by the home agent based 2520 on its own Prefix List entry for this prefix [13]. Furthermore, 2521 if the Prefix Length field in the Binding Update is nonzero, then 2522 the lifetime for the Binding Cache entry MUST NOT be greater than 2523 the minimum remaining valid lifetime for all subnet prefixes on 2524 the mobile node's home link. If the value of the Lifetime field 2525 specified by the mobile node in its Binding Update is greater than 2526 this prefix lifetime, the home agent MUST decrease the binding 2527 lifetime to less than or equal to the prefix valid lifetime. The 2528 home agent MAY further decrease the specified lifetime for the 2529 binding, for example based on a local policy implemented by the home 2530 agent. The resulting lifetime is stored by the home agent in the 2531 Binding Cache entry, and this Binding Cache entry MUST be deleted by 2532 the home agent after the expiration of this lifetime. 2534 The Prefix Length in the Binding Update MUST also be saved in the 2535 Binding Cache entry. 2537 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2538 be), then the home agent MUST return a Binding Acknowledgement to the 2539 mobile node, constructed as follows: 2541 - The Status field MUST be set to a value indicating success (the 2542 value MUST be less than 128). The only currently defined success 2543 Status value is 0, indicating simply that the Binding Update was 2544 accepted. 2546 - The Sequence Number field MUST be copied from the Sequence Number 2547 given in the Binding Update. 2549 - The Lifetime field MUST be set to the remaining lifetime for 2550 the binding as set by the home agent in its "home registration" 2551 Binding Cache entry for the mobile node. As described above, 2552 this lifetime MUST NOT be greater than the remaining valid 2553 lifetime for the subnet prefix in the mobile node's home address. 2555 - The Refresh field MUST be set to a value less than or equal to 2556 the Lifetime value being returned in the Binding Update. If the 2557 home agent stores the Binding Cache entry in nonvolatile storage 2558 (that survives the crash or other failure of the home agent), 2559 then the Refresh field SHOULD be set to the same value as the 2560 Lifetime field; otherwise, the home agent MAY set the Refresh 2561 field to a value less than the Lifetime field, to indicate that 2562 the mobile node SHOULD attempt to refresh its home registration 2563 at the indicated shorter interval (although the home agent will 2564 still retain the registration for the Lifetime period, even if 2565 the mobile node does not refresh its registration within the 2566 Refresh period). 2568 In addition, the home agent MUST follow the procedure defined in 2569 Section 9.5 to intercept packets on the mobile node's home link 2570 addressed to the mobile node, while the home agent is serving as the 2571 home agent for this mobile node. 2573 9.4. Primary Care-of Address De-registration 2575 When a node receives a Binding Update, it MUST validate it and 2576 determine the type of Binding Update according to the steps described 2577 in Section 8.2. This section describes the processing of a valid 2578 Binding Update that requests the receiving node to no longer serve as 2579 its home agent, de-registering its primary care-of address. 2581 To begin processing the Binding Update, the home agent MUST perform 2582 the following test: 2584 - If the receiving node has no entry in its Binding Cache for this 2585 mobile node that is marked as a "home registration", then this 2586 node MUST reject the Binding Update and SHOULD return a Binding 2587 Acknowledgement to the mobile node, in which the Status field is 2588 set to 137 (not home agent for this mobile node). 2590 If the home agent does not reject the Binding Update as described 2591 above, then it MUST delete any existing entry in its Binding Cache 2592 for this mobile node. 2594 If the Acknowledge (A) bit is set in the Binding Update (it SHOULD 2595 be), then the home agent MUST return a Binding Acknowledgement to the 2596 mobile node, constructed as follows: 2598 - The Status field MUST be set to a value indicating success (the 2599 value MUST be less than 128). The only currently defined success 2600 Status value is 0, indicating simply that the Binding Update was 2601 accepted. 2603 - The Sequence Number field MUST be copied from the Sequence Number 2604 given in the Binding Update. 2606 - The Lifetime field MUST be set to zero. 2608 - The Refresh field MUST be set to zero. 2610 In addition, the home agent MUST stop intercepting packets on the 2611 mobile node's home link addressed to the mobile node (Section 9.5). 2613 9.5. Intercepting Packets for a Mobile Node 2615 While a node is serving as the home agent for mobile node (while the 2616 node has an entry in its Binding Cache for this mobile node that is 2617 marked as a "home registration"), this node MUST attempt to intercept 2618 packets on the mobile node's home link addressed to the mobile node, 2619 and MUST tunnel each intercepted packet to the mobile node using 2620 using IPv6 encapsulation [4]. 2622 In order to intercept such packets on the home link, when a node 2623 becomes the home agent for some mobile node (it did not already 2624 have a Binding Cache entry for this mobile node marked as a "home 2625 registration"), then the home agent MUST multicast onto the home link 2626 a "gratuitous" Neighbor Advertisement message [13] on behalf of the 2627 mobile node. Specifically, the home agent performs the following 2628 steps: 2630 - The home agent examines the value of the Prefix Length field 2631 in the new "home registration" Binding Cache entry. If this 2632 value is zero, the following step is carried out only for the 2633 individual home address specified for this binding. If, instead, 2634 this field is nonzero, then the following step is carried out 2635 for each address for the mobile node formed from the interface 2636 identifier in the mobile node's home address in this binding 2637 (the remaining low-order bits in the address after the indicated 2638 subnet prefix), together with each one of the subnet prefixes 2639 currently considered by the home agent to be on-link (including 2640 both the link-local and site-local prefix). 2642 - For each specific IP address for the mobile node determined 2643 in the first step above, the home agent multicasts onto the 2644 home link (to the all-nodes multicast address) a Neighbor 2645 Advertisement message [13] on behalf of the mobile node, to 2646 advertise the home agent's own link-layer address for this IP 2647 address. The Target Address in the Neighbor Advertisement 2648 message MUST be set to this IP address for the mobile node, and 2649 the Advertisement MUST include a Target Link-layer Address option 2650 specifying the home agent's link-layer address. The Solicited 2651 Flag (S) in the Advertisement MUST NOT be set, since it was not 2652 solicited by any Neighbor Solicitation message. The Override 2653 Flag (O) in the Advertisement MUST be set, indicating that the 2654 Advertisement SHOULD override any existing Neighbor Cache entry 2655 at any node receiving it. 2657 Any node on the home link receiving one of the Neighbor Advertisement 2658 messages described above will thus update its Neighbor Cache to 2659 associate the mobile node's address with the home agent's link 2660 layer address, causing it to transmit any future packets for the 2661 mobile node normally destined to this address instead to the mobile 2662 node's home agent. Since multicasts on the local link (such as 2663 Ethernet) are typically not guaranteed to be reliable, the home 2664 agent MAY retransmit this Neighbor Advertisement message up to 2665 MAX_ADVERT_REXMIT times to increase its reliability. It is still 2666 possible that some nodes on the home link will not receive any of 2667 these Neighbor Advertisements, but these nodes will eventually be 2668 able to detect the link-layer address change for the mobile node's 2669 home address, through use of Neighbor Unreachability Detection [13]. 2671 While a node is serving as a home agent for some mobile node (it 2672 still has a "home registration" entry for this mobile node in its 2673 Binding Cache), the home agent uses IPv6 Neighbor Discovery [13] 2674 to intercept unicast packets on the home link addressed the mobile 2675 node's home address. In order to intercept packets in this way, 2676 the home agent MUST act as a proxy for this mobile node to reply to 2677 any received Neighbor Solicitation messages for it. When a home 2678 agent receives a Neighbor Solicitation message, it MUST check if the 2679 Target Address specified in the message matches the home address 2680 of any mobile node for which it has a Binding Cache entry marked 2681 as a "home registration". This check MUST include all possible 2682 home addresses for the mobile node, based on the subnet prefixes 2683 currently considered to be on-link by the home agent (including the 2684 corresponding link-local address and site-local address), if the 2685 Prefix Length in the Binding Cache entry for this mobile node (from 2686 the Binding Update that created this Cache entry) is nonzero. 2688 If such an entry exists in the home agent's Binding Cache, the home 2689 agent MUST reply to the Neighbor Solicitation message with a Neighbor 2690 Advertisement message, giving the home agent's own link-layer address 2691 as the link-layer address for the specified Target Address. Acting 2692 as a proxy in this way allows other nodes on the mobile node's home 2693 link to resolve the mobile node's IPv6 home address, and allows 2694 the home agent to to defend these addresses on the home link for 2695 Duplicate Address Detection [13]. 2697 9.6. Tunneling Intercepted Packets to a Mobile Node 2699 For any packet sent to a mobile node from the mobile node's home 2700 agent (for which the home agent is the original sender of the 2701 packet), the home agent is operating as a correspondent node of 2702 the mobile node for this packet and the procedures described in 2703 Section 8.9 apply. The home agent (as a correspondent node) uses a 2704 Routing header to route the packet to the mobile node by way of the 2705 care-of address in the home agent's Binding Cache (the mobile node's 2706 primary care-of address, in this case). 2708 While the mobile node is away from home and this node is acting 2709 as the mobile node's home agent, the home agent intercepts any 2710 packets on the home link addressed to the mobile node's home address 2711 (including addresses formed from other on-link prefixes, if the 2712 Prefix Length field was nonzero in the Binding Update), as described 2713 in Section 9.5. The home agent cannot use a Routing header to 2714 forward these intercepted packets to the mobile node, since it cannot 2715 modify the packet in flight without invalidating any existing IPv6 2716 AH [8] or ESP [9] header present in the packet. 2718 For forwarding each intercepted packet to the mobile node, the 2719 home agent MUST tunnel the packet to the mobile node using IPv6 2720 encapsulation [4]; the tunnel entry point node is the home agent, 2721 and the tunnel exit point node is the primary care-of address as 2722 registered with the home agent (which is an address of the mobile 2723 node itself). When a home agent encapsulates an intercepted packet 2724 for forwarding to the mobile node, the home agent sets the Source 2725 Address in the prepended tunnel IP header to the home agent's own IP 2726 address, and sets the Destination Address in the tunnel IP header 2727 to the mobile node's primary care-of address. When received by the 2728 mobile node (using its primary care-of address), normal processing of 2729 the tunnel header [4] will result in decapsulation and processing of 2730 the original packet by the mobile node. 2732 However, packets addressed to the mobile node's link-local address 2733 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 2734 be discarded, and the home agent SHOULD return an ICMP Destination 2735 Unreachable, Code 3, message to the packet's Source Address (unless 2736 this Source Address is a multicast address). Packets addressed to 2737 the mobile node's site-local address SHOULD be tunneled to the mobile 2738 node by default, but this behavior MUST be configurable to disable 2739 it; currently, the exact definition and semantics of a "site" and a 2740 site-local address are undefined in IPv6, and this default behavior 2741 might change at some point in the future. 2743 Tunneling of multicast packets to a mobile node follows similar 2744 limitations to those defined above for unicast packets addressed to 2745 the mobile node's link-local and site-local addresses. Multicast 2746 packets addressed to a multicast address with link-local scope [7], 2747 to which the mobile node is subscribed, MUST NOT be tunneled 2748 to the mobile node; such packets SHOULD be silently discarded 2749 (after delivering to other local multicast recipients). Multicast 2750 packets addressed to a multicast address with scope larger 2751 than link-local but smaller than global (e.g., site-local and 2752 organization-local) [7], to which the mobile node is subscribed, 2753 SHOULD be tunneled to the mobile node by default, but this behavior 2754 MUST be configurable to disable it; this default behavior might 2755 change at some point in the future as the definition of these scopes 2756 become better defined in IPv6. 2758 9.7. Renumbering the Home Subnet 2760 IPv6 provides mechanisms through Neighbor Discovery [13] and Address 2761 Autoconfiguration [22] to aid in renumbering a subnet, such as when a 2762 site switches to a new network service provider. In renumbering, new 2763 prefixes and addresses can be introduced for the subnet and old ones 2764 can be deprecated and removed. These mechanisms are defined to work 2765 while all nodes using the old prefixes are at home, connected to the 2766 link using these prefixes. Mobile IPv6 extends these mechanisms for 2767 the case in which one or more mobile nodes using the old prefixes are 2768 away from home while the renumbering takes place. 2770 The IPv6 renumbering mechanisms are based on nodes on the link 2771 receiving Prefix Information options in Router Advertisement messages 2772 giving the valid lifetime and preferred lifetime for different 2773 prefixes on the link [13]. Mobile IPv6 arranges to tunnel certain 2774 Router Advertisements giving "important" Prefix Information options 2775 to mobile nodes while away from home. To avoid the need to tunnel 2776 all Router Advertisements from the home link to a mobile node away 2777 from home, those Router Advertisements that are tunneled to the 2778 mobile node are retransmitted until acknowledged. To avoid possible 2779 security attacks from forged Router Advertisements tunneled to 2780 the mobile node, all such tunneled Router Advertisements must be 2781 authenticated to the mobile node by its home agent using AH [8] or 2782 ESP [9]. 2784 Specifically, a home agent serving some mobile node SHOULD construct 2785 and tunnel to the mobile node a new Router Advertisement when any of 2786 the following conditions occur: 2788 - The preferred or valid lifetime for an existing prefix on the 2789 home link is reduced. 2791 - A new prefix is introduced on the home link. 2793 - The state of the home agent's AdvManagedFlag flag [13] changes 2794 from FALSE to TRUE or from TRUE to FALSE. 2796 The home agent determines these conditions based on its own 2797 configuration as a router and based on the Router Advertisements 2798 that it receives on the home link. The home agent constructs a new 2799 Router Advertisement message containing no options other than the 2800 Prefix Information options describing the prefixes for which one of 2801 the conditions above has occurred since the last Router Advertisement 2802 tunneled to and acknowledged by the mobile node. When multiple 2803 conditions occur at or near the same time, the home agent SHOULD 2804 attempt to combine them into a single Router Advertisement message to 2805 the mobile node. 2807 In tunneling each such Router Advertisement to the mobile node, the 2808 home agent MUST construct the packet as follows: 2810 - The Source Address in the packet's IPv6 header MUST be set to the 2811 home agent's IP address to which the mobile node addressed its 2812 current home registration. 2814 - The packet MUST include either an AH [8] or ESP [9] header 2815 providing sender authentication, data integrity protection, and 2816 replay protection. 2818 - The packet MUST include a Binding Request destination option. 2820 - The Binding Request destination option MUST include a Unique 2821 Identifier Sub-Option (Section 5.5), with the unique identifier 2822 in the sub-option data set to a value different than that in 2823 any other Binding Request sent recently by this node. The word 2824 "recently" here means within the maximum likely lifetime of a 2825 packet, including transit time from source to destination and 2826 time spent awaiting reassembly with other fragments of the same 2827 packet, if fragmented. However, it is not required that a source 2828 node know the maximum packet lifetime. Rather, it is assumed 2829 that the requirement can be met by maintaining a simple 16-bit 2830 "wrap-around" counter to generate unique identifiers for Binding 2831 Requests that contain a Unique Identifier Sub-Option, incremented 2832 each time a Binding Request containing a Unique Identifier 2833 Sub-Option is sent. 2835 - The packet MUST be tunneled to the mobile node's primary care-of 2836 address using a Routing header, in the same way as any packet 2837 sent to the mobile node originated by the home agent (rather than 2838 using IPv6 encapsulation, as would be used by the home agent for 2839 intercepted packets). 2841 The home agent SHOULD periodically continue to retransmit this 2842 tunneled packet to the mobile node, until it is acknowledged by 2843 the receipt from the mobile node of a Binding Update matching 2844 the Binding Request in the packet (i.e., with matching Sequence 2845 Number). A Binding Update matches a Binding Request if it specifies 2846 a binding for the mobile node to which the Binding Request was sent 2847 and contains a Unique Identifier Sub-Option matching the unique 2848 identifier sent in the Unique Identifier Sub-Option in the Binding 2849 Request. 2851 If while the home agent is still retransmitting a Router 2852 Advertisement to the mobile node, another condition as described 2853 above occurs on the home link causing another Router Advertisement 2854 to be tunneled to the mobile node, the home agent SHOULD combine any 2855 Prefix Information options in the unacknowledged Router Advertisement 2856 into the new Router Advertisement and then begin retransmitting the 2857 new Router Advertisement rather than the old one. When tunneling 2858 a new Router Advertisement, even if it contains Prefix Information 2859 options sent previously in an unacknowledged tunneled Router 2860 Advertisement, the home agent MUST generate a new unique identifer 2861 for use in the Unique Identifier Sub-Option in the Binding Request 2862 tunneled with the new Router Advertisement. 2864 In addition, as described in Section 9.3, the lifetime returned by a 2865 mobile node's home agent in its Binding Acknowledgement in response 2866 to registration of a new primary care-of address by the mobile node 2867 MUST be no greater than the remaining valid lifetime for the subnet 2868 prefix in the mobile node's home address. Furthermore, as described 2869 in Section 10.7, Binding Updates sent by the mobile node to other 2870 nodes MUST use a lifetime no greater than the remaining lifetime of 2871 its home registration of its primary care-of address. These limits 2872 on a binding lifetimes ensure that no node uses a mobile node's home 2873 address beyond the time that it becomes invalid. The mobile node 2874 SHOULD further limit the lifetimes that it sends on any Binding 2875 Updates to be within the remaining preferred lifetime for the prefix 2876 in its home address. 2878 10. Mobile Node Operation 2880 10.1. Sending Packets While Away from Home 2882 While a mobile node is away from home, it continues to use its home 2883 address as well as also using one or more care-of addresses. When 2884 sending a packet while away from home, a mobile node MAY choose among 2885 these in selecting the address that it will use as the source of the 2886 packet, as follows: 2888 - From the point of view of protocol layers and applications 2889 above Mobile IP (e.g., transport protocols), the mobile node 2890 will generally use its home address as the source of the packet 2891 for most packets, even while away from home, since Mobile IP 2892 is designed to make mobility transparent to such software. 2893 Doing so also makes the node's mobility and the fact that it is 2894 currently away from home transparent to the correspondent nodes 2895 with which it communicates. For packets sent that are part of 2896 transport-level connections established while the mobile node 2897 was at home, the mobile node MUST use its home address in this 2898 way. Likewise, for packets sent that are part of transport-level 2899 connections that the mobile node may still be using after moving 2900 to a new location, the mobile node SHOULD use its home address 2901 in this way. When sending such packets, Mobile IP will modify 2902 the packet to move the home address into a Home Address option 2903 and will set the IPv6 header's Source Address field to one of 2904 the mobile node's care-of addresses; these modifications to 2905 the packet are then reversed in the node receiving the packet, 2906 restoring the mobile node's home address to be the packet's 2907 Source Address before processing by higher protocol layers and 2908 applications. 2910 - For short-term communication, particularly for communication that 2911 may easily be retried if it fails, the mobile node MAY choose 2912 to directly use one of its care-of addresses as the source of 2913 the packet, thus not requiring the use of a Home Address option 2914 in the packet. An example of this type of communication might 2915 be DNS queries sent by the mobile node [11, 12]. Using the 2916 mobile node's care-of address as the source for such queries will 2917 generally have a lower overhead than using the mobile node's 2918 home address, since no extra options need be used in either the 2919 query or its reply, and all packets can be routed normally, 2920 directly between their source and destination without relying 2921 on Mobile IP. If the mobile node has no particular knowledge 2922 that the communication being sent fits within this general type 2923 of communication, however, the mobile node SHOULD NOT use its 2924 care-of address as the source of the packet in this way. 2926 If the mobile node uses one of its care-of addresses as the source 2927 of some packet while away from home, no special Mobile IP processing 2928 is required for sending this packet. The packet is simply addressed 2929 and transmitted in the same way as any normal IPv6 packet, setting 2930 the Source Address field in the packet's IPv6 header to this care-of 2931 address. 2933 On the other hand, if while away from home, the mobile node uses its 2934 home address as the source of a packet from the point of view of 2935 higher protocol layers or applications as described above, special 2936 Mobile IP processing of this packet is required for the insertion of 2937 the Home Address option. Specifically: 2939 - Since Mobile IP is transparent to higher protocol layers (e.g., 2940 to TCP), the packet is initially constructed using the mobile 2941 node's home address as the packet's Source Address, in the same 2942 way as if the mobile node were at home. 2944 - If the mobile node is at home, no special Mobile IP processing 2945 for this packet is required. The packet is sent normally and the 2946 following additional steps are not performed. 2948 - Likewise, if the Source Address field in the packet's IPv6 header 2949 is not the mobile node's home address, no special Mobile IP 2950 processing for this packet is required. The packet is sent 2951 normally and the following additional steps are not performed. 2953 - Otherwise, insert a Home Address option into the packet, with the 2954 Home Address field copied from the original value of the Source 2955 Address field in the packet. 2957 - Change the Source Address field in the packet's IPv6 header to 2958 one of the mobile node's care-of addresses. This will typically 2959 be the mobile node's current primary care-of address, but MUST 2960 be a care-of address with a subnet prefix that is on-link on the 2961 network interface on which the mobile node will transmit the 2962 packet. 2964 This addition of the Home Address option to a packet MUST be 2965 performed before outgoing IPsec processing, such as the addition of 2966 an AH [8] or ESP [9] header to the packet, is performed. Likewise, 2967 IPsec processing for a received packet containing a Home Address 2968 option MUST be performed before the packet is possibly modified as 2969 part of processing the Home Address option. By using the care-of 2970 address as the Source Address in the IPv6 header, with the mobile 2971 node's home address instead in the Home Address option, the packet 2972 will be able to safely pass through any router implementing ingress 2973 filtering [6]. 2975 10.2. Receiving Packets While Away from Home 2977 While away from home, a mobile node will receive packets addressed to 2978 its home address, by one of three methods: 2980 - Packets sent by a correspondent node that does not have a 2981 Binding Cache entry for the mobile node, will be sent by the 2982 correspondent node in the same way as any normal IP packet. Such 2983 packets will then be intercepted by the mobile node's home agent, 2984 encapsulated using IPv6 encapsulation [4], and tunneled to the 2985 mobile node's primary care-of address. 2987 - Packets sent by a correspondent node that has a Binding Cache 2988 entry for the mobile node that contains the mobile node's current 2989 care-of address, will be sent by the correspondent node using 2990 a Routing header. The packet will be addressed to the mobile 2991 node's care-of address, with the final hop in the Routing header 2992 directing the packet to the mobile node's home address; the 2993 processing of this last hop of the Routing header is entirely 2994 internal to the mobile node, since the care-of address and home 2995 address are both addresses within the mobile node. 2997 - Packets sent by a correspondent node that has a Binding Cache 2998 entry for the mobile node that contains an out-of-date care-of 2999 address for the mobile node, will be sent by the correspondent 3000 node using a Routing header, as described above. If the mobile 3001 node sent a Binding Update to its previous default router when 3002 moving from this care-of address to another, and if the Binding 3003 Cache entry that was created from this Binding Update is still 3004 present in this router's Binding Cache, then such a packet 3005 will be intercepted by this router, encapsulated using IPv6 3006 encapsulation [4], and tunneled to the mobile node's primary 3007 care-of address (registered with this router, acting as a home 3008 agent for this out-of-date care-of address). 3010 For packets received by either the first or last of these three 3011 methods, the mobile node SHOULD send a Binding Update to the original 3012 sender of the packet, as described in Section 10.7, subject to the 3013 rate limiting defined in Section 10.10. The mobile node SHOULD 3014 also process the received packet in the manner defined for IPv6 3015 encapsulation [4], which will result in the encapsulated (inner) 3016 packet being processed normally by upper-layer protocols within the 3017 mobile node, as if it had been addressed (only) to the mobile node's 3018 home address. 3020 For packets received by the second method above (using a Routing 3021 header), the mobile node SHOULD process the received packet in the 3022 manner defined for the type of IPv6 Routing header used [5], which 3023 will result in the packet being processed normally by upper-layer 3024 protocols within the mobile node, as if it had been addressed (only) 3025 to the mobile node's home address. 3027 In addition, the general procedures defined by IPv6 for Routing 3028 headers suggest that a received Routing header MAY be automatically 3029 "reversed" to construct a Routing header for use in any response 3030 packets sent by upper-layer protocols, if the received packet is 3031 authenticated [5]. If this is done for upper-layer protocol response 3032 packets sent by a mobile node while away from home, the mobile 3033 node SHOULD NOT include its own care-of address, which appears in 3034 the Routing header of the received packet, in the reversed route 3035 for the response packet. If the received Routing header contained 3036 no additional hops (other than the mobile node's home address and 3037 care-of address), then any upper-layer protocol response packet 3038 SHOULD NOT include a Routing header. 3040 10.3. Movement Detection 3042 A mobile node MAY use any combination of mechanisms available to it 3043 to detect when it has moved from one link to another. The primary 3044 movement detection mechanism for Mobile IPv6 defined here uses the 3045 facilities of IPv6 Neighbor Discovery, including Router Discovery and 3046 Neighbor Unreachability Detection. The description here is based on 3047 the conceptual model of the organization and data structures defined 3048 by Neighbor Discovery [13]. 3050 Mobile nodes SHOULD use Router Discovery to discover new routers and 3051 on-link subnet prefixes; a mobile node MAY send Router Solicitation 3052 messages, or MAY wait for unsolicited (periodic) multicast Router 3053 Advertisement messages, as specified for Router Discovery [13]. 3054 Based on received Router Advertisement messages, a mobile node (in 3055 the same way as any other node) maintains an entry in its Default 3056 Router List for each router, and an entry in its Prefix List for each 3057 subnet prefix, that it currently considers to be on-link. Each entry 3058 in these lists has an associated invalidation timer value (extracted 3059 from the Router Advertisement) used to expire the entry when it 3060 becomes invalid. 3062 While away from home, a mobile node SHOULD select one router from 3063 its Default Router List to use as its default router, and one subnet 3064 prefix advertised by that router from its Prefix List to use as 3065 the subnet prefix in its primary care-of address. A mobile node 3066 MAY also have associated additional care-of addresses, using other 3067 subnet prefixes from its Prefix List. The method by which a mobile 3068 node selects and forms a care-of address from the available subnet 3069 prefixes is described in Section 10.4. The mobile node registers 3070 its primary care-of address with its home agent, as described in 3071 Section 10.5. 3073 While a mobile node is away from home and using some router as its 3074 default router, it is important for the mobile node to be able to 3075 quickly detect when that router becomes unreachable, so that it can 3076 switch to a new default router and to a new primary care-of address. 3077 Since some links (notably wireless) do not necessarily work equally 3078 well in both directions, it is likewise important for the mobile 3079 node to detect when it becomes unreachable to packets sent from its 3080 default router, so that the mobile node can take steps to ensure that 3081 any correspondent nodes attempting to communicate with it can still 3082 reach it through some other route. 3084 To detect when its default router becomes unreachable, a mobile 3085 node SHOULD use Neighbor Unreachability Detection. As specified in 3086 Neighbor Discovery [13], while the mobile node is actively sending 3087 packets to (or through) its default router, the mobile node can 3088 detect that the router (as its neighbor) is still reachable either 3089 through indications from upper layer protocols on the mobile node 3090 that a connection is making "forward progress" (e.g., receipt of TCP 3091 acknowledgements for new data transmitted), or through receipt of a 3092 Neighbor Advertisement message from its default router in response 3093 to an explicit Neighbor Solicitation messages to it. Note that 3094 although this mechanism detects that the mobile node's default router 3095 has become unreachable to the mobile node only while the mobile node 3096 is actively sending packets to it, this is the only time that this 3097 direction of reachability confirmation is needed. Confirmation 3098 that the mobile node is still reachable from the router is handled 3099 separately, as described below. 3101 For a mobile node to detect when it has become unreachable from its 3102 default router, the mobile node cannot efficiently rely on Neighbor 3103 Unreachability Detection alone, since the network overhead would be 3104 prohibitively high in many cases for a mobile node to continually 3105 probe its default router with Neighbor Solicitation messages even 3106 when it is not otherwise actively sending packets to it. Instead, 3107 a mobile node SHOULD consider receipt of any IPv6 packets from its 3108 current default router as an indication that it is still reachable 3109 from the router. Both packets from the router's IP address and 3110 (IPv6) packets from its link-layer address (e.g., those forwarded but 3111 not originated by the router) SHOULD be considered. 3113 Since the router SHOULD be sending periodic unsolicited multicast 3114 Router Advertisement messages, the mobile node will have frequent 3115 opportunity to check if it is still reachable from its default 3116 router, even in the absence of other packets to it from the router. 3117 If Router Advertisements that the mobile node receives include 3118 an Advertisement Interval option, the mobile node MAY use its 3119 Advertisement Interval field as an indication of the frequency with 3120 which it should expect to continue to receive future Advertisements 3121 from that router. This field specifies the minimum rate (the maximum 3122 amount of time between successive Advertisements) that the mobile 3123 node should expect. If this amount of time elapses without the 3124 mobile node receiving any Advertisement from this router, the mobile 3125 node can be sure that at least one Advertisement sent by the router 3126 has been lost. It is thus possible for the mobile node to implement 3127 its own policy for determining the number of Advertisements from 3128 its current default router it is willing to tolerate losing before 3129 deciding to switch to a different router from which it may currently 3130 be correctly receiving Advertisements. 3132 On some types of network interfaces, the mobile node MAY also 3133 supplement this monitoring of Router Advertisements, by setting its 3134 network interface into "promiscuous" receive mode, so that it is able 3135 to receive all packets on the link, including those not link-level 3136 addressed to it (i.e., disabling link-level address filtering). The 3137 mobile node will then be able to detect any packets sent by the 3138 router, in order to to detect reachability from the router. This 3139 use of promiscuous mode may be useful on very low bandwidth (e.g., 3140 wireless) links, but its use MUST be configurable on the mobile node. 3142 If the above means do not provide indication that the mobile node is 3143 still reachable from its current default router (i.e., the mobile 3144 node receives no packets from the router for a period of time), then 3145 the mobile node SHOULD attempt to actively probe the router with 3146 Neighbor Solicitation messages, even if it is not otherwise actively 3147 sending packets to the router. If it receives a solicited Neighbor 3148 Advertisement message in response from the router, then the mobile 3149 node can deduce that it is still reachable. It is expected that the 3150 mobile node will in most cases be able to determine its reachability 3151 from the router by listening for packets from the router as described 3152 above, and thus, such extra Neighbor Solicitation probes should 3153 rarely be necessary. 3155 With some types of networks, it is possible that additional 3156 indications about link-layer mobility can be obtained from 3157 lower-layer protocol or device driver software within the mobile 3158 node. However, a mobile node MUST NOT assume that all link-layer 3159 mobility indications from lower layers indicate a movement of the 3160 mobile node to a new link, such that the mobile node would need to 3161 switch to a new default router and primary care-of address. For 3162 example, movement of a mobile node from one cell to another in many 3163 wireless LANs can be made transparent to the IP level through use of 3164 a link-layer "roaming" protocol, as long as the different wireless 3165 LAN cells all operate as part of the same IP link with the same 3166 subnet prefix. Upon lower-layer indication of link-layer mobility, 3167 the mobile node MAY send Router Solicitation messages to determine if 3168 new routers (and new on-link subnet prefixes) are present on its new 3169 link. 3171 Such lower-layer information might also be useful to a mobile node in 3172 deciding to switch its primary care-of address to one of the other 3173 care-of addresses it has formed from the on-link subnet prefixes 3174 currently available through different routers from which the mobile 3175 node is reachable. For example, a mobile node MAY use signal 3176 strength or signal quality information (with suitable hysteresis) for 3177 its link with the available routers to decide when to switch to a new 3178 primary care-of address using that router rather than its current 3179 default router (and current primary care-of address). Even though 3180 the mobile node's current default router may still be reachable in 3181 terms of Neighbor Unreachability Detection, the mobile node MAY use 3182 such lower-layer information to determine that switching to a new 3183 default router would provide a better connection. 3185 10.4. Forming New Care-of Addresses 3187 After detecting that it has moved from one link to another (i.e., its 3188 current default router has become unreachable and it has discovered a 3189 new default router), a mobile node SHOULD form a new primary care-of 3190 address using one of the on-link subnet prefixes advertised by the 3191 new router. A mobile node MAY form a new primary care-of address 3192 at any time, except that it MUST NOT do so too frequently (not more 3193 often than once per MAX_UPDATE_RATE seconds). 3195 In addition, after discovering a new on-link subnet prefix, a mobile 3196 node MAY form a new (non-primary) care-of address using that subnet 3197 prefix, even when it has not switched to a new default router. A 3198 mobile node can have only one primary care-of address at a time 3199 (which is registered with its home agent), but it MAY have an 3200 additional care-of address for any or all of the prefixes on its 3201 current link. Furthermore, since a wireless network interface may 3202 actually allow a mobile node to be reachable on more than one link at 3203 a time (i.e., within wireless transmitter range of routers on more 3204 than one separate link), a mobile node MAY have care-of addresses 3205 on more than one link at a time. The use of more than one care-of 3206 address at a time is described in Section 10.15. 3208 As described in Section 4, in order to form a new care-of address, 3209 a mobile node MAY use either stateless [22] or stateful (e.g., 3210 DHCPv6 [2]) address autoconfiguration. If a mobile node needs to 3211 send packets as part of the method of address autoconfiguration, 3212 it MUST use an IPv6 link-local address rather than its own IPv6 3213 home address as the Source Address in the IPv6 header of each such 3214 autoconfiguration packet. 3216 In some cases, a mobile node may already know a (constant) IPv6 3217 address that has been assigned to it for its use only while 3218 visiting a specific foreign link. For example, a mobile node may be 3219 statically configured with an IPv6 address assigned by the system 3220 administrator of some foreign link, for its use while visiting that 3221 link. If so, rather than using address autoconfiguration to form a 3222 new care-of address using this subnet prefix, the mobile node MAY use 3223 its own pre-assigned address as its care-of address on this link. 3225 10.5. Sending Binding Updates to the Home Agent 3227 After deciding to change its primary care-of address as described 3228 in Sections 10.3 and 10.4, a mobile node MUST register this care-of 3229 address with its home agent in order to make this its primary care-of 3230 address. To do so, the mobile node sends a packet to its home agent 3231 containing a Binding Update option, with the packet constructed as 3232 follows: 3234 - The Home Registration (H) bit MUST be set in the Binding Update. 3236 - The Acknowledge (A) bit MUST be set in the Binding Update. 3238 - The packet MUST contain a Home Address option, giving the mobile 3239 node's home address for the binding. 3241 - The care-of address for the binding MUST be used as the Source 3242 Address in the packet's IPv6 header, or the Care-of Address 3243 Present (C) bit MUST be set in the Binding Update and the care-of 3244 address for the binding MUST be specified in the Care-of Address 3245 field in the Binding Update. 3247 - The Prefix Length field SHOULD be set to the length of the mobile 3248 node's subnet prefix in its home address, to request the mobile 3249 node's home agent to serve as a home agent for all home addresses 3250 for the mobile node based on all on-link subnet prefixes on the 3251 home link. Otherwise, this field MUST be set to zero. 3253 The Acknowledge (A) bit in the Binding Update requests the home 3254 agent to return a Binding Acknowledgement in response to this 3255 Binding Update. As described in Section 5.2, the mobile node SHOULD 3256 retransmit this Binding Update to its home agent until it receives 3257 a matching Binding Acknowledgement. Once reaching a retransmission 3258 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 3259 continue to periodically retransmit the Binding Update at this rate 3260 until acknowledged (or until it begins attempting to register a 3261 different primary care-of address). 3263 The Prefix Length field in the Binding Update allows the mobile node 3264 to request its home agent to serve all home addresses for the mobile 3265 node, as indicated by the interface identifier in the mobile node's 3266 home address (the remaining low-order bits after the indicated subnet 3267 prefix), together with each on-link subnet prefix on the home link. 3268 Until the lifetime of this registration expires, the home agent 3269 considers itself the home agent for each such home address of the 3270 mobile node. As the set of on-link subnet prefixes on the home link 3271 changes over time, the home agent changes the set of home addresses 3272 for this mobile node for which it is serving as the home agent. 3274 If the mobile node has additional home addresses using a different 3275 interface identifier, then the mobile node SHOULD send an additional 3276 packet containing a Binding Update to its home agent to register 3277 the care-of address for each such other home address (or set of 3278 home addresses sharing an interface identifier). These additional 3279 Binding Updates MUST each be sent as a separate packet, since each 3280 MUST contain an AH [8] or ESP [9] header to authenticate the Binding 3281 Update as coming from the home address being bound. 3283 10.6. Dynamic Home Agent Address Discovery 3285 It is possible that when the mobile node needs to send a Binding 3286 Update to its home agent to register its new primary care-of address, 3287 as described in Section 10.5, the mobile node may not know the 3288 address of any router on its home link that can serve as a home agent 3289 for it. For example, some nodes on its home link may have been 3290 reconfigured while the mobile node has been away from home, such that 3291 the router that was operating as the mobile node's home agent has 3292 been replaced by a different router serving this role. 3294 In this case, the mobile node SHOULD use the dynamic home agent 3295 address discovery procedure to find the address of a suitable home 3296 agent on its home link. To do so, the mobile node sends the packet, 3297 as described above, with the Destination Address in the packet's IPv6 3298 header set to the Home-Agents anycast address for its home subnet 3299 prefix. As described in Section 9.2, the home agent on its home link 3300 that receives this Binding Update will reject the Update, returning 3301 to the mobile node the home agent's own global unicast IP address 3302 along with a list of the global unicast IP addresses of each other 3303 home agent operating on the home link. The mobile node SHOULD then 3304 retransmit its Binding Update to one of these homes agent using the 3305 provided global unicast address; the mobile node MAY re-attempt 3306 this home registration with each of these home agents in turn, by 3307 sending each a Binding Update and waiting for the matching Binding 3308 Acknowledgement, until its registration is accepted by one of these 3309 home agents. 3311 If the mobile node has a current registration with some home agent 3312 on its home link (the Lifetime for that registration has not yet 3313 expired), then the mobile node MUST attempt any new registration 3314 first with that home agent. If that registration attempt fails 3315 (e.g., times out or is rejected), the mobile node SHOULD then 3316 reattempt this registration with another home agent on its home link. 3317 If the mobile node knows of no other suitable home agent, then it MAY 3318 attempt the dynamic home agent address discovery procedure described 3319 above. 3321 10.7. Sending Binding Updates to Correspondent Nodes 3323 A mobile node MAY send a Binding Update to any correspondent node at 3324 any time to allow it to cache its current care-of address (subject to 3325 the rate limiting defined in Section 10.10). In any Binding Update 3326 sent by a mobile node, the care-of address (either the Source Address 3327 in the packet's IPv6 header or the Care-of Address field in the 3328 Binding Update) MUST be set to one of the care-of addresses currently 3329 in use by the mobile node or to the mobile node's home address. 3331 If set to one of the mobile node's current care-of addresses (the 3332 care-of address given MAY differ from the mobile node's primary 3333 care-of address), the Binding Update requests the correspondent node 3334 to create or update an entry for the mobile node in the correspondent 3335 node's Binding Cache to record this care-of address for use in 3336 sending future packets to the mobile node. In this case, the 3337 Lifetime value sent in the Binding Update MUST be no greater than 3338 the remaining lifetime of the mobile node's home registration of its 3339 primary care-of address at its home agent. 3341 If, instead, the care-of address is set to the mobile node's home 3342 address, the Binding Update requests the correspondent node to delete 3343 any existing Binding Cache entry that it has for the mobile node. 3344 A mobile node MAY set the care-of address differently for sending 3345 Binding Updates to different correspondent nodes. 3347 When sending any Binding Update, the mobile node MUST record in its 3348 Binding Update List the following fields from the Binding Update: 3350 - The IP address of the node to which the Binding Update was sent. 3352 - The home address for which the Binding Update was sent (the value 3353 in the Home Address option in the packet carrying the Binding 3354 Update). 3356 - The remaining lifetime of the binding, initialized from the 3357 Lifetime field sent in the Binding Update. 3359 The mobile node MUST retain in its Binding Update List information 3360 about all Binding Updates sent, for which the lifetime of the binding 3361 has not yet expired. However, when sending a Binding Update, if an 3362 entry already exists in the mobile node's Binding Update List for 3363 an earlier Binding Update sent to that same destination node, the 3364 existing Binding Update List entry is updated to reflect the new 3365 Binding Update rather than creating a new Binding Update List entry. 3367 In general, when a mobile node sends a Binding Update to its home 3368 agent to register a new primary care-of address (as described in 3369 Section 10.5), the mobile node will also send a Binding Update to 3370 each other node for which an entry exists in the mobile node's 3371 Binding Update List. Thus, other relevant nodes are generally kept 3372 updated about the mobile node's binding and can send packets directly 3373 to the mobile node using the mobile node's current care-of address. 3375 The mobile node, however, need not send these Binding Updates 3376 immediately after configuring a new care-of address. For example, 3377 since the Binding Update is a destination option and can be included 3378 in any packet sent by a mobile node, the mobile node MAY delay 3379 sending a new Binding Update to any correspondent node for a 3380 short period of time, in hopes that the needed Binding Update 3381 can be included in some packet that the mobile node sends to that 3382 correspondent node for some other reason (for example, as part of 3383 some TCP connection in use). In this case, when sending a packet 3384 to some correspondent node, the mobile node SHOULD check in its 3385 Binding Update List to determine if a new Binding Update to this 3386 correspondent node is needed, and SHOULD include the new Binding 3387 Update in this packet as necessary. 3389 In addition, when a mobile node receives a packet for which the 3390 mobile node can deduce that the original sender of the packet has 3391 no Binding Cache entry for the mobile node, or for which the mobile 3392 node can deduce that the original sender of the packet has an 3393 out-of-date care-of address for the mobile node in its Binding Cache, 3394 the mobile node SHOULD return a Binding Update to the sender giving 3395 its current care-of address (subject to the rate limiting defined 3396 in Section 10.10). In particular, the mobile node SHOULD return a 3397 Binding Update in response to receiving a packet that meets all of 3398 the following tests: 3400 - The packet was tunneled using IPv6 encapsulation. 3402 - The Destination Address in the tunnel (outer) IPv6 header is 3403 equal to any of the mobile node's care-of addresses. 3405 - The Destination Address in the original (inner) IPv6 header 3406 is equal to one of the mobile node's home addresses; or this 3407 Destination Address is equal to one of the mobile node's previous 3408 care-of addresses, if the mobile node has an entry in its Binding 3409 Update List representing an unexpired Binding Update sent to 3410 a previous default router for this previous care-of address 3411 (Section 10.8). 3413 - The Source Address in the tunnel (outer) IPv6 header differs from 3414 the Source Address in the original (inner) IPv6 header. 3416 The destination address to which the Binding Update should be sent 3417 in response to receiving a packet meeting all of the above tests is 3418 the Source Address in the original (inner) IPv6 header of the packet. 3419 The home address for which this Binding Update is sent should be the 3420 Destination Address of the original (inner) packet. 3422 Binding Updates sent to correspondent nodes are not generally 3423 required to be acknowledged. However, if the mobile node wants 3424 to be sure that its new care-of address has been entered into a 3425 correspondent node's Binding Cache, the mobile node MAY request an 3426 acknowledgement by setting the Acknowledge (A) bit in the Binding 3427 Update. In this case, however, the mobile node SHOULD NOT continue 3428 to retransmit the Binding Update once the retransmission timeout 3429 period has reached MAX_BINDACK_TIMEOUT. 3431 A mobile node MAY choose to keep its location private from certain 3432 correspondent nodes, and thus need not send new Binding Updates to 3433 those correspondents. A mobile node MAY also send a Binding Update 3434 to such a correspondent node to instruct it to delete any existing 3435 binding for the mobile node from its Binding Cache, as described in 3436 Section 5.1. No other IPv6 nodes are authorized to send Binding 3437 Updates on behalf of a mobile node. 3439 10.8. Sending Binding Updates to the Previous Default Router 3441 After switching to a new default router (and thus also changing its 3442 primary care-of address), a mobile node MAY send a Binding Update to 3443 its previous default router, giving its new care-of address. The 3444 packet carrying the Binding Update MUST be addressed to the mobile 3445 node's previous default router's global unicast address, learned 3446 by the mobile node based on Prefix Information options received in 3447 Router Advertisements from it in which the Router Address (R) bit is 3448 set (Sections 4.3 and 6.2). 3450 If the mobile node sends such a Binding Update, the home address 3451 for the binding, specified in the Home Address option included in 3452 the packet carrying this Binding Update, MUST be set the mobile 3453 node's old primary care-of address (that it used while using this 3454 default router), and the care-of address for the binding (either the 3455 Source Address in the packet's IPv6 header or the Care-of Address 3456 field in the Binding Update) MUST be set to the mobile node's new 3457 primary care-of address. In addition, the Home Registration (H) 3458 bit MUST also be set in this Binding Update, to request the mobile 3459 node's previous default router to temporarily act as a home agent 3460 for the mobile node's old primary care-of address. The previous 3461 default router will thus tunnel packets for the mobile node to its 3462 new care-of address. All of the procedures defined for home agent 3463 operation must be followed by this previous default router for this 3464 registration. Note that the previous router does not necessarily 3465 know the mobile node's (permanent) home address as part of this 3466 registration. 3468 10.9. Retransmitting Binding Updates 3470 If, after sending a Binding Update in which the Acknowledge (A) bit 3471 is set, a mobile node fails to receive a Binding Acknowledgement 3472 within INITIAL_BINDACK_TIMEOUT seconds, the mobile node SHOULD 3473 retransmit the Binding Update until a Binding Acknowledgement 3474 is received. Such a retransmitted Binding Update MUST use the 3475 same Sequence Number value as the original transmission. The 3476 retransmissions by the mobile node MUST use an exponential 3477 back-off process, in which the timeout period is doubled 3478 upon each retransmission until either the node receives a 3479 Binding Acknowledgement or the timeout period reaches the value 3480 MAX_BINDACK_TIMEOUT. 3482 10.10. Rate Limiting for Sending Binding Updates 3484 A mobile node MUST NOT send Binding Updates more often than once per 3485 MAX_UPDATE_RATE seconds to any node. After sending MAX_FAST_UPDATES 3486 consecutive Binding Updates to a particular node with the same 3487 care-of address, the mobile node SHOULD reduce its rate of sending 3488 Binding Updates to that node, to the rate of SLOW_UPDATE_RATE per 3489 second. The mobile node MAY continue to send Binding Updates at this 3490 slower rate indefinitely, in hopes that the node will eventually 3491 be able to process a Binding Update and begin to route its packets 3492 directly to the mobile node at its new care-of address. 3494 10.11. Receiving Binding Acknowledgements 3496 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 3497 node MUST validate the packet according to the following tests: 3499 - The packet contains a valid AH [8] or ESP [9] header providing 3500 sender authentication, data integrity protection, and replay 3501 protection. 3503 - The Option Length field in the option is greater than or equal to 3504 11 octets. 3506 - The Sequence Number field matches the Sequence Number sent by the 3507 mobile node to this destination address in an outstanding Binding 3508 Update. 3510 Any Binding Acknowledgement not satisfying all of these tests MUST be 3511 silently ignored, although the remainder of the packet (i.e., other 3512 options, extension headers, or payload) SHOULD be processed normally 3513 according to any procedure defined for that part of the packet. 3515 When a mobile node receives a packet carrying a valid Binding 3516 Acknowledgement, the mobile node MUST examine the Status field as 3517 follows: 3519 - If the Status field indicates that the Binding Update was 3520 accepted (the Status field is less than 128), then the mobile 3521 node MUST update the corresponding entry in its Binding Update 3522 List to indicate that the Binding Update has been acknowledged. 3523 The mobile node MUST then stop retransmitting the Binding Update. 3525 - If the Status field indicates that the Binding Update was 3526 rejected (the Status field is greater than or equal to 128), then 3527 the mobile node MUST delete the corresponding Binding Update List 3528 entry (and MUST also stop retransmitting the Binding Update). 3529 Optionally, the mobile node MAY then take steps to correct the 3530 cause of the error and retransmit the Binding Update (with a new 3531 Sequence Number value), subject to the rate limiting restriction 3532 specified in Section 10.10. In particular, if the Status field 3533 is equal to 135 (dynamic home agent address discovery response), 3534 then the mobile node MAY reattempt its home registration with 3535 the home agent address given in the Source Address field of the 3536 packet carrying the Binding Acknowledgement or with any of the 3537 home agent IP addresses listed in the Home Agents List Sub-Option 3538 in the Binding Acknowledgement. If any of these addresses is not 3539 a global unicast address or does not have a subnet prefix equal 3540 to the mobile node's own subnet prefix, then that particular 3541 address MUST be ignored and the mobile node MUST NOT reattempt 3542 its home registration with that home agent. 3544 10.12. Receiving Binding Requests 3546 When a mobile node receives a packet containing a Binding Request, 3547 it SHOULD return to the sender a packet containing a Binding Update. 3548 The Lifetime field in this Binding Update SHOULD be set to a new 3549 lifetime, extending any current lifetime remaining from a previous 3550 Binding Update sent to this node (as indicated in any existing 3551 Binding Update List entry for this node), except that this lifetime 3552 MUST NOT exceed the remaining lifetime for the mobile node's primary 3553 care-of address registration at its home agent. When sending this 3554 Binding Update, the mobile node MUST update its Binding Update List 3555 in the same way as for any other Binding Update sent by the mobile 3556 node. 3558 Note, however, that the mobile node MAY choose to keep its current 3559 binding private from the sender of the Binding Request. In this 3560 case, the mobile node instead SHOULD returns a Binding Update to the 3561 sender, in which the Lifetime field is set to zero and the care-of 3562 address is set to the mobile node's home address. 3564 If the Binding Request for which the Binding Update is being returned 3565 contains a Unique Identifer Sub-Option, the Binding Update MUST also 3566 include a Unique Identifier Sub-Option. The unique identifier in the 3567 SUb-Option Data field of the Unique Identifier Sub-Option MUST be 3568 copied from the unique identifier carried in the Binding Request. 3570 10.13. Receiving ICMP Error Messages 3572 The Option Type value for a Binding Update option specifies that 3573 any node receiving this option that does not recognize the Option 3574 Type SHOULD return an ICMP Parameter Problem, Code 2, message to 3575 the sender of the packet containing the Binding Update option. If 3576 a node sending a Binding Update receives such an ICMP error message 3577 in response, it should record in its Binding Update List that future 3578 Binding Updates should not be sent to this destination. 3580 Likewise, although ALL IPv6 nodes (whether host or router, whether 3581 mobile or stationary) MUST implement the ability to correctly process 3582 received packets containing a Home Address option, all Option Type 3583 values in IPv6 include a specification of the behavior that a node 3584 receiving a packet containing this option performs if it does not 3585 implement receipt of that type of option. For the Home Address 3586 option, the Option Type value specifies that any node receiving 3587 this option that does not recognize the Option Type SHOULD return 3588 an ICMP Parameter Problem, Code 2, message to the sender of the 3589 packet containing the Home Address option. If a mobile node receives 3590 such an ICMP error message from some node indicating that it does 3591 not recognize the mobile node's Home Address option, the mobile 3592 node SHOULD log the error and then discard the ICMP message; this 3593 error message indicates that the node to which the original packet 3594 was addressed (the node returning the ICMP error message) does not 3595 correctly implement this required part of the IPv6 protocol. 3597 10.14. Receiving Tunneled Router Advertisements 3599 Section 9.7 describes the operation of a home agent to support 3600 renumbering a mobile node's home subnet while the mobile node is 3601 away from home. The home agent tunnels certain Router Advertisement 3602 messages to the mobile node while away from home, giving "important" 3603 Prefix Information options that describe changes in the prefixes in 3604 use on the mobile node's home link. 3606 When a mobile node receives a tunneled Router Advertisement, it MUST 3607 validate it according to the following tests: 3609 - The Source Address of the IP packet carrying the Router 3610 Advertisement is the same as the home agent address to which the 3611 mobile node last sent an accepted "home registration" Binding 3612 Update to register its primary care-of address. 3614 - The packet contains either an AH [8] or ESP [9] header providing 3615 sender authentication, data integrity protection, and replay 3616 protection. 3618 - The packet contains a Binding Request destination option. 3620 - The Binding Request option contains a Unique Identifier 3621 Sub-Option. 3623 Any received tunneled Router Advertisement not meeting all of these 3624 tests MUST be silently discarded. 3626 If a received tunneled Router Advertisement is not discarded 3627 according to the tests listed above, the mobile node MUST process the 3628 Router Advertisement as if it were connected to its home link [13]. 3629 Such processing MAY result in the mobile node configuring a new home 3630 address, although due to separation between preferred lifetime and 3631 valid lifetime, such changes should not affect most communication by 3632 the mobile node, in the same way as for nodes that are at home. 3634 In addition, in processing the packet containing this Router 3635 Advertisement, the mobile node SHOULD return to the home agent a 3636 Binding Update in response to the Binding Request carried in the 3637 packet. The correct formation of this Binding Update by the mobile 3638 node and processing of it by the home agent will be viewed by the 3639 home agent as an acknowledgement of this Router Advertisement, 3640 confirming to it that this Router Advertisement was received by the 3641 mobile node. 3643 10.15. Using Multiple Care-of Addresses 3645 As described in Section 10.4, a mobile node MAY use more than one 3646 care-of address at a time. Particularly in the case of many wireless 3647 networks, a mobile node effectively might be reachable through 3648 multiple links at the same time (e.g., with overlapping wireless 3649 cells), on which different on-link subnet prefixes may exist. A 3650 mobile node SHOULD select a primary care-of address from among those 3651 care-of addresses it has formed using any of these subnet prefixes, 3652 based on the movement detection mechanism in use, as described in 3653 Section 10.3. When the mobile node selects a new primary care-of 3654 address, it MUST register it with its home agent by sending it a 3655 Binding Update with the Home Registration (H) and Acknowledge (A) 3656 bits set, as described in Section 10.5. 3658 To assist with smooth handoffs, a mobile node SHOULD retain 3659 its previous primary care-of address as a (non-primary) care-of 3660 address, and SHOULD still accept packets at this address, even after 3661 registering its new primary care-of address with its home agent. 3662 This is reasonable, since the mobile node could only receive packets 3663 at its previous primary care-of address if it were indeed still 3664 connected to that link. If the previous primary care-of address was 3665 allocated using stateful address autoconfiguration [2], the mobile 3666 node may not wish to release the address immediately upon switching 3667 to a new primary care-of address. 3669 10.16. Routing Multicast Packets 3671 A mobile node that is connected to its home link functions in the 3672 same way as any other (stationary) node. Thus, when it is at home, 3673 a mobile node functions identically to other multicast senders and 3674 receivers. This section therefore describes the behavior of a mobile 3675 node that is not on its home link. 3677 In order to receive packets sent to some multicast group, a mobile 3678 node must join that multicast group. One method by which a mobile 3679 node MAY join the group is via a (local) multicast router on the 3680 foreign link being visited. The mobile node SHOULD use its care-of 3681 address sharing a subnet prefix with the multicast router, as 3682 the source IPv6 address of its multicast group membership control 3683 messages. 3685 Alternatively, a mobile node MAY join multicast groups via a 3686 bi-directional tunnel to its home agent. The mobile node tunnels its 3687 multicast group membership control packets to its home agent, and the 3688 home agent forwards multicast packets down the tunnel to the mobile 3689 node. 3691 A mobile node that wishes to send packets to a multicast group 3692 also has two options: (1) send directly on the foreign link being 3693 visited; or (2) send via a tunnel to its home agent. Because 3694 multicast routing in general depends upon the Source Address used in 3695 the IPv6 header of the multicast packet, a mobile node that tunnels a 3696 multicast packet to its home agent MUST use its home address as the 3697 IPv6 Source Address of the inner multicast packet. 3699 10.17. Returning Home 3701 A mobile node detects that it has returned to its home link through 3702 the movement detection algorithm in use (Section 10.3), when the 3703 mobile node detects that its home subnet prefix is again on-link. 3704 The mobile node SHOULD then send a Binding Update to its home agent, 3705 to instruct its home agent to no longer intercept or tunnel packets 3706 for it. In this Binding Update, the mobile node MUST set the care-of 3707 address for the binding (the Source Address field in the packet's 3708 IPv6 header) to the mobile node's own home address. As with other 3709 Binding Updates sent to register with its home agent, the mobile 3710 node MUST set the Acknowledge (A) and Home Registration (H) bits, 3711 and SHOULD retransmit the Binding Update until a matching Binding 3712 Acknowledgement is received. 3714 In addition, the mobile node MUST multicast onto the home link 3715 (to the all-nodes multicast address) a Neighbor Advertisement 3716 message [13], to advertise the mobile node's own link-layer address 3717 for its own home address. The Target Address in this Neighbor 3718 Advertisement message MUST be set to the mobile node's home address, 3719 and the Advertisement MUST include a Target Link-layer Address option 3720 specifying the mobile node's link-layer address. The mobile node 3721 MUST multicast such a Neighbor Advertisement message for each of its 3722 home addresses, as defined by the current on-link prefixes, including 3723 its link-local address and site-local address. The Solicited 3724 Flag (S) in these Advertisements MUST NOT be set, since they were 3725 not solicited by any Neighbor Solicitation message. The Override 3726 Flag (O) in these Advertisements MUST be set, indicating that the 3727 Advertisements SHOULD override any existing Neighbor Cache entries at 3728 any node receiving them. 3730 Since multicasts on the local link (such as Ethernet) are typically 3731 not guaranteed to be reliable, the mobile node MAY retransmit these 3732 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 3733 increase their reliability. It is still possible that some nodes on 3734 the home link will not receive any of these Neighbor Advertisements, 3735 but these nodes will eventually be able to recover through use of 3736 Neighbor Unreachability Detection [13]. 3738 11. Constants 3740 INITIAL_BINDACK_TIMEOUT 1 second 3742 MAX_BINDACK_TIMEOUT 256 seconds 3744 MAX_UPDATE_RATE once per second 3746 SLOW_UPDATE_RATE once per 10 seconds 3748 MAX_FAST_UPDATES 5 transmissions 3750 MAX_ADVERT_REXMIT 3 transmissions 3752 12. IANA Considerations 3754 This document defines four new types of IPv6 destination options, 3755 each of which must be assigned an Option Type value: 3757 - The Binding Update option, described in Section 5.1 3759 - The Binding Acknowledgement option, described in Section 5.2 3761 - The Binding Request option, described in Section 5.3 3763 - The Home Address option, described in Section 5.4 3765 In addition, this document defines two new Neighbor Discovery [13] 3766 options, which must be assigned Option Type values within the option 3767 numbering space for Neighbor Discovery messages: 3769 - The Advertisement Interval option, described in Section 6.3. 3771 - The Home Agent Information option, described in Section 6.4. 3773 Finally, this document defines a new type of anycast address, which 3774 must be assigned a reserved value for use with any subnet prefix to 3775 define this anycast address on each subnet: 3777 - The Home-Agents anycast address, used in the dynamic home agent 3778 address discovery procedure described in Sections 9.2 and 10.6. 3780 13. Security Considerations 3782 13.1. Binding Updates, Acknowledgements, and Requests 3784 The Binding Update option described in this document will result 3785 in packets addressed to a mobile node being delivered instead to 3786 its care-of address. This ability to change the routing of these 3787 packets could be a significant vulnerability if any packet containing 3788 a Binding Update option was not authenticated. Such use of "remote 3789 redirection", for instance as performed by the Binding Update option, 3790 is widely understood to be a security problem in the current Internet 3791 if not authenticated [1]. 3793 The Binding Acknowledgement option also requires authentication, 3794 since, for example, an attacker could otherwise trick a mobile node 3795 into believing a different outcome from a registration attempt with 3796 its home agent. 3798 No authentication is required for the Binding Request option, since 3799 the use of this option does not modify or create any state in either 3800 the sender or the receiver. The Binding Request option does open 3801 some issues with binding privacy, but those issues can be dealt with 3802 either through existing IPsec encryption mechanisms or through use of 3803 firewalls. 3805 The existing IPsec replay protection mechanisms allow a "replay 3806 protection window" to support receiving packets out of order. 3807 Although appropriate for many forms of communication, Binding Updates 3808 MUST be applied only in the order sent. The Binding Update option 3809 thus includes a Sequence Number field to provide this necessary 3810 sequencing. The use of this Sequence Number together with IPsec 3811 replay protection is similar in many ways, for example, to the the 3812 sequence number in TCP. IPsec provides strong replay protection but 3813 no ordering, and the sequence number provides ordering but need not 3814 worry about replay protection such as through the sequence number 3815 wrapping around. 3817 13.2. Home Address Option 3819 No special authentication of the Home Address option is required, 3820 except that if the IPv6 header of a packet is covered by 3821 authentication, then that authentication MUST also cover the Home 3822 Address option; this coverage is achieved automatically by the 3823 definition of the Option Type code for the Home Address option 3824 (Section 5.4), since it indicates that the option is included in the 3825 authentication computation. Thus, even when authentication is used 3826 in the IPv6 header, the security of the Source Address field in the 3827 IPv6 header is not compromised by the presence of a Home Address 3828 option. Without authentication of the packet, then any field in the 3829 IPv6 header, including the Source Address field, and any other parts 3830 of the packet, including the Home Address option, can be forged or 3831 modified in transit. In this case, the contents of the Home Address 3832 option is no more suspect than any other part of the packet. 3834 The use of the Home Address option allows packets sent by a 3835 mobile node to pass normally through routers implementing ingress 3836 filtering [6]. Since the care-of address used in the Source Address 3837 field of the packet's IPv6 header is topologically correct for the 3838 sending location of the mobile node, ingress filtering can trace the 3839 location of the mobile node in the same way as can be done with any 3840 sender when ingress filtering is in use. 3842 However, if a node receiving a packet that includes a Home Address 3843 option implements the processing of this option by physically 3844 copying the Home Address field from the option into the IPv6 header, 3845 replacing the Source Address field there, then the ability to 3846 trace the true location of the sender is removed once this step 3847 in the processing is performed. This diminishing of the power of 3848 ingress filtering only occurs once the packet has been received at 3849 its ultimate destination, and does not affect the capability of 3850 ingress filtering while the packet is in transit. Furthermore, this 3851 diminishing can be entirely eliminated by appropriate implementation 3852 techniques in the receiving node. For example, the original contents 3853 of the Source Address field (the sending care-of address) could be 3854 saved elsewhere in memory with the packet, until all processing of 3855 the packet is completed. 3857 13.3. General Mobile Computing Issues 3859 The mobile computing environment is potentially very different from 3860 the ordinary computing environment. In many cases, mobile computers 3861 will be connected to the network via wireless links. Such links 3862 are particularly vulnerable to passive eavesdropping, active replay 3863 attacks, and other active attacks. Furthermore, mobile computers 3864 are more susceptible to loss or theft than stationary computers. 3865 Any secrets such as authentication or encryption keys stored on the 3866 mobile computer are thus subject to compromise in ways generally not 3867 common in the non-mobile environment. 3869 Users who have sensitive data that they do not wish others to have 3870 access to should use additional mechanisms (such as encryption) to 3871 provide privacy protection, but such mechanisms are beyond the scope 3872 of this document. Users concerned about traffic analysis should 3873 consider appropriate use of link encryption. If stronger location 3874 privacy is desired, the mobile node can create a tunnel to its home 3875 agent. Then, packets destined for correspondent nodes will appear 3876 to emanate from the home subnet, and it may be more difficult to 3877 pinpoint the location of the mobile node. Such mechanisms are all 3878 beyond the scope of this document. 3880 Changes from Previous Draft 3882 This appendix briefly lists some of the major changes in this 3883 draft relative to the previous version of this same draft, 3884 draft-ietf-mobileip-ipv6-06.txt: 3886 - Changed the way in which optional information is included in 3887 Mobile IPv6 destination options. In pervious versions of this 3888 draft, optional data was in an unspecified format (except for 3889 the Home Agents List in a Binding Acknowledgement, which was 3890 a simple list of IP addresses). Instead, such optional data 3891 is now specified as sub-options within the option data field, 3892 encoded in type-length-value (TLV) format. Added Section 5.5 3893 to define the general format of sub-options and to specify the 3894 sub-option data format for each defined sub-option, and updated 3895 relevant references to such optional information throughout 3896 the draft. This new TLV encoding of optional information 3897 allows much more flexibility in future versions of the protocol 3898 specification, and solves the problem that the previous encoding 3899 of the Home Agents List in a Binding Acknowledgement prevented 3900 other optional information from also being included in a Binding 3901 Acknowledgement. 3903 - Specified in Section 9.2 that a home agent returning a Binding 3904 Acknowledgement containing a Home Agents List Sub-Option SHOULD 3905 limit the size of the list so as to avoid the possibility of the 3906 packet carrying the Binding Acknowledgement being fragmented. 3908 - Specified in Section 4.3 that each Home Agents List entry 3909 represents a single home agent by its link-local address 3910 (the Source Address used in its Router Advertisements), 3911 and contains one or more global IP addresses for this home 3912 agent, learned through Prefix Information options received 3913 in Router Advertisements from this link-local address, in 3914 which the Router Address (R) bit is set. Also specified in 3915 Section ha-advert how to add global addresses to this list of 3916 global addresses associated with a home agent in the Home Agents 3917 List. 3919 - Specified in Section 9.2 that in forming the Home Agents 3920 List Sub-Option to return to a mobile node in a Binding 3921 Acknowledgement, only home agent global IP addresses sharing a 3922 prefix with the mobile node's home address are returned in the 3923 Binding Acknowledgement. 3925 - Specified in Section 8 that in processing a Home Address option 3926 in a received packet, any actual modifications to the Source 3927 Address field in the packet's IPv6 header MUST not be performed 3928 until after all processing of other options contained in this 3929 same Destination Options extension header is completed. This 3930 restriction prevents confusion in the meaning of these other 3931 destination options. 3933 - General clarification and correction of minor typographical 3934 errors throughout. 3936 Acknowledgements 3938 We would like to thank the members of the Mobile IP and IPng Working 3939 Groups for their comments and suggestions on this work. We would 3940 particularly like to thank (in alphabetical order) Josh Broch 3941 (Carnegie Mellon University), Thomas Narten (IBM), Erik Nordmark (Sun 3942 Microsystems), Simon Nybroe (Telebit Communications), Patrice Romand 3943 (Bull S.A.), Tom Soderlund (Nokia Research), and Jim Solomon (RedBack 3944 Networks) for their detailed reviews of earlier versions of this 3945 draft. Their suggestions have helped to improve both the design and 3946 presentation of the protocol. 3948 References 3950 [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 3951 ACM Computer Communications Review, 19(2), March 1989. 3953 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 3954 Protocol for IPv6 (DHCPv6). Internet-Draft, 3955 draft-ietf-dhc-dhcpv6-10.txt, May 1997. Work in progress. 3957 [3] Scott Bradner. Key words for use in RFCs to indicate 3958 requirement levels. RFC 2119, March 1997. 3960 [4] Alex Conta and Stephen Deering. Generic packet 3961 tunneling in IPv6 specification. Internet-Draft, 3962 draft-ietf-ipngwg-ipv6-tunnel-07.txt, December 1996. 3963 Work in progress. 3965 [5] Stephen E. Deering and Robert M. Hinden. Internet 3966 Protocol version 6 (IPv6) specification. Internet-Draft, 3967 draft-ietf-ipngwg-ipv6-spec-v2-00.txt, July 1997. Work in 3968 progress. 3970 [6] Paul Ferguson and Daniel Senie. Network ingress filtering: 3971 Defeating denial of service attacks which employ IP source 3972 address spoofing. RFC 2267, January 1998. 3974 [7] Robert M. Hinden and Stephen E. Deering. IP Version 6 3975 addressing architecture. Internet-Draft, 3976 draft-ietf-ipngwg-addr-arch-v2-06.txt, January 1998. Work in 3977 progress. 3979 [8] Stephen Kent and Randall Atkinson. IP Authentication header. 3980 Internet-Draft, draft-ietf-ipsec-auth-header-02.txt, October 3981 1997. Work in progress. 3983 [9] Stephen Kent and Randall Atkinson. IP Encapsulating Security 3984 Payload (ESP). Internet-Draft, draft-ietf-ipsec-esp-v2-01.txt, 3985 October 1997. Work in progress. 3987 [10] Stephen Kent and Randall Atkinson. Security architecture for 3988 the Internet Protocol. Internet-Draft, 3989 draft-ietf-ipsec-arch-sec-02.txt, November 1997. Work in 3990 progress. 3992 [11] P. Mockapetris. Domain Names -- concepts and facilities. 3993 RFC 1034, November 1987. 3995 [12] P. Mockapetris. Domain Names -- implementation and 3996 specification. RFC 1035, November 1987. 3998 [13] Thomas Narten, Erik Nordmark, and William Allen Simpson. 3999 Neighbor Discovery for IP version 6 (IPv6). Internet-Draft, 4000 draft-ietf-ipngwg-discovery-v2-00.txt, July 1997. Work in 4001 progress. 4003 [14] Charles Perkins. IP encapsulation within IP. RFC 2003, October 4004 1996. 4006 [15] Charles Perkins, editor. IP mobility support. RFC 2002, 4007 October 1996. 4009 [16] Charles Perkins. Minimal encapsulation within IP. RFC 2004, 4010 October 1996. 4012 [17] Charles Perkins and David B. Johnson. Route optimization in 4013 Mobile IP. Internet-Draft, draft-ietf-mobileip-optim-07.txt, 4014 November 1997. Work in progress. 4016 [18] David C. Plummer. An Ethernet address resolution protocol: 4017 Or converting network protocol addresses to 48.bit Ethernet 4018 addresses for transmission on Ethernet hardware. RFC 826, 4019 November 1982. 4021 [19] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 4023 [20] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 4024 September 1981. 4026 [21] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 4027 October 1994. 4029 [22] Susan Thomson and Thomas Narten. IPv6 stateless address 4030 autoconfiguration. Internet-Draft, 4031 draft-ietf-ipngwg-addrconf-v2-00.txt, July 1997. 4033 Chair's Address 4035 The Working Group can be contacted via its current chairs: 4037 Jim Solomon 4038 RedBack Networks 4039 1389 Moffett Park Drive 4040 Sunnyvale, CA 94089-1134 4041 USA 4043 Phone: +1 408 548-3583 4044 Fax: +1 408 548-3599 4045 E-mail: solomon@rback.com 4047 Erik Nordmark 4048 Sun Microsystems, Inc. 4049 2550 Garcia Avenue 4050 Mt. View, CA 94041 4051 USA 4053 Phone: +1 415 786-5166 4054 Fax: +1 415 786-5896 4055 E-mail: nordmark@sun.com 4057 Authors' Addresses 4059 Questions about this document can also be directed to the authors: 4061 David B. Johnson 4062 Carnegie Mellon University 4063 Computer Science Department 4064 5000 Forbes Avenue 4065 Pittsburgh, PA 15213-3891 4066 USA 4068 Phone: +1 412 268-7399 4069 Fax: +1 412 268-5576 4070 E-mail: dbj@cs.cmu.edu 4072 Charles Perkins 4073 Sun Microsystems, Inc. 4074 Technology Development Group 4075 Mail Stop MPK15-214 4076 Room 2682 4077 901 San Antonio Road 4078 Palo Alto, CA 94303 4079 USA 4081 Phone: +1 415 786-6464 4082 Fax: +1 415 786-6445 4083 E-mail: cperkins@eng.sun.com