idnits 2.17.1 draft-ietf-mobileip-ipv6-03.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-04-20) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 279: '... MUST...' RFC 2119 keyword, line 284: '... MUST NOT...' RFC 2119 keyword, line 289: '... SHOULD...' RFC 2119 keyword, line 296: '... SHOULD NOT...' RFC 2119 keyword, line 304: '... MAY...' (222 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (30 July 1997) is 9761 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) ** Obsolete normative reference: RFC 1826 (ref. '1') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-10 ** Obsolete normative reference: RFC 1883 (ref. '5') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1970 (ref. '9') (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 2002 (ref. '11') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 793 (ref. '14') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '15') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1971 (ref. '16') (Obsoleted by RFC 2462) Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group David B. Johnson 2 INTERNET-DRAFT Carnegie Mellon University 3 Charles Perkins 4 Sun Microsystems 5 30 July 1997 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 (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document specifies the operation of mobile computers using IPv6. 37 Each mobile node is always identified by its home address, regardless 38 of its current point of attachment to the Internet. While situated 39 away from its home, a mobile node is also associated with a care-of 40 address, which provides information about the mobile node's current 41 location. IPv6 packets addressed to a mobile node's home address are 42 transparently routed to its care-of address. The protocol enables 43 IPv6 nodes to cache the binding of a mobile node's home address with 44 its care-of address, and to then send packets destined for the mobile 45 node directly to it at this care-of address. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Terminology 2 56 2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 2 57 2.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 3 58 2.3. Specification Language . . . . . . . . . . . . . . . . . 4 60 3. Overview of Mobile IPv6 Operation 6 61 3.1. Protocol Summary . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . 11 64 4. New IPv6 Destination Options 12 65 4.1. Binding Update Option . . . . . . . . . . . . . . . . . . 12 66 4.2. Binding Acknowledgement Option . . . . . . . . . . . . . 16 67 4.3. Binding Request Option . . . . . . . . . . . . . . . . . 20 68 4.4. Home Address Option . . . . . . . . . . . . . . . . . . . 21 70 5. Requirements for IPv6 Nodes 23 72 6. Correspondent Node Operation 25 73 6.1. Receiving Packets from a Mobile Node . . . . . . . . . . 25 74 6.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 25 75 6.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 26 76 6.4. Requests to Delete a Binding . . . . . . . . . . . . . . 27 77 6.5. Sending Binding Acknowledgements . . . . . . . . . . . . 27 78 6.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 28 79 6.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 28 80 6.8. Sending Packets to a Mobile Node . . . . . . . . . . . . 29 82 7. Home Agent Operation 31 83 7.1. Dynamic Home Agent Address Discovery . . . . . . . . . . 31 84 7.2. Primary Care-of Address Registration . . . . . . . . . . 31 85 7.3. Primary Care-of Address De-registration . . . . . . . . . 33 86 7.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 34 87 7.5. Renumbering the Home Subnet . . . . . . . . . . . . . . . 35 89 8. Mobile Node Operation 37 90 8.1. Sending Packets While Away from Home . . . . . . . . . . 37 91 8.2. Movement Detection . . . . . . . . . . . . . . . . . . . 38 92 8.3. Forming New Care-of Addresses . . . . . . . . . . . . . . 40 93 8.4. Sending Binding Updates to the Home Agent . . . . . . . . 41 94 8.5. Sending Binding Updates to Correspondent Nodes . . . . . 42 95 8.6. Sending Binding Updates to the Previous Default Router . 45 96 8.7. Retransmitting Binding Updates . . . . . . . . . . . . . 45 97 8.8. Rate Limiting for Sending Binding Updates . . . . . . . . 46 98 8.9. Receiving Binding Acknowledgements . . . . . . . . . . . 46 99 8.10. Using Multiple Care-of Addresses . . . . . . . . . . . . 47 100 8.11. Returning Home . . . . . . . . . . . . . . . . . . . . . 47 102 9. Routing Multicast Packets 49 104 10. Constants 50 106 11. Security Considerations 51 107 11.1. Binding Updates, Acknowledgements, and Requests . . . . . 51 108 11.2. Home Address Options . . . . . . . . . . . . . . . . . . 51 109 11.3. General Mobile Computing Issues . . . . . . . . . . . . . 52 111 Appendix A. Changes from Previous Draft 53 113 Acknowledgements 54 115 References 55 117 Chair's Address 57 119 Authors' Addresses 58 120 1. Introduction 122 This document specifies the operation of mobile computers using 123 Internet Protocol Version 6 (IPv6) [5]. Without specific support for 124 mobility in IPv6, packets destined to a mobile node (host or router) 125 would not be able to reach it while the mobile node is away from its 126 home IPv6 subnet, since routing is based on the network prefix in a 127 packet's destination IP address. In order continue communication 128 in spite of its movement, a mobile node could change its IP address 129 each time it moves to a new IPv6 subnet, but the mobile node would 130 then not be able to maintain transport and higher-layer connections 131 when it changes location. Mobility support in IPv6 is particularly 132 important, as mobile computers are likely to account for a majority 133 or at least a substantial fraction of the population of the Internet 134 during the lifetime of IPv6. 136 The protocol operation defined here, known as Mobile IPv6, allows a 137 mobile node to move from one IPv6 subnet to another without changing 138 the mobile node's IP address. A mobile node is always addressable 139 by its "home address", the IP address assigned to the mobile node 140 within its home IPv6 subnet. Packets may be routed to the mobile 141 node using this address regardless of the mobile node's current point 142 of attachment to the Internet, and the mobile node may continue to 143 communicate with other nodes (stationary or mobile) after moving 144 to a new subnet. The movement of a mobile node away from its home 145 subnet is thus transparent to transport and higher-layer protocols 146 and applications. 148 The Mobile IPv6 protocol is just as suitable for mobility across 149 homogeneous media as for mobility across heterogeneous media. For 150 example, Mobile IPv6 facilitates node movement from one Ethernet 151 segment to another as well as it facilitates node movement from an 152 Ethernet segment to a wireless LAN cell, with the mobile node's IP 153 address remaining unchanged in spite of such movement. 155 One can think of the Mobile IPv6 protocol as solving the "macro" 156 mobility management problem. More "micro" mobility management 157 applications -- for example, handoff amongst wireless transceivers, 158 each of which covers only a very small geographic area -- are 159 possibly more suited to other solutions. For example, as long as 160 node movement does not occur between link-level points of attachment 161 on different IPv6 subnets, link-layer mobility support offered by a 162 number of current wireless LAN products is likely to offer faster 163 convergence and lower overhead than Mobile IPv6. Extensions to the 164 Mobile IPv6 protocol are also possible to support a more local, 165 hierarchical form of handoff, but such extensions are beyond the sope 166 of this document. 168 2. Terminology 170 2.1. General Terms 172 IP 174 Internet Protocol Version 6 (IPv6). 176 node 178 A device that implements IP. 180 router 182 A node that forwards IP packets not explicitly addressed to 183 itself. 185 host 187 Any node that is not a router. 189 link 191 A communication facility or medium over which nodes can 192 communicate at the link layer, such as an Ethernet (simple or 193 bridged). A link is the layer immediately below IP. 195 interface 197 A node's attachment to a link. 199 network prefix 201 A bit string that consists of some number of initial bits of an 202 IP address. 204 link-layer address 206 A link-layer identifier for an interface, such as IEEE 802 207 addresses on Ethernet links. 209 packet 211 An IP header plus payload. 213 2.2. Mobile IPv6 Terms 215 home address 217 An IP address assigned to a mobile node within its home subnet. 218 The network prefix in a mobile node's home address is equal to 219 the network prefix of the home subnet. 221 home subnet 223 The IP subnet indicated by a mobile node's home address. 224 Standard IP routing mechanisms will deliver packets destined 225 for a mobile node's home address to its home subnet. 227 mobile node 229 A node that can change its link-level point of attachment from 230 one IP subnet to another, while still being reachable via its 231 home address. 233 movement 235 A change in a mobile node's point of attachment to the Internet 236 such that it is no longer link-level connected to the same IP 237 subnet as it was previously. If a mobile node is not currently 238 link-level connected to its home subnet, the mobile node is 239 said to be "away from home". 241 correspondent node 243 A peer node with which a mobile node is communicating. The 244 correspondent node may be either mobile or stationary. 246 foreign subnet 248 Any IP subnet other than the mobile node's home subnet. 250 home agent 252 A router on a mobile node's home subnet with which the mobile 253 node has registered its current care-of address. While the 254 mobile node is away from home, the home agent intercepts 255 packets on the home subnet destined to the mobile node's home 256 address, encapsulates them, and tunnels them to the mobile 257 node's registered care-of address. 259 care-of address 261 An IP address associated with a mobile node while visiting 262 a foreign subnet, which uses the network prefix of that 263 foreign subnet. Among the multiple care-of addresses that a 264 mobile node may have at a time (e.g., with different network 265 prefixes), the one registered with the mobile node's home agent 266 is called its "primary" care-of address. 268 binding 270 The association of the home address of a mobile node with a 271 care-of address for that mobile node, along with the remaining 272 lifetime of that association. 274 2.3. Specification Language 276 In this document, several words are used to signify the requirements 277 of the specification. These words are often capitalized. 279 MUST 281 This word, or the adjective "REQUIRED", means that the 282 definition is an absolute requirement of the specification. 284 MUST NOT 286 This phrase means that the definition is an absolute 287 prohibition of the specification. 289 SHOULD 291 This word, or the adjective "RECOMMENDED", means that there may 292 exist valid reasons in particular circumstances to ignore a 293 particular item, but the full implications must be understood 294 and carefully weighed before choosing a different course. 296 SHOULD NOT 298 This phrase means that there may exist valid reasons in 299 particular circumstances when the particular behavior is 300 acceptable or even useful, but the full implications should be 301 understood and the case carefully weighed before implementing 302 any behavior described with this label. 304 MAY 306 This word, or the adjective "OPTIONAL", means that an item 307 is truly optional. For example, one vendor may choose to 308 include the item because a particular marketplace requires 309 it or because the vendor feels that it enhances the product, 310 while another vendor may omit the same item. An implementation 311 which does not include a particular option MUST be prepared to 312 interoperate with another implementation which does include the 313 option. 315 silently discard 317 The implementation discards the packet without further 318 processing, and without indicating an error to the sender. The 319 implementation SHOULD provide the capability of logging the 320 error, including the contents of the discarded packet, and 321 SHOULD record the event in a statistics counter. 323 3. Overview of Mobile IPv6 Operation 325 3.1. Protocol Summary 327 A mobile node is always addressable by its home address, whether it 328 is currently attached to its home subnet or is away from home. While 329 a mobile node is at home, packets addressed to the mobile node's 330 home address are routed to it using conventional Internet routing 331 mechanisms in the same way as if the node were never mobile. Since 332 the network prefix of a mobile node's home address is equal to the 333 network prefix of its home subnet, packets addressed to it will be 334 routed to its home subnet. 336 While a mobile node is attached to some foreign subnet away from 337 home, it is also addressable by one or more care-of addresses, in 338 addition to its home address. A care-of address is an IP address 339 associated with a mobile node while visiting a particular foreign 340 subnet. The network prefix of a mobile node's care-of address is 341 equal to the network prefix of the foreign subnet being visited 342 by the mobile node; if the mobile node is link-level connected 343 to this foreign subnet while using that care-of address, packets 344 addressed to this care-of address will be routed to the mobile node 345 in its location away from home. The association between a mobile 346 node's home address and care-of address is known as a "binding" 347 for the mobile node. A mobile node typically acquires its care-of 348 address through stateless [16] or stateful (e.g., DHCPv6 [3]) 349 address autoconfiguration, according to the methods of IPv6 Neighbor 350 Discovery [9], although other methods of acquiring a care-of address 351 are also possible. 353 While away from home, the mobile node registers one of its bindings 354 with a router in its home subnet, requesting this router to function 355 as the "home agent" for the mobile node. This binding registration 356 is done by the mobile node sending a packet with a "Binding Update" 357 destination option to the home agent, which replies by returning a 358 packet containing a "Binding Acknowledgement" destination option to 359 the mobile node. The care-of address in this binding registered 360 with its home agent is known as the mobile node's "primary care-of 361 address". The mobile node's home agent thereafter uses proxy 362 Neighbor Discovery to intercept any IPv6 packets addressed to the 363 mobile node's home address on the home subnet, and tunnels each 364 intercepted packet to the mobile node's primary care-of address. 365 To tunnel each intercepted packet, the home agent encapsulates the 366 packet using IPv6 encapsulation [4], addressed to the mobile node's 367 primary care-of address. 369 The Binding Update and Binding Acknowledgement destination options, 370 together with a "Binding Request" destination option, are also used 371 to allow IPv6 nodes communicating with a mobile node, to dynamically 372 learn and cache the mobile node's binding. When sending a packet 373 to any IPv6 destination, a node checks its cached bindings for an 374 entry for the packet's destination address. If a cached binding for 375 this destination address is found, the node uses an IPv6 Routing 376 header [5] (instead of IPv6 encapsulation) to route the packet to 377 the mobile node by way of the care-of address indicated in this 378 binding. If, instead, the sending node has no cached binding for 379 this destination address, the node sends the packet normally (with 380 no Routing header), and the packet is subsequently intercepted and 381 tunneled by the mobile node's home agent as described above. A node 382 communicating with a mobile node is referred to in this document as a 383 "correspondent node" of the mobile node. 385 Since a Binding Update, Binding Acknowledgement, and Binding Request 386 are each represented in a packet as an IPv6 destination option [5], 387 they may be included in any IPv6 packet. Any of these options can be 388 sent in either of two ways: 390 - A Binding Update, Binding Acknowledgement, or Binding Request can 391 be included within any IPv6 packet carrying any payload such as 392 TCP [14] or UDP [13]. 394 - A Binding Update, Binding Acknowledgement, or Binding Request can 395 be sent as a separate IPv6 packet containing no payload. In this 396 case, the Next Header field in the Destination Options header is 397 set to the value 59, to indicate "No Next Header" [5]. 399 Mobile IPv6 also defines one additional IPv6 destination option. 400 When a mobile node sends a packet while away from home, it will 401 generally set the Source Address in the packet's IPv6 header to one 402 of its current care-of addresses, and will also include a "Home 403 Address" destination option in the packet, giving the mobile node's 404 home address. Many routers implement security policies such as 405 "ingress filtering" [6] that do not allow forwarding of packets 406 that appear to have a Source Address that is not topologically 407 correct. By using the care-of address as the IPv6 header Source 408 Address, the packet will be able to pass normally through such 409 routers, yet ingress filtering rules will still be able to locate 410 the true physical source of the packet in the same way as packets 411 from non-mobile nodes. By also including the Home Address option, 412 the sending mobile node can communicate its home address to the 413 correspondent node receiving this packet, allowing the use of the 414 care-of address to be transparent above the Mobile IPv6 support 415 level (e.g., at the transport layer). The inclusion of a Home 416 Address option in a packet affects only the correspondent node's 417 receipt of this single packet; no state is created or modified in the 418 correspondent node as a result of receiving a Home Address option in 419 a packet. 421 In summary, the following four new IPv6 destination options are 422 defined for Mobile IPv6: 424 Binding Update 426 A Binding Update option is used by a mobile node to notify 427 a correspondent node or the mobile node's home agent of 428 its current binding. The Binding Update sent to the mobile 429 node's home agent to register its primary care-of address is 430 marked as a "home registration". Any packet that includes a 431 Binding Update option MUST also include an IPv6 Authentication 432 header [1], providing sender authentication, data integrity 433 protection, and replay protection. The Binding Update option 434 is described in detail in Section 4.1. 436 Binding Acknowledgement 438 A Binding Acknowledgement option is used to acknowledge receipt 439 of a Binding Update, if an acknowledgement was requested 440 in the Binding Update. Any packet that includes a Binding 441 Acknowledgement option MUST also include an IPv6 Authentication 442 header [1], providing sender authentication, data integrity 443 protection, and replay protection. The Binding Acknowledgement 444 option is described in detail in Section 4.2. 446 Binding Request 448 A Binding Request option is used to request a mobile node 449 to send a Binding Update to the requesting node, containing 450 the mobile node's current binding. This option is typically 451 used by a correspondent node to refresh a cached binding for 452 a mobile node, when the cached binding is in active use but 453 the binding's lifetime is close to expiration. No special 454 authentication is required for the Binding Request option. The 455 Binding Request option is described in detail in Section 4.3. 457 Home Address 459 A Home Address option is used in a packet sent by a mobile 460 node to inform the recipient of that packet of the mobile 461 node's home address. For packets sent by a mobile node while 462 away from home, the mobile node generally uses one of its 463 care-of addresses as the Source Address in the packet's IPv6 464 header. By including a Home Address option in the packet, the 465 correspondent node receiving the packet is able to substitute 466 the mobile node's home address for this care-of address when 467 processing the packet, thus making the use of the care-of 468 address transparent to the correspondent node. The Home 469 Address option is described in detail in Section 4.4. 471 Extensions to the format of these options may be included after the 472 fixed portion of the option data specified in this document. The 473 presence of such extensions will be indicated by the Option Length 474 field within the option. When the Option Length is greater than the 475 length required for the option specified here, the remaining octets 476 are interpreted as extensions. Currently, no extensions have been 477 defined. 479 This document describes the Mobile IPv6 protocol in terms of the 480 following two conceptual data structures used in the maintenance of 481 cached bindings: 483 Binding Cache 485 A cache, maintained by each IPv6 node, of bindings for other 486 nodes. An entry in a node's binding cache for which the node 487 is serving as a home agent is marked as a "home registration" 488 entry and SHOULD NOT be deleted by the home agent until the 489 expiration of its binding lifetime. Other Binding Cache 490 entries MAY be replaced at any time by any reasonable local 491 cache replacement policy but SHOULD NOT be unnecessarily 492 deleted. Any node's Binding Cache may contain at most one 493 entry for each mobile node, keyed by the mobile node's home 494 address. The contents of a node's Binding Cache MUST NOT be 495 changed in response to a Home Address option in a received 496 packet. The Binding Cache MAY be implemented in any manner 497 consistent with the external behavior described in this 498 document, for example by being combined with the node's 499 Destination Cache as maintained through Neighbor Discovery [9]. 501 Binding Update List 503 A list, maintained by each mobile node, recording information 504 for each Binding Update sent by this mobile node, for which the 505 Lifetime of the binding sent in that Binding Update has not 506 yet expired. The Binding Update List includes all bindings 507 sent by the mobile node: those to correspondent nodes, to the 508 mobile node's home agent, and to a previous default router 509 of the mobile node. Each Binding Update List entry records 510 the IP address of the node to which the Update was sent, the 511 home address for which one Binding Update was sent, and the 512 remaining lifetime of that binding. The Binding Update List 513 MAY be implemented in any manner consistent with the external 514 behavior described in this document. 516 When a mobile node configures a new care-of address and decides to 517 use this new address as its primary care-of address, the mobile 518 node registers this new binding with its home agent by sending 519 the home agent a Binding Update. The mobile node indicates 520 that an acknowledgement is needed for this Binding Update and 521 continues to periodically retransmit it until acknowledged. The 522 home agent acknowledges the Binding Update by returning a Binding 523 Acknowledgement to the mobile node. 525 When a mobile node receives a packet tunneled to it from its 526 home agent, the mobile node assumes that the original sending 527 correspondent node has no binding cache entry for the mobile node, 528 since the correspondent node would otherwise have sent the packet 529 directly to the mobile node using a Routing header. The mobile node 530 thus returns a Binding Update to the correspondent node, allowing 531 it to cache the mobile node's binding for routing future packets. 532 Although the mobile node may request an acknowledgement for this 533 Binding Update, it need not, since subsequent packets from the 534 correspondent node will continue to be intercepted and tunneled by 535 the mobile node's home agent, effectively causing any needed Binding 536 Update retransmission. 538 A correspondent node with a binding cache entry for a mobile node 539 may refresh this binding, for example if the binding's lifetime 540 is near expiration, by sending a Binding Request to the mobile 541 node. Normally, a correspondent node will only refresh a binding 542 cache entry in this way if it is actively communicating with the 543 mobile node and has indications, such as an open TCP connection to 544 the mobile node, that it will continue this communication in the 545 future. When a mobile node receives a Binding Request, it replies by 546 returning a Binding Update to the node sending the Binding Request. 548 A mobile node may use more than one care-of address at the same time, 549 although only one care-of address may be registered for it at its 550 home agent as its primary care-of address. The mobile node's home 551 agent will tunnel all intercepted packets for the mobile node to its 552 (single) registered primary care-of address, but the mobile node 553 will accept packets that it receives at any of its current care-of 554 addresses. Use of more than one care-of address by a mobile node may 555 be useful, for example, to improve smooth handoff when the mobile 556 node moves from one wireless IP subnet to another. If each wireless 557 subnet is connected to the Internet through a separate base station, 558 such that the wireless transmission range from the two base stations 559 overlap, the mobile node may be able to remain link-level connected 560 within both subnets while in the area of overlap. In this case, the 561 mobile node could acquire a new care-of address in the new subnet 562 before moving out of transmission range and link-level disconnecting 563 from the old subnet. The mobile node may thus still accept packets 564 at its old care-of address while it works to update its home agent 565 and correspondent nodes, notifying them of its new care-of address in 566 the new subnet. 568 Since correspondent nodes cache bindings, it is expected that 569 correspondent nodes usually will route packets directly to the mobile 570 node's care-of address, so that the home agent is rarely involved 571 with packet transmission to the mobile node. This is essential for 572 scalability and reliability, and for minimizing overall network load. 573 By caching the care-of address of a mobile node, optimal routing of 574 packets can be achieved from the correspondent node to the mobile 575 node. Routing packets directly to the mobile node's care-of address 576 also eliminates congestion at the mobile node's home agent and home 577 subnet. In addition, the impact of of any possible failure of the 578 home agent, the home subnet, or intervening networks leading to or 579 from the home subnet is reduced, since these nodes and links are not 580 involved in the delivery of most packets to the mobile node. 582 3.2. Comparison with Mobile IP for IPv4 584 [This section will include a comparison between the Mobile IPv6 585 protocol and the Mobile IPv4 protocol [11, 10, 12]. However, this 586 comparison has not yet been written. It will be filled in with the 587 next revsion to this draft.] 589 4. New IPv6 Destination Options 591 4.1. Binding Update Option 593 The Binding Update destination option is used by a mobile node to 594 notify a correspondent node or the mobile node's home agent of a new 595 care-of address. 597 The Binding Update option is encoded in type-length-value (TLV) 598 format as follows: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Option Type | Option Length |A|H|C|L| Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Lifetime | Sequence Number | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | | 608 + + 609 | | 610 + Care-of Address + 611 | (only present if C bit set) | 612 + + 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | | 616 + + 617 | | 618 + Home Link-Local Address + 619 | (only present if L bit set) | 620 + + 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Option Type 626 192 ??? 628 Option Length 630 8-bit unsigned integer. Length of the option, in octets, 631 excluding the Option Type and Option Length fields. For the 632 current definition of the Binding Update option, the minimum 633 value for this field is 6, for the case in which neither the 634 Care-of Address Present (C) bit nor the Home Link-Local Address 635 Present (L) bit are set, and the maximum value is 38, for the 636 case in which both of these bits are set. 638 Acknowledge (A) 640 The Acknowledge (A) bit is set by the sending node to request a 641 Binding Acknowledgement (Section 4.2) be returned upon receipt 642 of the Binding Update option. 644 Home Registration (H) 646 The Home Registration (H) bit is set by the sending node to 647 request the receiving node to act as this node's home agent. 648 The Destination Address in the IP header of the packet carrying 649 this option MUST be that of a router sharing the same network 650 prefix as the home address of the mobile node in the binding 651 (given by the Home Address field in the Home Address option in 652 the packet). 654 Care-of Address Present (C) 656 The Care-of Address Present (C) bit indicates the presence of 657 the Care-of Address field in the Binding Update. The care-of 658 address for this binding is either the address in the Care-of 659 Address field in the Binding Update, if this bit is set, or the 660 Source Address in the packet's IPv6 header, if this bit is not 661 set. 663 Home Link-Local Address Present (L) 665 The Home Link-Local Address Present (L) bit indicates the 666 presence of the Home Link-Local Address field in the Binding 667 Update. This bit is set by the sending node to request 668 the receiving node to act as a proxy (for participating in 669 the Neighbor Discovery Protocol) for the node while it is 670 away from home. This bit MUST NOT be set unless the Home 671 Registration (H) bit is also set in the Binding Update. 673 Reserved 675 Sent as 0; ignored on reception. 677 Lifetime 679 16-bit unsigned integer. The number of seconds remaining 680 before the binding must be considered expired. A value of all 681 ones (0xffff) indicates infinity. A value of zero indicates 682 that the Binding Cache entry for the mobile node should be 683 deleted. 685 Sequence Number 687 Used by the receiving node to sequence Binding Updates and by 688 the sending node to match a returned Binding Acknowledgement 689 with this Binding Update. Each Binding Update sent by a mobile 690 node MUST use a Sequence Number greater than the Sequence 691 Number value sent in the previous Binding Update (if any) to 692 the same destination address (modulo 2**16). There is no 693 requirement, however, that the Sequence Number value strictly 694 increase by 1 with each new Binding Update sent. 696 Care-of Address 698 This field in the Binding Update is optional and is only 699 present when the Care-of Address Present (L) bit is set. If 700 present, it gives the care-of address of the mobile node for 701 this binding. For most Binding Updates sent, it is expected 702 that this field will not be present, and instead that the 703 care-of address for the binding will be given by the Source 704 Address field in the packet's IPv6 header. 706 Home Link-Local Address 708 This field in the Binding Update is optional and is only 709 present when the Home Link-Local Address Present (L) bit is 710 set. If present, it gives the link-local address of the mobile 711 node used by the mobile node when it was last attached to its 712 home subnet. 714 Any packet including a Binding Update option MUST also include a Home 715 Address option. The home address of the mobile node in the binding 716 given in the Binding Update option is indicated by the Home Address 717 field in the Home Address option in the packet. 719 Any packet that includes a Binding Update option MUST include an IPv6 720 Authentication header [1] in order to protect against forged Binding 721 Updates. The authentication MUST provide sender authentication, data 722 integrity protection, and replay protection. 724 If the care-of address in the binding (either the Care-of Address 725 field in the Binding Update option or the Source Address field in 726 the packet's IPv6 header) is equal to the home address of the mobile 727 node, the Binding Update option indicates that any existing binding 728 for the mobile node should be deleted. Likewise, if the Lifetime 729 field in the Binding Update option is equal to 0, the Binding Update 730 option indicates that any existing binding for the mobile node should 731 be deleted. In each of these cases, no Binding Cache entry for the 732 mobile node should be created in response to receiving the Binding 733 Update. 735 The three highest-order bits of the Option Type are encoded to 736 indicate specific processing of the option [5]. For the Binding 737 Update option, these three bits are set to 110, indicating that the 738 data within the option cannot change en-route to the packet's final 739 destination, and that any IPv6 node processing this option that does 740 not recognize the Option Type must discard the packet and, only if 741 the packet's Destination Address was not a multicast address, return 742 an ICMP Parameter Problem, Code 2, message to the packet's Source 743 Address. 745 Extensions to the Binding Update option format may be included after 746 the fixed portion of the Binding Update option specified above. The 747 presence of such extensions will be indicated by the Option Length 748 field. When the Option Length is greater than the length defined 749 above, depending on the state of the Care-of Address Present (C) 750 and Home Link-Local Address Present (L) bits, the remaining octets 751 are interpreted as extensions. Currently, no extensions have been 752 defined. 754 4.2. Binding Acknowledgement Option 756 The Binding Acknowledgement destination option is used to acknowledge 757 receipt of a Binding Update option (Section 4.1). When a node 758 receives a packet containing a Binding Update option, with this 759 node being the destination node of the packet, this node MUST 760 return a Binding Acknowledgement to the source of the packet, if the 761 Acknowledge (A) bit is set in the Binding Update. 763 The Binding Acknowledgement option is encoded in type-length-value 764 (TLV) format as follows: 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+ 769 | Option Type | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Option Length | Status | Lifetime | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Refresh | Sequence Number | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Option Type 778 193 ??? 780 Option Length 782 8-bit unsigned integer. Length of the option, in octets, 783 excluding the Option Type and Option Length fields. For the 784 current definition of the Binding Acknowledgement option, this 785 field MUST be set to 9. 787 Status 789 8-bit unsigned integer indicating the disposition of the 790 Binding Update. Values of the Status field less than 128 791 indicate that the Binding Update was accepted by the receiving 792 node. The following such Status values are currently defined: 794 0 Binding Update accepted 796 Values of the Status field greater than or equal to 128 797 indicate that the Binding Update was rejected by the receiving 798 node. The following such Status values are currently defined: 800 128 Reason unspecified 801 129 Poorly formed Binding Update 802 130 Administratively prohibited 803 131 Insufficient resources 804 132 Home registration not supported 805 133 Not home subnet 806 134 Sequence Number field value too small 807 135 Dynamic home agent address discovery response 809 Up-to-date values of the Status field are to be specified in 810 the most recent "Assigned Numbers" [15]. 812 Lifetime 814 The granted lifetime for which this node will attempt to retain 815 the entry for this mobile node in its binding cache. If the 816 node sending the Binding Acknowledgement is serving as the 817 mobile node's home agent, the Lifetime period also indicates 818 the period for which this node will continue this service; if 819 the mobile node requires home agent service from this node 820 beyond this period, the mobile node MUST send a new Binding 821 Update to it before the expiration of this period, in order to 822 extend the lifetime. 824 Refresh 826 The recommended period at which the mobile node SHOULD send 827 a new Binding Update to this node in order to "refresh" the 828 mobile node's binding in this node's binding cache. This 829 refreshing of the binding is useful in case the node fails and 830 loses its cache state. The Refresh period is determined by 831 the node sending the Binding Acknowledgement (the node caching 832 the binding). If this node is serving as the mobile node's 833 home agent, the Refresh value may be set, for example, based on 834 whether the node stores the mobile node's binding in volatile 835 storage or in nonvolatile storage. If the node sending the 836 Binding Acknowledgement is not serving as the mobile node's 837 home agent, the Refresh period SHOULD be set equal to the 838 Lifetime period in the Binding Acknowledgement; even if this 839 node loses this cache entry due to a failure of the node, 840 packets from it can still reach the mobile node through the 841 mobile node's home agent, causing a new Binding Update to this 842 node to allow it to recreate this cache entry. 844 Sequence Number 846 The Sequence Number in the Binding Acknowledgement is copied 847 from the Sequence Number field in the Binding Update option, 848 for use by the mobile node in matching this Acknowledgement 849 with an outstanding Binding Update. 851 Any packet that includes a Binding Acknowledgement option MUST 852 include an IPv6 Authentication header [1] in order to protect 853 against forged Binding Acknowledgements. The authentication MUST 854 provide sender authentication, data integrity protection, and replay 855 protection. 857 If the node returning the Binding Acknowledgement accepted the 858 Binding Update for which the Acknowledgement is being returned (the 859 value of the Status field in the Acknowledgement is less than 128), 860 this node will have an entry for the mobile node in its Binding 861 Cache, and MUST use this entry (which includes the care-of address 862 received in the Binding Update) in sending the packet containing the 863 Binding Acknowledgement to the mobile node. The details of sending 864 this packet to the mobile node are the same as for sending any packet 865 to a mobile node using a binding, and are described in Section 6.8. 866 The packet is sent using a Routing header, routing the packet to the 867 mobile node by way of its care-of address recorded in the Binding 868 Cache entry. 870 If the node returning the Binding Acknowledgement instead 871 rejected the Binding Update (the value of the Status field in the 872 Acknowledgement is greater than or equal to 128), this node MUST 873 similarly use a Routing header in sending the packet containing the 874 Binding Acknowledgement, as described in Section 6.8, but MUST NOT 875 use its Binding Cache in forming the IP header or Routing header 876 in this packet. Rather, the care-of address used by this node in 877 sending the packet containing the Binding Acknowledgement MUST be 878 copied from the care-of address received in the rejected Binding 879 Update; this node MUST NOT modify its Binding Cache in response 880 to receiving this rejected Binding Update and MUST ignore its 881 Binding Cache in sending the packet in which it returns this Binding 882 Acknowledgement. The packet is sent using a Routing header, routing 883 the packet to the home address of the rejected Binding Update by way 884 of the care-of address indicated in the packet containing the Binding 885 Update. 887 The three highest-order bits of the Option Type are encoded to 888 indicate specific processing of the option [5]. For the Binding 889 Acknowledgement option, these three bits are set to 110, indicating 890 that the data within the option cannot change en-route to the 891 packet's final destination, and that any IPv6 node processing this 892 option that does not recognize the Option Type must discard the 893 packet and, only if the packet's Destination Address was not a 894 multicast address, return an ICMP Parameter Problem, Code 2, message 895 to the packet's Source Address. 897 Extensions to the Binding Acknowledgement option format may be 898 included after the fixed portion of the Binding Acknowledgement 899 option specified above. The presence of such extensions will be 900 indicated by the Option Length field. When the Option Length is 901 greater than 8 octets, the remaining octets are interpreted as 902 extensions. Currently, no extensions have been defined. 904 4.3. Binding Request Option 906 The Binding Request destination option is used to request a mobile 907 node's binding from the mobile node. When a mobile node receives 908 a packet containing a Binding Request option, it SHOULD return a 909 Binding Update (Section 4.1) to the source of the Binding Request. 911 The Binding Request option is encoded in type-length-value (TLV) 912 format as follows: 914 0 1 915 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Option Type | Option Length | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 Option Type 922 194 ??? 924 Option Length 926 8-bit unsigned integer. Length of the option, in octets, 927 excluding the Option Type and Option Length fields. For the 928 current definition of the Binding Request option, this field 929 MUST be set to 0. 931 The three highest-order bits of the Option Type are encoded to 932 indicate specific processing of the option [5]. For the Binding 933 Request option, these three bits are set to 110, indicating that the 934 data within the option cannot change en-route to the packet's final 935 destination, and that any IPv6 node processing this option that does 936 not recognize the Option Type must discard the packet and, only if 937 the packet's Destination Address was not a multicast address, return 938 an ICMP Parameter Problem, Code 2, message to the packet's Source 939 Address. 941 Extensions to the Binding Request option format may be included after 942 the fixed portion of the Binding Request option specified above. 943 The presence of such extensions will be indicated by the Option 944 Length field. When the Option Length is greater than 0 octets, 945 the remaining octets are interpreted as extensions. Currently, no 946 extensions have been defined. 948 4.4. Home Address Option 950 The Home Address destination option is used in a packet sent by a 951 mobile node to inform the recipient of that packet of the mobile 952 node's home address. For packets sent by a mobile node while 953 away from home, the mobile node generally uses one of its care-of 954 addresses as the Source Address in the packet's IPv6 header. By 955 including a Home Address option in the packet, the correspondent 956 node receiving the packet is able to substitute the mobile node's 957 home address for this care-of address when processing the packet, 958 thus making the use of the care-of address transparent to the 959 correspondent node. 961 The Home Address option is encoded in type-length-value (TLV) format 962 as follows: 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Option Type | Option Length | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | | 970 + + 971 | | 972 + Home Address + 973 | | 974 + + 975 | | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 Option Type 980 195 ??? 982 Option Length 984 8-bit unsigned integer. Length of the option, in octets, 985 excluding the Option Type and Option Length fields. For the 986 current definition of the Home Address option, this field MUST 987 be set to 8. 989 Home Address 991 The home address of the mobile node sending the packet. 993 The inclusion of a Home Address option in a packet affects only 994 the correspondent node's receipt of this single packet; no state 995 is created or modified in the correspondent node as a result of 996 receiving a Home Address option in a packet. In particular, the 997 receipt of a packet containing a Home Address option MUST NOT alter 998 the contents of the receiver's Binding Cache due to the presence of 999 the Home Address option, and the mapping between the home address 1000 and care-of address indicated by the Home Address option MUST NOT be 1001 used as a basis for routing subsequent packets sent by this receiving 1002 node. 1004 No special authentication of the Home Address option is required, 1005 except that if the IPv6 header of a packet is covered by 1006 authentication, then that authentication MUST also cover the Home 1007 Address option. If the packet carries no IP authentication, then the 1008 contents of the Home Address option, as well as the Source Address 1009 field or any other field in the IPv6 header, may have been forged or 1010 altered during transit. Upon receipt of a packet containing a Home 1011 Address option, the receiving node replaces the Source Address in 1012 the IPv6 header with the Home Address in the Home Address option. 1013 By requiring that any authentication of the IPv6 header also cover 1014 the Home Address option, the security of the Source Address field in 1015 the IPv6 header is not compromised by the presence of a Home Address 1016 option. Security issues related to the Home Address option are 1017 discussed further in Section 11. 1019 The three highest-order bits of the Option Type are encoded to 1020 indicate specific processing of the option [5]. For the Home Address 1021 option, these three bits are set to 110, indicating that the data 1022 within the option cannot change en-route to the packet's final 1023 destination, and that any IPv6 node processing this option that does 1024 not recognize the Option Type must discard the packet and, only if 1025 the packet's Destination Address was not a multicast address, return 1026 an ICMP Parameter Problem, Code 2, message to the packet's Source 1027 Address. 1029 Extensions to the Home Address option format may be included after 1030 the fixed portion of the Home Address option specified above. 1031 The presence of such extensions will be indicated by the Option 1032 Length field. When the Option Length is greater than 8 octets, 1033 the remaining octets are interpreted as extensions. Currently, no 1034 extensions have been defined. 1036 5. Requirements for IPv6 Nodes 1038 Mobile IPv6 places some special requirements on the functions 1039 provided by different IPv6 nodes. This section summarizes those 1040 requirements, identifying the functionality each requirement is 1041 intended to support. Further details on this functionality is 1042 provided in the following sections. 1044 Since any IPv6 node may at any time be a correspondent node of a 1045 mobile node, the following requirements pertain to all IPv6 nodes: 1047 - Every IPv6 node MUST be able to process a Home Address option 1048 received in a packet. 1050 - Every IPv6 node SHOULD be able to process a Binding Update option 1051 received in a packet, and to return a Binding Acknowledgement 1052 option if requested. 1054 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 1055 bindings received in accepted Binding Updates. 1057 In order for a mobile node to operate correctly while away from 1058 home, at least one IPv6 router in the mobile node's home subnet must 1059 function as a home agent for the mobile node. The following special 1060 requirements pertain to all IPv6 routers capable of serving as a home 1061 agent: 1063 - Every home agent MUST be able to maintain an entry in its Binding 1064 Cache for each mobile node for which it is serving as the home 1065 agent. Each such Binding Cache entry records the mobile node's 1066 binding with its primary care-of address and is marked as a "home 1067 registration". 1069 - Every home agent MUST be able to intercept packets (using proxy 1070 Neighbor Discovery) on the local subnet addressed to a mobile 1071 node for which it is currently serving as the home agent while 1072 that mobile node is away from home. 1074 - Every home agent MUST be able to encapsulate such intercepted 1075 packets in order to tunnel them to the primary care-of address 1076 for the mobile node indicated in its binding. 1078 - Every home agent MUST be able to return a Binding Acknowledgement 1079 in response to a Binding Update received with the Acknowledge (A) 1080 bit set. 1082 - Every home agent MUST be able to accept packets addressed to the 1083 Home-Agents anycast address for the subnet on which it is serving 1084 as a home agent, and MUST be able to participate in dynamic home 1085 agent address discovery. 1087 Finally, the following requirements pertain all IPv6 nodes capable of 1088 functioning as mobile nodes: 1090 - Every IPv6 mobile node MUST be able to perform IPv6 1091 decapsulation [4]. 1093 - Every IPv6 mobile node MUST support sending Binding Updates, as 1094 specified in Sections 8.4, 8.5, and 8.6; and MUST be able to 1095 receive and process Binding Acknowledgements, as specified in 1096 Section 8.9. 1098 - Every IPv6 mobile node MUST maintain a Binding Update List in 1099 which it records the IP address of each other node to which it 1100 has sent a Binding Update, for which the Lifetime sent in that 1101 binding has not yet expired. 1103 6. Correspondent Node Operation 1105 A correspondent node is any node communicating with a mobile node. 1106 The correspondent node, itself, may be fixed or mobile, and may 1107 possibly also be functioning as a home agent for Mobile IPv6. The 1108 procedures in this section thus apply to all IPv6 nodes. 1110 6.1. Receiving Packets from a Mobile Node 1112 Packets sent by a mobile node while away from home generally include 1113 a Home Address option. When a node receives a packet containing 1114 a Home Address option, it MUST process the option in a manner 1115 consistent with copying the Home Address field from the Home Address 1116 option into the IPv6 header, replacing the original value of the 1117 Source Address field there. Further processing of the packet (e.g., 1118 at the transport layer) thus need not know that the original Source 1119 Address was a care-of address, or that the Home Address option was 1120 used in the packet. Since the sending mobile node uses its home 1121 address at the transport layer when sending such a packet, the use of 1122 the care-of address and Home Address option is thus transparent to 1123 both the mobile node and the correspondent node above the level of 1124 the Home Address option generation and processing. 1126 6.2. Receiving Binding Updates 1128 Upon receiving a Binding Update option in some packet, the receiving 1129 node MUST validate the Binding Update according to the following 1130 tests: 1132 - The packet contains an IP Authentication header and the 1133 authentication is valid [1]. The Authentication header MUST 1134 provide sender authentication, integrity protection, and replay 1135 protection. 1137 - The Option Length field in the Binding Update option is greater 1138 than or equal to the length specified in Section 4.1. 1140 - The Sequence Number field in the Binding Update option is greater 1141 than the Sequence Number received in the previous Binding Update 1142 for this home address, if any. The Sequence Number comparison is 1143 performed modulo 2**16. 1145 - The packet MUST contain a valid Home Address option. The home 1146 address for the binding is specified by the Home Address field of 1147 the Home Address option. 1149 Any Binding Update not satisfying all of these tests MUST be silently 1150 ignored, although the remainder of the packet (i.e., other options, 1151 extension headers, or payload) SHOULD be processed normally according 1152 to any procedure defined for that part of the packet. 1154 If the Binding Update is valid according to the tests above, then the 1155 Binding Update is processed further as follows: 1157 - If the Destination Address in the packet's IPv6 header is the 1158 Home-Agents anycast address for a local subnet and this address 1159 is assigned to one of this node's network interfaces, then the 1160 mobile node sending this Binding Update is attempting dynamic 1161 home agent address discovery. Processing for this type of 1162 received Binding Update is described in Section 7.1. (If the 1163 Destination Address is not assigned to one of this node's network 1164 interfaces, then the packet would have been forwarded as a normal 1165 packet and the Binding Update, as a destination option, would not 1166 be processed in any way by this node.) 1168 - If the Lifetime specified in the Binding Update is nonzero and 1169 the specified Care-of Address is not equal to the home address 1170 for the binding, then this is a request to cache a binding for 1171 the mobile node. Processing for this type of received Binding 1172 Update is described in Section 6.3. 1174 - If the Lifetime specified in the Binding Update is zero or the 1175 specified Care-of Address matches the home address for the 1176 binding, then this is a request to delete the mobile node's 1177 cached binding. Processing for this type of received Binding 1178 Update is described in Section 6.4. 1180 6.3. Requests to Cache a Binding 1182 If a node receives a valid Binding Update requesting it to cache a 1183 binding for a mobile node, as specified in Section 6.2, then the node 1184 MUST examine the Home Registration (H) bit in the Binding Update 1185 to determine how to further process the Binding Update. If the 1186 Home Registration (H) bit is set, the Binding Update is processed 1187 according to the procedure specified in Section 7.2. 1189 If the Home Registration (H) bit is not set, then the receiving node 1190 SHOULD create a new entry in its Binding Cache for this mobile node 1191 (or update its existing Binding Cache entry for this mobile node, if 1192 such an entry already exists). The home address of the mobile node 1193 is taken from the Home Address field in the packet's Home Address 1194 option. The new Binding Cache entry records the association between 1195 this address and the care-of address for the binding, as specified 1196 in either the Care-of Address field of the Binding Update or in the 1197 Source Address field in the packet's IPv6 header. Any Binding Cache 1198 entry created or updated in response to processing this Binding 1199 Update MUST be deleted after the expiration of the Lifetime period 1200 specified in the Binding Update. 1202 6.4. Requests to Delete a Binding 1204 If a node receives a valid Binding Update requesting it to delete a 1205 cached binding for a mobile node, as specified in Section 6.2, then 1206 the node MUST examine the Home Registration (H) bit in the Binding 1207 Update to determine how to further process the Binding Update. If 1208 the Home Registration (H) bit is set, the Binding Update is processed 1209 according to the procedure specified in Section 7.3. 1211 If the Home Registration (H) bit is not set, then the receiving node 1212 MUST delete any existing entry in its Binding Cache for this mobile 1213 node. The home address of the mobile node is taken from the Home 1214 Address field in the packet's Home Address option. 1216 6.5. Sending Binding Acknowledgements 1218 When any node receives a packet containing a Binding Update option 1219 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 1220 Acknowledgement option acknowledging receipt of the Binding Update. 1221 If the node accepts the Binding Update and creates or updates an 1222 entry in its Binding Cache for this binding, the Status field in 1223 the Binding Acknowledgement MUST be set to a value less than 128; 1224 if the node rejects the Binding Update and does not create or 1225 update an entry for this binding, the Status field in the Binding 1226 Acknowledgement MUST be set to a value greater than or equal to 128. 1227 Specific values for the Status field are described in Section 4.2 and 1228 in the most recent "Assigned Numbers" [15]. 1230 As described in Section 4.2, the packet in which the Binding 1231 Acknowledgement is returned MUST include an IPv6 Authentication 1232 header [1] in order to protect against forged Binding 1233 Acknowledgements, and the packet MUST be sent using a Routing 1234 header in the same way as any other packet sent to a mobile node 1235 using a care-of address (even if the binding was not accepted), as 1236 described in Section 6.8. The packet is routed first to the care-of 1237 address contained in the Binding Update being acknowledged, and 1238 then to the mobile node's home address. This use of the Routing 1239 header ensures that the Binding Acknowledgement will be routed to the 1240 current location of the node sending the Binding Update, whether the 1241 Binding Update was accepted or rejected. 1243 6.6. Cache Replacement Policy 1245 Any entry in a node's Binding Cache MUST be deleted after the 1246 expiration of the Lifetime specified in the Binding Update from which 1247 the entry was created or was last updated. Conceptually, a node 1248 maintains a separate timer for each entry in its Binding Cache. When 1249 creating or updating a Binding Cache entry in response to a received 1250 and accepted Binding Update, the node sets the timer for this entry 1251 to the specified Lifetime period. When a Binding Cache entry's timer 1252 expires, the node deletes the entry. 1254 Each node's Binding Cache will, by necessity, have a finite size. 1255 A node MAY use any reasonable local policy for managing the space 1256 within its Binding Cache, except that any entry marked as a "home 1257 registration" (Section 7.2) MUST NOT be deleted from the cache until 1258 the expiration of its lifetime period. When attempting to add a 1259 new "home registration" entry in response to a Binding Update with 1260 the Home Registration (H) bit set, if insufficient space exists (or 1261 can be reclaimed) in the node's Binding Cache, the node MUST reject 1262 the Binding Update and SHOULD return a Binding Acknowledgement to 1263 the sending mobile node, in which the Status field is set to 131 1264 (insufficient resources). When otherwise attempting to add a new 1265 entry to its Binding Cache, a node MAY, if needed, choose to drop any 1266 entry already in its Binding Cache, other than a "home registration" 1267 entry, in order to make space for the new entry. For example, a 1268 "least-recently used" (LRU) strategy for cache entry replacement 1269 among entries not marked as a "home registration" is likely to work 1270 well. 1272 Any binding dropped from a node's Binding Cache due to lack of cache 1273 space will be rediscovered and a new cache entry created, if the 1274 binding is still in active use by the node for sending packets. If 1275 the node sends a packet to a destination for which it has dropped the 1276 entry from its Binding Cache, the packet will be routed normally, 1277 leading to the mobile node's home subnet. There, the packet will 1278 be intercepted by the mobile node's home agent and tunneled to the 1279 mobile node's current primary care-of address. As when a Binding 1280 Cache entry is initially created, this indirect routing to the mobile 1281 node through its home agent will result in the mobile node sending 1282 a Binding Update to this sending node when it receives the tunneled 1283 packet, allowing it to add an entry again for this destination to its 1284 Binding Cache. 1286 6.7. Receiving ICMP Error Messages 1288 When a correspondent node sends a packet to a mobile node, if the 1289 correspondent node has a Binding Cache entry for the destination 1290 address of the packet, then the correspondent node uses a Routing 1291 header to deliver the packet to the mobile node through the care-of 1292 address in the binding recorded in the Binding Cache entry. Any ICMP 1293 error message caused by the packet on its way to the mobile node will 1294 be returned normally to the correspondent node. 1296 On the other hand, if the correspondent node has no Binding Cache 1297 entry for the mobile node, the packet will be routed to the mobile 1298 node's home subnet, where it will be intercepted by the mobile node's 1299 home agent, encapsulated, and tunneled to the mobile node's primary 1300 care-of address. Any ICMP error message caused by the packet on 1301 its way to the mobile node while in the tunnel, will be returned to 1302 the mobile node's home agent (the source of the tunnel). By the 1303 definition of IPv6 encapsulation [4], this encapsulating node MUST 1304 relay certain ICMP error messages back to the original sender of the 1305 packet, which in this case is the correspondent node. 1307 Likewise, if a packet for a mobile node arrives at the mobile node's 1308 previous default router (e.g., the mobile node moved after the packet 1309 was sent), the router will encapsulate and tunnel the packet to the 1310 mobile node's new care-of address (if it has a Binding Cache entry 1311 for the mobile node). As above, any ICMP error message caused by the 1312 packet while in this tunnel will be returned to the previous default 1313 router (the source of the tunnel), which MUST relay certain ICMP 1314 error messages back to the correspondent node [4]. 1316 Thus, in all cases, any meaningful ICMP error messages caused by 1317 packets from a correspondent node to a mobile node will be returned 1318 to the correspondent node. If the correspondent node receives 1319 persistent ICMP Host Unreachable or Network Unreachable error 1320 messages after sending packets to a mobile node based on an entry in 1321 its Binding Cache, the correspondent node SHOULD delete this Binding 1322 Cache entry. If the correspondent node subsequently transmits 1323 another packet to the mobile node, the packet will be routed to the 1324 mobile node's home subnet, intercepted by the mobile node's home 1325 agent, and tunneled to the mobile node's primary care-of address 1326 using IPv6 encapsulation. The mobile node will then return a Binding 1327 Update to the correspondent node, allowing it to recreate a (correct) 1328 Binding Cache entry for the mobile node. 1330 6.8. Sending Packets to a Mobile Node 1332 Before sending any packet, the sending node SHOULD examine its 1333 Binding Cache for an entry for the destination address to which the 1334 packet is being sent. If the sending node has a Binding Cache entry 1335 for this address, the sending node SHOULD use a Routing header to 1336 route the packet to this mobile node (the destination node) by way 1337 of the care-of address in the binding recorded in that Binding Cache 1338 entry. For example, assuming use of a Type 0 Routing header [5], if 1339 no other use of a Routing header is involved in the routing of this 1340 packet, the mobile node sets the fields in the packet's IPv6 header 1341 and Routing header as follows: 1343 - The Destination Address in the packet's IPv6 header is set to 1344 the mobile node's care-of address copied from the Binding Cache 1345 entry. 1347 - The Routing header is initialized to contain a single route 1348 segment, with an Address of the mobile node's home address (the 1349 original destination address to which the packet was being sent). 1351 Following the definition of a Type 0 Routing header [5], this packet 1352 will be routed to the mobile node's care-of address, where it will 1353 be delivered to the mobile node (the mobile node has associated the 1354 care-of address with its network interface). Normal processing of 1355 the Routing header by the mobile node will then proceed as follows: 1357 - The mobile node swaps the Destination Address in the packet's 1358 IPv6 header and the Address specified in the Routing header. 1359 This results in the packet's IP Destination Address being set to 1360 the mobile node's home address. 1362 - The mobile node then resubmits the packet to its IPv6 module for 1363 further processing. Since the mobile node recognizes its own 1364 home address as one if its current IP addresses, the packet is 1365 processed further within the mobile node, in the same way then as 1366 if the mobile node was at home. 1368 If, instead, the sending node has no Binding Cache entry for the 1369 destination address to which the packet is being sent, the sending 1370 node simply sends the packet normally, with no Routing header. If 1371 the destination node is not a mobile node (or is a mobile node that 1372 is currently at home), the packet will be delivered directly to this 1373 node and processed normally by it. If, however, the destination node 1374 is a mobile node that is currently away from home, the packet will 1375 be intercepted by the mobile node's home agent and tunneled (using 1376 IPv6 encapsulation [4]) to the mobile node's current primary care-of 1377 address, as described in Section 7.4. The mobile node will then send 1378 a Binding Update to the sending node, as described in Section 8.5, 1379 allowing the sending node to create a Binding Cache entry for its use 1380 in sending subsequent packets to this mobile node. 1382 7. Home Agent Operation 1384 7.1. Dynamic Home Agent Address Discovery 1386 If a received Binding Update indicates that the mobile node sending 1387 it is attempting dynamic home agent address discovery, as described 1388 in Section 6.2, then the receiving node MUST process the Binding 1389 Update as specified in this section. 1391 A mobile node attempts dynamic home agent address discovery by 1392 sending its "home registration" Binding Update to the Home-Agents 1393 anycast address for its home IP subnet (the packet MUST also include 1394 a Home Address option, as described in Section 8.4). A home agent 1395 receiving such a Binding Update that is serving this subnet (the 1396 home agent is configured with this anycast address on one of its 1397 network interfaces) MUST reject the Binding Update and SHOULD return 1398 a Binding Acknowledgement indicating this rejection and giving its 1399 unicast address. The Status field in the Binding Acknowledgement 1400 MUST be set to 135 (dynamic home agent address discovery response). 1401 The mobile node, upon receiving this Binding Acknowledgement, MAY 1402 then resend its Binding Update to the unicast home agent address 1403 given in the Acknowledgement. 1405 7.2. Primary Care-of Address Registration 1407 General processing of a received Binding Update that requests a 1408 binding to be cached, is described in Section 6.3. However, if the 1409 Home Registration (H) bit is set in the Binding Update, then the 1410 receiving node MUST process the Binding Update as specified in this 1411 section, rather than following the general procedure specified in 1412 Section 6.3. 1414 To begin processing the Binding Update, the home agent MUST perform 1415 the following sequence of tests: 1417 - If the node is not a router that implements home agent 1418 functionality, then the node MUST reject the Binding Update and 1419 SHOULD return a Binding Acknowledgement to the mobile node, in 1420 which the Status field is set to 132 (home registration not 1421 supported). 1423 - Else, if the home address for the binding (the Home Address field 1424 in the packet's Home Address option) is not an on-link IPv6 1425 address with respect to the home agent's current Prefix List, 1426 then the home agent MUST reject the Binding Update and SHOULD 1427 return a Binding Acknowledgement to the mobile node, in which the 1428 Status field is set to 133 (not home subnet). 1430 - Else, if the home agent chooses to reject the Binding Update for 1431 any other reason (e.g., insufficient resources to serve another 1432 mobile node as a home agent), then the home agent SHOULD return a 1433 Binding Acknowledgement to the mobile node, in which the Status 1434 field is set to an appropriate value to indicate the reason for 1435 the rejection. 1437 If the home agent does not reject the Binding Update as described 1438 above, then it becomes the home agent for the mobile node. The new 1439 home agent (the receiving node) MUST then create a new entry or 1440 update the existing entry in its Binding Cache for this mobile node's 1441 home address, as described in Section 6.3. In addition, the home 1442 agent MUST mark this Binding Cache entry as a "home registration" 1443 to indicate that the node is serving as a home agent for this 1444 binding. Binding Cache entries marked as a "home registration" MUST 1445 be excluded from the normal cache replacement policy used for the 1446 Binding Cache (Section 6.6) and MUST NOT be removed from the Binding 1447 Cache until the expiration of the Lifetime period. 1449 If the home agent was not already serving as a home agent for this 1450 mobile node (the home agent did not already have a Binding Cache 1451 entry for this home address marked as a "home registration"), then 1452 the home agent MUST multicast onto the home subnet (to the all-nodes 1453 multicast address) a Neighbor Advertisement message [9] on behalf 1454 of the mobile node, to advertise the home agent's own link-layer 1455 address for the mobile node's home IP address. The Target Address in 1456 the Neighbor Advertisement message MUST be set to the mobile node's 1457 home address, and the Advertisement MUST include a Target Link-layer 1458 Address option specifying the home agent's link-layer address. The 1459 Solicited Flag (S) in the Advertisement MUST NOT be set, since it was 1460 not solicited by any Neighbor Solicitation message. The Override 1461 Flag (O) in the Advertisement MUST be set, indicating that the 1462 Advertisement SHOULD override any existing Neighbor Cache entry at 1463 any node receiving it. 1465 Any node on the home subnet receiving this Neighbor Advertisement 1466 message will thus update its Neighbor Cache to associate the mobile 1467 node's home address with the home agent's link layer address, causing 1468 it to transmit any future packets for the mobile node instead to 1469 the mobile node's home agent. Since multicasts on the local link 1470 (such as Ethernet) are typically not guaranteed to be reliable, the 1471 home agent MAY retransmit this Neighbor Advertisement message up to 1472 MAX_ADVERT_REXMIT times to increase its reliability. It is still 1473 possible that some nodes on the home subnet will not receive any of 1474 these Neighbor Advertisements, but these nodes will eventually be 1475 able to detect the link-layer address change for the mobile node's 1476 home address, through use of Neighbor Unreachability Detection [9]. 1478 In addition, while this node is serving as a home agent for this 1479 mobile node (it still has a "home registration" entry for this mobile 1480 node in its Binding Cache), it MUST act as a proxy for this mobile 1481 node to reply to any received Neighbor Solicitation messages for 1482 it. When a home agent receives a Neighbor Solicitation message, it 1483 MUST check if the Target Address specified in the message matches 1484 the home address of any mobile node for which it has a Binding Cache 1485 entry marked as a "home registration". If such an entry exists 1486 in its Binding Cache, the home agent MUST reply to the Neighbor 1487 Solicitation message with a Neighbor Advertisement message, giving 1488 the home agent's own link-layer address as the link-layer address for 1489 the specified Target Address. Likewise, if the mobile node included 1490 its home link-local address and set the Home Link-Local Address 1491 Present (L) bit in its Binding Update with which it established 1492 this "home registration" with its home agent, its home agent MUST 1493 also similarly act as a proxy for the mobile node's home link-local 1494 address while it has this "home registration" entry in its Binding 1495 Cache. Acting as a proxy in this way allows other nodes on the 1496 mobile node's home subnet to resolve the mobile node's IPv6 home 1497 address and IPv6 link-local address, and allows the home agent to 1498 to defend these addresses on the home subnet for Duplicate Address 1499 Detection [9]. 1501 7.3. Primary Care-of Address De-registration 1503 General processing of a received Binding Update that requests a 1504 binding to be deleted, is described in Section 6.4. However, if the 1505 Home Registration (H) bit is set in the Binding Update, then the 1506 receiving node MUST process the Binding Update as specified in this 1507 section, rather than following the general procedure specified in 1508 Section 6.4. 1510 To begin processing the Binding Update, the home agent MUST perform 1511 the following sequence of tests: 1513 - If the node is not a router that implements home agent 1514 functionality, then the node MUST reject the Binding Update and 1515 SHOULD return a Binding Acknowledgement to the mobile node, in 1516 which the Status field is set to 132 (home registration not 1517 supported). 1519 - Else, if the home address for the binding (the Home Address 1520 field in the packet's Home Address option) is not an on-link 1521 IPv6 address with respect to the home agent's current Prefix 1522 List, then it MUST reject the Binding Update and SHOULD return a 1523 Binding Acknowledgement to the mobile node, in which the Status 1524 field is set to 133 (not home subnet). 1526 If the home agent does not reject the Binding Update as described 1527 above, then it MUST delete any existing entry in its Binding Cache 1528 for this mobile node. 1530 In addition, in this case, the home agent MUST multicast a Neighbor 1531 Advertisement message (to the all-nodes multicast address), giving 1532 the mobile node's home address as the Target Address, and specifying 1533 the mobile node's link-layer address in a Target Link-layer 1534 Address option in the Neighbor Advertisement message. The home 1535 agent MAY retransmit this Neighbor Advertisement message up to 1536 MAX_ADVERT_REXMIT times to increase its reliability; any nodes on the 1537 home subnet that miss all of these Neighbor Advertisements can also 1538 eventually detect the link-layer address change for the mobile node's 1539 home address, through use of Neighbor Unreachability Detection [9]. 1541 7.4. Tunneling Intercepted Packets to a Mobile Node 1543 For any packet sent to a mobile node from the mobile node's home 1544 agent (for which the home agent is the original sender of the 1545 packet), the home agent is operating as a correspondent node of 1546 the mobile node for this packet and the procedures described in 1547 Section 6.8 apply. The home agent (as a correspondent node) uses a 1548 Routing header to route the packet to the mobile node by way of the 1549 care-of address in the home agent's Binding Cache (the mobile node's 1550 primary care-of address, in this case). 1552 In addition, while the mobile node is away from home and this node 1553 is acting as the mobile node's home agent, the home agent intercepts 1554 any packets on the home subnet addressed to the mobile node's 1555 home address, as described in Section 7.2. The home agent cannot 1556 use a Routing header to forward these intercepted packets to the 1557 mobile node, since it cannot modify the packet in flight without 1558 invalidating any existing IPv6 Authentication header present in the 1559 packet [1]. 1561 For forwarding each intercepted packet to the mobile node, the 1562 home agent MUST tunnel the packet to the mobile node using IPv6 1563 encapsulation [4]; the tunnel entry point node is the home agent, 1564 and the tunnel exit point node is the mobile node itself (using its 1565 primary care-of address as registered with the home agent). When a 1566 home agent encapsulates an intercepted packet for forwarding to the 1567 mobile node, the home agent sets the Source Address in the prepended 1568 tunnel IP header to the home agent's own IP address, and sets the 1569 Destination Address in the tunnel IP header to the mobile node's 1570 primary care-of address. When received by the mobile node (using its 1571 primary care-of address), normal processing of the tunnel header [4] 1572 will result in decapsulation and processing of the original packet by 1573 the mobile node. 1575 7.5. Renumbering the Home Subnet 1577 Neighbor Discovery [9] specifies a mechanism by which all nodes on a 1578 subnet can gracefully autoconfigure new addresses, say by each node 1579 combining a new routing prefix with its existing link-layer address. 1580 As currently specified, this mechanism works when the nodes are on 1581 the same link as the router issuing the necessary multicast packets 1582 to advertise the new routing prefix(es) appropriate for the link. 1584 However, for mobile nodes away from home, special care must be taken 1585 to allow the mobile nodes to renumber gracefully. The most direct 1586 method of ensuring this is for the home agent to encapsulate and 1587 tunnel the multicast packets to the primary care-of address of each 1588 mobile node for which it is serving as the home agent. The rules for 1589 this are as follows: 1591 - A mobile node assumes that its routing prefix has not changed 1592 unless it receives an authenticated Router Advertisement message 1593 from its home agent that the prefix has changed. 1595 - When the mobile node is at home, the home agent does not tunnel 1596 Router Advertisements to it. 1598 - The mobile node's home agent serves as a proxy for the mobile 1599 node's home address and link-local address, including defending 1600 these addresses for Duplicate Address Detection, while the mobile 1601 node is registered with the home agent away from home. 1603 - When a home subnet prefix changes, the home agent tunnels Router 1604 Advertisement packets to each mobile node registered with it that 1605 is currently away from home and using a home address with the 1606 affected routing prefix. Such tunneled Router Advertisements 1607 MUST be authenticated [1]. 1609 - When a mobile node receives a tunneled Router Advertisement 1610 containing a new routing prefix, it MUST perform the standard 1611 autoconfiguration operation to create its new address. 1613 - When a mobile node returns to its home subnet, it must again 1614 perform Duplicate Address Detection at the earliest possible 1615 moment after it has deleted its "home registration" binding with 1616 its home agent. 1618 - A mobile node MAY send a Router Solicitation to its home agent at 1619 any time, within the constraints imposed by rate control defined 1620 by Neighbor Discovery [9]. 1622 8. Mobile Node Operation 1624 8.1. Sending Packets While Away from Home 1626 While a mobile node is away from home, it continues to use its home 1627 address as well as also using one or more care-of addresses. When 1628 sending a packet while away from home, a mobile node MAY choose among 1629 these in selecting the address that it will use as the source of the 1630 packet, as follows: 1632 - For most packets, the mobile node will generally use its home 1633 address as the source of the packet. Doing so makes its mobility 1634 and the fact that it is currently away from home transparent to 1635 the correspondent nodes with which it communicates. For packets 1636 sent that are part of transport-level connections established 1637 while the mobile node was at home, the mobile node MUST use 1638 its home address. Likewise, for packets sent that are part of 1639 transport-level connections that the mobile node may still be 1640 using after moving to a new location, the mobile node SHOULD use 1641 its home address. 1643 - For short-term communication, particularly for communication 1644 that may easily be retried if it fails, the mobile node MAY 1645 choose to use one of its care-of addresses as the source of the 1646 packet. An example of this type of communication might be DNS 1647 queries sent by the mobile node [7, 8]. Using the mobile node's 1648 care-of address as the source for such queries will generally 1649 have a lower overhead than using the mobile node's home address, 1650 since no extra options need be used in either the query or its 1651 reply, and all packets can be routed normally, directly between 1652 their source and destination without relying on Mobile IP. If the 1653 mobile node has no particular knowledge that the communication 1654 being sent fits within this type of communication, however, the 1655 mobile node SHOULD use its home address. 1657 If the mobile node uses one of its care-of addresses as the source 1658 of some packet while away from home, no special Mobile IP processing 1659 is required for sending this packet. The packet is simply addressed 1660 and transmitted in the same way as any normal IPv6 packet, setting 1661 the Source Address field in the packet's IPv6 header to this care-of 1662 address. 1664 On the other hand, if the mobile node uses its home address as the 1665 source of a packet while away from home, the mobile node SHOULD 1666 construct the packet as follows: 1668 - The Source Address field in the packet's IPv6 header is set to 1669 one of the mobile node's care-of addresses. 1671 - A Home Address option is included in the packet, with the Home 1672 Address field set to the mobile node's home address. 1674 Without this use of the care-of address in the IPv6 header, with the 1675 mobile node's home address instead in the Home Address option, the 1676 packet will likely be discarded by any router implementing ingress 1677 filtering [6]. 1679 8.2. Movement Detection 1681 A mobile node MAY use any combination of mechanisms available to 1682 it to detect when its link-level point of attachment has moved 1683 from one IP subnet to another. The primary movement detection 1684 mechanism for Mobile IPv6 defined here uses the facilities of 1685 IPv6 Neighbor Discovery, including Router Discovery and Neighbor 1686 Unreachability Detection. The description here is based on the 1687 conceptual model of the organization and data structures defined by 1688 Neighbor Discovery [9]. 1690 Mobile nodes SHOULD use Router Discovery to discover new routers and 1691 on-link network prefixes; a mobile node MAY send Router Solicitation 1692 messages, or MAY wait for unsolicited (periodic) Router Advertisement 1693 messages, as specified for Router Discovery [9]. Based on received 1694 Router Advertisement messages, a mobile node (in the same way as any 1695 other node) maintains an entry in its Default Router List for each 1696 router, and an entry in its Prefix List for each network prefix, that 1697 it currently considers to be on-link. Each entry in these lists has 1698 an associated invalidation timer value (extracted from the Router 1699 Advertisement) used to expire the entry when it becomes invalid. 1701 While away from home, a mobile node SHOULD select one router from its 1702 Default Router List to use as its default router, and one network 1703 prefix advertised by that router from its Prefix List to use as 1704 the network prefix in its primary care-of address. A mobile node 1705 MAY also have associated additional care-of addresses, using other 1706 network prefixes from its Prefix List. The method by which a mobile 1707 node selects and forms a care-of address from the available network 1708 prefixes is described in Section 8.3. The mobile node registers 1709 its primary care-of address with its home agent, as described in 1710 Section 8.4. 1712 While a mobile node is away from home and using some router as its 1713 default router, it is important for the mobile node to be able to 1714 quickly detect when that router becomes unreachable, so that it can 1715 switch to a new default router and to a new primary care-of address. 1716 Since some links (notably wireless) do not necessarily work equally 1717 well in both directions, it is likewise important for the mobile 1718 node to detect when it becomes unreachable to packets sent from its 1719 default router, so that the mobile node can take steps to ensure that 1720 any correspondent nodes attempting to communicate with the it can 1721 still reach it through some other route. 1723 To detect when its default router becomes unreachable, a mobile 1724 node SHOULD use Neighbor Unreachability Detection. As specified in 1725 Neighbor Discovery [9], while the mobile node is actively sending 1726 packets to (or through) its default router, the mobile node can 1727 detect that the router is still reachable either through indications 1728 from upper layer protocols on the mobile node that a connection is 1729 making "forward progress" (e.g., receipt of TCP acknowledgements for 1730 new data transmitted), or through receipt of a Neighbor Advertisement 1731 message form its default router in response to an explicit Neighbor 1732 Solicitation messages to it. Note that although this mechanism only 1733 detects that the mobile node's default router has become unreachable 1734 to the mobile node while the mobile node is actively sending packets 1735 to it, this is the only time that this direction of reachability 1736 confirmation is needed. Confirmation that the mobile node is still 1737 reachable from the router is handled separately, as described below. 1739 For a mobile node to detect when it has become unreachable to its 1740 default router, however, the mobile node cannot efficiently rely on 1741 Neighbor Unreachability Detection alone, since the network overhead 1742 would be prohibitively high in many cases for a mobile node to 1743 continually probe its default router with Neighbor Solicitation 1744 messages even when it is not otherwise actively sending packets to 1745 it. Instead, a mobile node SHOULD consider receipt of any IPv6 1746 packets from its current default router as an indication that it is 1747 still reachable from the router. Both packets from the router's IP 1748 address and (IPv6) packets from its link-layer address (e.g., those 1749 forwarded but not originated by the router) SHOULD be considered. 1751 Since the router SHOULD be sending periodic multicast Router 1752 Advertisement messages, the mobile node will have frequent 1753 opportunity to check if it is still reachable from its default 1754 router, even in the absence of other packets to it from the router. 1755 On some types of network interfaces, the mobile node MAY also 1756 supplement this by setting its network interface into "promiscuous" 1757 receive mode, so that it is able to receive all packets on the link, 1758 including those not link-level addressed to it. The mobile node will 1759 then be able to detect any packets sent by the router, in order to to 1760 detect reachability from the router. This may be useful on very low 1761 bandwidth (e.g., wireless) links, but its use MUST be configurable on 1762 the mobile node. 1764 If the above means do not provide indication that the mobile node 1765 is still reachable from its current default router (i.e., the 1766 mobile node receives no packets from the router for a period of 1767 time), then the mobile node SHOULD actively probe the router with 1768 Neighbor Solicitation messages, even if it is not otherwise actively 1769 sending packets to the router. If it receives a solicited Neighbor 1770 Advertisement message in response from the router, then the mobile 1771 node can deduce that it is still reachable. It is expected that the 1772 mobile node will in most cases be able to determine its reachability 1773 from the router by listening for packets from the router as described 1774 above, and thus, such extra Neighbor Solicitation probes should 1775 rarely be necessary. 1777 With some types of networks, it is possible that additional 1778 indications about link-layer mobility can be obtained from 1779 lower-layer protocol or device driver software within the mobile 1780 node. However, a mobile node MUST NOT assume that all link-layer 1781 mobility indications from lower layers indicate a movement of the 1782 mobile node's link-layer connection to a new IP subnet, such that the 1783 mobile node would need to switch to a new default router and primary 1784 care-of address. Upon lower-layer indication of link-layer mobility, 1785 the mobile node SHOULD send Router Solicitation messages to determine 1786 if new routers (and new on-link network prefixes) are present on its 1787 new link. 1789 Such lower-layer information might also be useful to a mobile node in 1790 deciding to switch its primary care-of address to one of the other 1791 care-of addresses it has formed from the on-link network prefixes 1792 currently available through different default routers from which the 1793 mobile node is reachable. For example, a mobile node MAY use signal 1794 strength or signal quality information (with suitable hysteresis) 1795 for its link with the available default routers to decide when to 1796 switch to a new primary care-of address using that default router 1797 rather than its current default router (and current primary care-of 1798 address). Even though the mobile node's current default router may 1799 still be reachable in terms of Neighbor Unreachability Detection, the 1800 mobile node MAY use such lower-layer information to determine that 1801 switching to a new default router would provide a better connection. 1803 8.3. Forming New Care-of Addresses 1805 After detecting that its link-layer point of attachment has moved 1806 from one IPv6 subnet to another (i.e., its current default router 1807 has become unreachable and it has discovered a new default router), 1808 a mobile node SHOULD form a new primary care-of address using one of 1809 the on-link network prefixes advertised by the new router. A mobile 1810 node MAY form a new primary care-of address at any time, except 1811 that it MUST NOT do so too frequently (not more often than once per 1812 MAX_UPDATE_RATE seconds). 1814 In addition, after discovering a new on-link network prefix, a 1815 mobile node MAY form a new (non-primary) care-of address using that 1816 network prefix, even when it has not switched to a new default 1817 router. A mobile node can have only one primary care-of address at 1818 a time (which is registered with its home agent), but it MAY have an 1819 additional care-of address for any or all of the network prefixes on 1820 its current link. Furthermore, since a wireless network interface 1821 may actually allow a mobile node to be reachable on more than one 1822 link at a time (i.e., within wireless transmitter range of routers 1823 on more than one separate link), a mobile node MAY have care-of 1824 addresses on more than one link at a time. The use of more than one 1825 care-of address at a time is described in Section 8.10. 1827 As described in Section 3.1, in order to form a new care-of address, 1828 a mobile node MAY use either stateless [16] or stateful (e.g., 1829 DHCPv6 [3]) address autoconfiguration. If a mobile node needs to 1830 send packets as part of the method of address autoconfiguration, 1831 it MUST use an IPv6 link-local address rather than its own IPv6 1832 home address as the Source Address in the IPv6 header of each such 1833 autoconfiguration packet. 1835 In some cases, a mobile node may already know a (constant) IPv6 1836 address that has been assigned to it for its use only while visiting 1837 a specific foreign subnet. For example, a mobile node may be 1838 statically configured with an IPv6 address assigned by the system 1839 administrator of some foreign subnet, for its use while visiting that 1840 subnet. If so, rather than using address autoconfiguration to form 1841 a new care-of address using this network prefix, the mobile node 1842 MAY use its own pre-assigned address as its care-of address on this 1843 subnet. 1845 8.4. Sending Binding Updates to the Home Agent 1847 After deciding to change its primary care-of address as described 1848 in Sections 8.2 and 8.3, a mobile node MUST register this care-of 1849 address with its home agent in order to make this its primary care-of 1850 address. To do so, the mobile node sends a packet to its home agent 1851 containing a Binding Update option, with the packet constructed as 1852 follows: 1854 - The Home Registration (H) bit MUST be set in the Binding Update. 1856 - The Acknowledge (A) bit MUST be set in the Binding Update. 1858 - The packet MUST contain a Home Address option, giving the mobile 1859 node's home address for the binding. 1861 - The care-of address for the binding MUST be used as the Source 1862 Address in the packet's IPv6 header, or the Care-of Address 1863 Present (C) bit MUST be set in the Binding Update and the care-of 1864 address for binding MUST be specified in the Care-of Address 1865 field in the Binding Update. 1867 The Acknowledge (A) bit in the Binding Update requests the home 1868 agent to return a Binding Acknowledgement in response to this 1869 Binding Update. As described in Section 4.2, the mobile node SHOULD 1870 retransmit this Binding Update to its home agent until it receives 1871 a matching Binding Acknowledgement. Once reaching a retransmission 1872 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD 1873 continue to periodically retransmit the Binding Update at this rate 1874 until acknowledged (or until it begins attempting to register a 1875 different primary care-of address). 1877 It is possible that when the mobile node needs to send such a Binding 1878 Update to its home agent, that the mobile node does not know the 1879 address of any router in its home subnet that can serve as a home 1880 agent for it. In this case, the mobile node SHOULD use the dynamic 1881 home agent address resolution procedure to find the address of a 1882 suitable home agent in its home subnet. To do so, the mobile node 1883 sends the packet, as described above, with the Destination Address in 1884 the packet's IPv6 header set the Home-Agents anycast address for its 1885 home subnet. The home agent in its home subnet that receives this 1886 Binding Update will reject the Update, returning to the mobile node 1887 the home agent's unicast IP address. The mobile node SHOULD then 1888 retransmit its Binding Update to this home agent using the provided 1889 unicast address. 1891 If the mobile node has a current registration with some home agent 1892 in its home subnet (the Lifetime for that registration has not yet 1893 expired), then the mobile node MUST attempt any new registration 1894 first with that home agent. If that registration attempt fails 1895 (e.g., times out or is rejected), the mobile node SHOULD then 1896 reattempt this registration with another home agent in its home 1897 subnet. If the mobile node knows of no other suitable home agent, 1898 then it MAY attempt the dynamic home agent address resolution 1899 procedure described above. 1901 8.5. Sending Binding Updates to Correspondent Nodes 1903 A mobile node MAY send a Binding Update to any correspondent node at 1904 any time to allow it to cache its current care-of address (subject 1905 to the rate limiting defined in Section 8.8). In any Binding Update 1906 sent by a mobile node, the care-of address (either the Source Address 1907 in the packet's IPv6 header or the Care-of Address field in the 1908 Binding Update) MUST be set to one of the care-of addresses currently 1909 in use by the mobile node or to the mobile node's home address. 1910 If set to one of the mobile node's current care-of addresses (the 1911 care-of address given MAY differ from the mobile node's primary 1912 care-of address), the Binding Update requests the correspondent node 1913 to create or update an entry for the mobile node in the correspondent 1914 node's Binding Cache to record this care-of address for use in 1915 sending future packets to the mobile node. If, instead, the care-of 1916 address is set to the mobile node's home address, the Binding Update 1917 requests the correspondent node to delete any existing Binding Cache 1918 entry that it has for the mobile node. A mobile node MAY set the 1919 care-of address differently for sending Binding Updates to different 1920 correspondent nodes. 1922 When sending any Binding Update, the mobile node MUST record in its 1923 Binding Update List the following fields from the Binding Update: 1925 - The IP address of the node to which the Binding Update was sent. 1927 - The home address for which the Binding Update was sent, 1929 - The remaining lifetime of the binding, initialized from the 1930 Lifetime field sent in the Binding Update. 1932 The mobile node MUST retain in its Binding Update List information 1933 about all Binding Updates sent, for which the lifetime of the 1934 binding has not yet expired. When sending a Binding Update, if an 1935 entry already exists in the mobile node's Binding Update List for 1936 an earlier Binding Update sent to that same destination node, the 1937 existing Binding Update List entry is updated to reflect the new 1938 Binding Update rather than creating a new Binding Update List entry. 1940 In general, when a mobile node sends a Binding Update to its home 1941 agent to register a new primary care-of address (as described in 1942 Section 8.4), the mobile node will also send a Binding Update to each 1943 correspondent node for which an entry exists in the mobile node's 1944 Binding Update List. Thus, correspondent nodes are generally kept 1945 updated about the mobile node's binding and can send packets directly 1946 to the mobile node using the mobile node's current care-of address. 1948 The mobile node, however, need not send these Binding Updates 1949 immediately after configuring a new care-of address. For example, 1950 since the Binding Update is a destination option and can be included 1951 in any packet sent by a mobile node, the mobile node MAY delay 1952 sending a new Binding Update to any correspondent node for a 1953 short period of time, in hopes that the needed Binding Update 1954 can be included in some packet that the mobile node sends to that 1955 correspondent node for some other reason (for example, as part of 1956 some TCP connection in use). In this case, when sending a packet 1957 to some correspondent node, the mobile node SHOULD check in its 1958 Binding Update List to determine if a new Binding Update to this 1959 correspondent node is needed, and SHOULD include the new Binding 1960 Update in this packet as necessary. 1962 In addition, when a mobile node receives a packet for which the 1963 mobile node can deduce that the original sender of the packet has no 1964 Binding Cache entry for the mobile node, or for which the mobile node 1965 can deduce that the original sender of the packet has an out-of-date 1966 care-of address for the mobile node in its Binding Cache, the mobile 1967 node SHOULD return a Binding Update to the sender giving its current 1968 care-of address. In particular, the mobile node SHOULD return a 1969 Binding Update in response to receiving a packet that meets all of 1970 the following tests: 1972 - The packet was tunneled using IPv6 encapsulation. 1974 - The Destination Address in the tunnel (outer) IPv6 header is 1975 equal to any of the mobile node's care-of addresses. 1977 - The Destination Address in the original (inner) IPv6 header is 1978 equal to the mobile node's home address. If the original packet 1979 contains a Routing header, the final Address indicated in the 1980 Routing header should be used in this comparison rather than the 1981 Destination Address in the original IPv6 header. 1983 - The Source Address in the tunnel (outer) IPv6 header differs from 1984 the Source Address in the original (inner) IPv6 header. 1986 The destination address to which the Binding Update should be sent in 1987 response to receiving a packet meeting all of the tests above, is the 1988 Source Address in the original (inner) IPv6 header of the packet. 1990 Binding Updates sent to correspondent nodes are not generally 1991 required to be acknowledged. However, if the mobile node wants to be 1992 sure that its new care-of address has been added to a correspondent 1993 node's Binding Cache, the mobile node MAY request an acknowledgement 1994 by setting the Acknowledge (A) bit in the Binding Update. In this 1995 case, however, the mobile node SHOULD NOT continue to retransmit the 1996 Binding Update once the retransmission timeout period has reached 1997 MAX_BINDACK_TIMEOUT. 1999 A mobile node MAY choose to keep its location private from certain 2000 correspondent nodes, and thus need not send new Binding Updates to 2001 those correspondents. A mobile node MAY also send a Binding Update 2002 to such a correspondent node to instruct it to delete any existing 2003 binding for the mobile node from its Binding Cache, as described in 2004 Section 4.1. No other IPv6 nodes are authorized to send Binding 2005 Updates on behalf of a mobile node. 2007 8.6. Sending Binding Updates to the Previous Default Router 2009 After switching to a new default router (and thus also changing its 2010 primary care-of address), a mobile node SHOULD send a Binding Update 2011 to its previous default router, giving its new care-of address. If 2012 the mobile node sends such a Binding Update, the home address for 2013 the binding, specified in the Home Address option included in the 2014 packet carrying this Binding Update, MUST be set the mobile node's 2015 old primary care-of address (that it used while using this default 2016 router), and the care-of address for the binding (either the Source 2017 Address in the packet's IPv6 header or the Care-of Address field in 2018 the Binding Update) MUST be set to the mobile node's new primary 2019 care-of address. In addition, the Home Registration (H) bit MUST 2020 also be set in this Binding Update, to request the mobile node's 2021 previous default router to temporarily act as a home agent for the 2022 mobile node's old primary care-of address. Note that the previous 2023 router does not necessarily know the mobile node's (permanent) home 2024 address as part of this registration. 2026 If any subsequent packets arrive at this previous router for 2027 forwarding to the mobile node's old primary care-of address, 2028 the router SHOULD encapsulate each such packet (using IPv6 2029 encapsulation [4]) and tunnel it to the mobile node at its new 2030 primary care-of address. Moreover, for the lifetime of the "home 2031 registration" Binding Cache entry for the mobile node at this 2032 router, this router MUST act as a proxy for the mobile node's 2033 previous care-of address, for purposes of participation in Neighbor 2034 Discovery [9], in the same way as any home agent does for a mobile 2035 node's home address (Section 7.2). This allows the router to 2036 intercept packets addressed to the mobile node's previous care-of 2037 address, and to encapsulate and tunnel them to the mobile node's new 2038 care-of address, as described in Section 7.4. 2040 8.7. Retransmitting Binding Updates 2042 If, after sending a Binding Update in which the Acknowledge (A) bit 2043 is set, a mobile node fails to receive a Binding Acknowledgement 2044 within INITIAL_BINDACK_TIMEOUT seconds, the mobile node SHOULD 2045 retransmit the Binding Update until a Binding Acknowledgement 2046 is received. Such a retransmitted Binding Update MUST use he 2047 same Sequence Number value as the original transmission. The 2048 retransmissions by the mobile node MUST use an exponential 2049 back-off process, in which the timeout period is doubled 2050 upon each retransmission until either the node receives a 2051 Binding Acknowledgement or the timeout period reaches the value 2052 MAX_BINDACK_TIMEOUT. 2054 8.8. Rate Limiting for Sending Binding Updates 2056 A mobile node MUST NOT send Binding Updates more often than once per 2057 MAX_UPDATE_RATE seconds to any node. After sending MAX_FAST_UPDATES 2058 consecutive Binding Updates to a particular node with the same 2059 care-of address, the mobile node SHOULD reduce its rate of sending 2060 Binding Updates to that node, to the rate of SLOW_UPDATE_RATE per 2061 second. The mobile node MAY continue to send Binding Updates at the 2062 slower rate indefinitely, in hopes that the node will eventually 2063 be able to process a Binding Update and begin to route its packets 2064 directly to the mobile node at its new care-of address. 2066 8.9. Receiving Binding Acknowledgements 2068 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 2069 node MUST validate the packet according to the following tests: 2071 - The packet contains an IP Authentication header and the 2072 authentication is valid [1]. The Authentication header MUST 2073 provide both sender authentication, integrity protection, and 2074 replay protection. 2076 - The Option Length field in the option is greater than or equal to 2077 9 octets. 2079 - The Sequence Number field matches the Sequence Number sent by the 2080 mobile node to this destination address in an outstanding Binding 2081 Update. 2083 Any Binding Acknowledgement not satisfying all of these tests MUST be 2084 silently ignored, although the remainder of the packet (i.e., other 2085 options, extension headers, or payload) SHOULD be processed normally 2086 according to any procedure defined for that part of the packet. 2088 When a mobile node receives a packet carrying a valid Binding 2089 Acknowledgement, the mobile node MUST examine the Status field as 2090 follows: 2092 - If the Status field indicates that the Binding Update was 2093 accepted (the Status field is less than 128), then the mobile 2094 node MUST update the corresponding entry in its Binding Update 2095 List to indicate that the Binding Update has been acknowledged. 2096 The mobile node MUST thus stop retransmitting the Binding Update. 2098 - If the Status field indicates that the Binding Update was not 2099 accepted (the Status field is greater than or equal to 128), then 2100 the mobile node MUST delete the corresponding Binding Update List 2101 entry (and MUST also stop retransmitting the Binding Update). 2102 Optionally, the mobile node MAY then take steps to correct the 2103 cause of the error and retransmit the Binding Update (with a new 2104 Sequence Number value), subject to the rate limiting restriction 2105 specified in Section 8.8. 2107 8.10. Using Multiple Care-of Addresses 2109 As described in Section 8.3, a mobile node MAY have more than one 2110 care-of address at a time. Particularly in the case of many wireless 2111 networks, a mobile node effectively might be reachable through 2112 multiple link-level points of attachment at the same time (e.g., 2113 with overlapping wireless cells), on which different on-link network 2114 prefixes may exist. A mobile node SHOULD select a primary care-of 2115 address from among those care-of addresses it has formed using any 2116 of these network prefixes, based on the movement detection mechanism 2117 in use, as described in Section 8.2. When the mobile node selects 2118 a new primary care-of address, it MUST register it with its home 2119 agent through a Binding Update with the Home Registration (H) and 2120 Acknowledge (A) bits set, as described in Section 8.4. 2122 To assist with smooth handoffs, a mobile node SHOULD retain 2123 its previous primary care-of address as a (non-primary) care-of 2124 address, and SHOULD still accept packets at this address, even after 2125 registering its new primary care-of address with its home agent. 2126 This is reasonable, since the mobile node could only receive packets 2127 at its previous primary care-of address if it were indeed still 2128 connected to that link. If the previous primary care-of address 2129 was allocated using stateful address autoconfiguration [3], the 2130 mobile node may not wish to release the address immediately upon 2131 switching to a new primary care-of address. The stateful address 2132 autoconfiguration server will allow mobile nodes to acquire new 2133 addresses while still using previously allocated addresses. 2135 8.11. Returning Home 2137 A mobile node detects that it has returned to its home subnet through 2138 the movement detection algorithm in use (Section 8.2), when the 2139 mobile node detects that the network prefix of its home subnet is 2140 again on-link. The mobile node SHOULD then send a Binding Update to 2141 its home agent, to instruct its home agent to no longer intercept 2142 or tunnel packets for it. In this Binding Update, the mobile node 2143 MUST set the care-of address for the binding (Source Address field in 2144 the packet's IPv6 header) to the mobile node's own home address. As 2145 with other Binding Updates sent to register with its home agent, the 2146 mobile node MUST set the Acknowledge (A) and Home Registration (H) 2147 bits, and SHOULD retransmit the Binding Update until a matching 2148 Binding Acknowledgement is received. 2150 In addition, the mobile node MUST multicast onto the home subnet 2151 (to the all-nodes multicast address) a Neighbor Advertisement 2152 message [9], to advertise the mobile node's own link-layer address 2153 for its own home address. The Target Address in this Neighbor 2154 Advertisement message MUST be set to the mobile node's home address, 2155 and the Advertisement MUST include a Target Link-layer Address 2156 option specifying the mobile node's link-layer address. Similarly, 2157 the mobile node MUST multicast a Neighbor Advertisement message to 2158 advertise its link-layer address for its IPv6 link-local address. 2159 The Solicited Flag (S) in these Advertisements MUST NOT be set, since 2160 they were not solicited by any Neighbor Solicitation message. The 2161 Override Flag (O) in these Advertisements MUST be set, indicating 2162 that the Advertisements SHOULD override any existing Neighbor Cache 2163 entries at any node receiving them. 2165 Since multicasts on the local link (such as Ethernet) are typically 2166 not guaranteed to be reliable, the mobile node MAY retransmit 2167 these Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times 2168 to increase their reliability. It is still possible that some 2169 nodes on the home subnet will not receive any of these Neighbor 2170 Advertisements, but these nodes will eventually be able to recover 2171 through use of Neighbor Unreachability Detection [9]. 2173 9. Routing Multicast Packets 2175 A mobile node that is connected to its home subnet functions in the 2176 same way as any other (stationary) node. Thus, when it is at home, 2177 a mobile node functions identically to other multicast senders and 2178 receivers. This section therefore describes the behavior of a mobile 2179 node that is not on its home subnet. 2181 In order receive packets sent to some multicast group, a mobile node 2182 must join the that multicast group. One method by which a mobile 2183 node MAY join the group is via a (local) multicast router on the 2184 foreign subnet being visited. This option assumes that there is a 2185 multicast router present on the foreign subnet. The mobile node 2186 SHOULD use its care-of address sharing a network prefix with the 2187 multicast router, as the source IPv6 address of its multicast group 2188 membership control messages. 2190 Alternatively, a mobile node MAY join multicast groups via a 2191 bi-directional tunnel to its home agent, assuming that its home agent 2192 is a multicast router. The mobile node tunnels the appropriate 2193 multicast group membership control packets to its home agent, and the 2194 home agent forwards multicast packets down the tunnel to the mobile 2195 node. 2197 A mobile node that wishes to send packets to a multicast group 2198 also has two options: (1) send directly on the foreign subnet 2199 being visited; or (2) send via a tunnel to its home agent. Because 2200 multicast routing in general depends upon the Source Address used 2201 in the IPv6 header of the multicast packet, a mobile node that 2202 sends multicast packets directly on the foreign subnet MUST use its 2203 care-of address as the IPv6 Source Address of each multicast packet. 2204 Similarly, a mobile node that tunnels a multicast packet to its home 2205 agent MUST use its home address as the IPv6 Source Address of the 2206 inner multicast packet. This second option assumes that the home 2207 agent is a multicast router. 2209 10. Constants 2211 INITIAL_BINDACK_TIMEOUT 1 second 2213 MAX_BINDACK_TIMEOUT 256 seconds 2215 MAX_UPDATE_RATE once per second 2217 SLOW_UPDATE_RATE once per 10 seconds 2219 MAX_FAST_UPDATES 5 2221 MAX_ADVERT_REXMIT 3 2223 11. Security Considerations 2225 11.1. Binding Updates, Acknowledgements, and Requests 2227 The Binding Update option described in this document will result 2228 in packets addressed to a mobile node being delivered instead to 2229 its care-of address. This ability to change the routing of these 2230 packets could be a significant vulnerability if any packet containing 2231 a Binding Update option was not authenticated. Such use of "remote 2232 redirection", for instance as performed by the Binding Update option, 2233 is widely understood to be a security problem in the current Internet 2234 if not authenticated [2]. 2236 The Binding Acknowledgement option also requires authentication, 2237 since, for example, an attacker could otherwise trick a mobile node 2238 into believing a different outcome from a registration attempt with 2239 its home agent. 2241 No authentication is required for the Binding Request option, since 2242 the use of this option does not modify or create any state in either 2243 the sender or the receiver. This Option Does open some issues with 2244 binding privacy, but those issues can be dealt with either through 2245 existing IPsec encryption mechanisms or through use of firewalls. 2247 The existing IPsec replay protection mechanisms allow a "replay 2248 protection window" to support receiving packets out of order. 2249 Although appropriate for many forms of communication, Binding Updates 2250 MUST be applied only in the order sent. The Binding Update option 2251 thus includes a Sequence Number field to provide this necessary 2252 sequencing. The use of this Sequence Number together with IPsec 2253 replay protection is similar in many ways, for example, to the the 2254 sequence number in TCP. IPsec provides strong replay protection but 2255 no ordering, and the sequence number provides ordering but need not 2256 worry about replay protection such as through the sequence number 2257 wrapping around. 2259 11.2. Home Address Options 2261 No special authentication of the Home Address option is required, 2262 except that if the IPv6 header of a packet is covered by 2263 authentication, then that authentication MUST also cover the Home 2264 Address option. Thus, even when authentication is used in the IPv6 2265 header, the security of the Source Address field in the IPv6 header 2266 is not compromised by the presence of a Home Address option. Without 2267 authentication of the packet, then any field in the IPv6 header, 2268 including the Source Address field, and any other parts of the 2269 packet, including the Home Address option, can be forged or modified 2270 in transit. In this case, the contents of the Home Address option is 2271 no more suspect than any other part of the packet. 2273 The use of the Home Address option allows packets sent by a 2274 mobile node to pass normally through routers implementing ingress 2275 filtering [6]. Since the care-of address used in Source Address 2276 field of the packet's IPv6 header is topologically correct for the 2277 sending location of the mobile node, ingress filtering can trace the 2278 location of the mobile node in the same way as can be done with any 2279 sender when ingress filtering is in use. 2281 However, if a node receiving a packet that includes a Home Address 2282 option implements the processing of this option by physically 2283 copying the Home Address field from the option into the IPv6 header, 2284 replacing the Source Address field there, then the ability to 2285 trace the true location of the sender is removed once this step 2286 in the processing is performed. This diminishing of the power of 2287 ingress filtering only occurs once the packet has been received at 2288 its ultimate destination, and does not affect the capability of 2289 ingress filtering while the packet is in transit. Furthermore, this 2290 diminishing can be entirely eliminated by appropriate implementation 2291 techniques in the receiving node. For example, the original contents 2292 of the Source Address field (the sending care-of address) could be 2293 saved elsewhere in memory with the packet, until all processing of 2294 the packet is completed. 2296 11.3. General Mobile Computing Issues 2298 The mobile computing environment is potentially very different from 2299 the ordinary computing environment. In many cases, mobile computers 2300 will be connected to the network via wireless links. Such links 2301 are particularly vulnerable to passive eavesdropping, active replay 2302 attacks, and other active attacks. Furthermore, mobile computers 2303 are more susceptible to loss or theft than stationary computers. 2304 Any secrets such as authentication or encryption keys stored on the 2305 mobile computer are thus subject to compromise in ways generally not 2306 common in the non-mobile environment. 2308 Users who have sensitive data that they do not wish others to see 2309 should use mechanisms outside the scope of this document (such as 2310 encryption) to provide appropriate protection. Users concerned about 2311 traffic analysis should consider appropriate use of link encryption. 2312 If stronger location privacy is desired, the mobile node can create a 2313 tunnel to its home agent. Then, packets destined for correspondent 2314 nodes will appear to emanate from the home subnet, and it may be 2315 more difficult to pinpoint the location of the mobile node. Such 2316 mechanisms are all beyond the scope of this document. 2318 Appendix A. Changes from Previous Draft 2320 This appendix briefly lists some of the major changes in this 2321 draft relative to the previous version of this same draft, 2322 draft-ietf-mobileip-ipv6-02.txt: 2324 - Added a comparison to Mobile IP for IPv4 and added this section 2325 listing changes from the previous version of this draft. 2327 - Introduced the Home Address destination option, to allow packets 2328 sent by a mobile node while away from home to pass normally 2329 through routers implementing ingress filtering. 2331 - Added the requirement that all IPv6 nodes MUST be able to 2332 correctly process a Home Address destination option in a received 2333 packet. 2335 - Changed the interpretation of the Binding Update option such 2336 that the home address in the binding is the address in the Home 2337 Address option, not the Source Address in the IPv6 header. 2339 - Made the Care-of Address field in the Binding Update optional, 2340 controlled by whether or not the new Care-of Address Present (C) 2341 bit is set in the option. With the new use of the Home Address 2342 option, the care-of address for a binding will usually be 2343 specified by the Source Address field in the packet's IPv6 2344 header, but by retaining this field (and making it optional), 2345 it is possible to send a binding update using a Source Address 2346 different from the care-of address for the binding. 2348 - Changed the 32-bit Identification field in the Binding Update and 2349 Binding Acknowledgement to a 16-bit Sequence Number field, and 2350 clarified the use of this field. Replay protection for Binding 2351 Updates and Binding Acknowledgements is provided by the IPsec 2352 authentication in the packet, but this replay protection does 2353 not provide sequencing due to the use of the replay protection 2354 window. This field satisfies that the additional sequencing 2355 requirement. 2357 - Added a description of the dynamic home agent address discovery 2358 procedure and the use of the new Home-Agents anycast address. 2360 Acknowledgements 2362 We would like to thank the members of the Mobile IP and IPng Working 2363 Groups for their comments and suggestions on this work. We would 2364 particularly like to thank Thomas Narten and Erik Nordmark for 2365 their detailed reviews of earlier versions of this draft. Their 2366 suggestions have helped to improve both the design and presentation 2367 of the protocol. 2369 References 2371 [1] Randall Atkinson. IP Authentication header. RFC 1826, August 2372 1995. 2374 [2] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 2375 ACM Computer Communications Review, 19(2), March 1989. 2377 [3] Jim Bound and Charles Perkins. Dynamic Host Configuration 2378 Protocol for IPv6 (DHCPv6). Internet-Draft, 2379 draft-ietf-dhc-dhcpv6-10.txt, May 1997. Work in progress. 2381 [4] Alex Conta and Stephen Deering. Generic packet 2382 tunneling in IPv6 specification. Internet-Draft, 2383 draft-ietf-ipngwg-ipv6-tunnel-07.txt, December 1996. 2384 Work in progress. 2386 [5] Stephen E. Deering and Robert M. Hinden. Internet Protocol 2387 version 6 (IPv6) specification. RFC 1883, December 1995. 2389 [6] Paul Ferguson, editor. Network ingress filtering: Defeating 2390 IP source address spoofing denial of service attacks. 2391 Internet-Draft, draft-ferguson-ingress-filtering-02.txt, July 2392 1997. Work in progress. 2394 [7] P. Mockapetris. Domain Names---concepts and facilities. 2395 RFC 1034, November 1987. 2397 [8] P. Mockapetris. Domain Names---implementation and 2398 specification. RFC 1035, November 1987. 2400 [9] Thomas Narten, Erik Nordmark, and William Allen Simpson. 2401 Neighbor Discovery for IP version 6 (IPv6). RFC 1970, August 2402 1996. 2404 [10] Charles Perkins. IP encapsulation within IP. RFC 2003, October 2405 1996. 2407 [11] Charles Perkins, editor. IP mobility support. RFC 2002, 2408 October 1996. 2410 [12] Charles Perkins. Minimal encapsulation within IP. RFC 2004, 2411 October 1996. 2413 [13] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 2415 [14] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 2416 September 1981. 2418 [15] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 2419 October 1994. 2421 [16] Susan Thomson and Thomas Narten. IPv6 stateless address 2422 autoconfiguration. RFC 1971, August 1996. 2424 Chair's Address 2426 The Working Group can be contacted via its current chairs: 2428 Jim Solomon 2429 Motorola, Inc. 2430 1301 E. Algonquin Rd. 2431 Schaumburg, IL 60196 2432 USA 2434 Phone: +1 847 576-2753 2435 E-mail: solomon@comm.mot.com 2437 Erik Nordmark 2438 Sun Microsystems, Inc. 2439 2550 Garcia Avenue 2440 Mt. View, CA 94041 2441 USA 2443 Phone: +1 415 786-5166 2444 Fax: +1 415 786-5896 2445 E-mail: nordmark@sun.com 2447 Authors' Addresses 2449 Questions about this document can also be directed to the authors: 2451 David B. Johnson 2452 Carnegie Mellon University 2453 Computer Science Department 2454 5000 Forbes Avenue 2455 Pittsburgh, PA 15213-3891 2456 USA 2458 Phone: +1 412 268-7399 2459 Fax: +1 412 268-5576 2460 E-mail: dbj@cs.cmu.edu 2462 Charles Perkins 2463 Sun Microsystems, Inc. 2464 Technology Development Group 2465 Mail Stop MPK15-214 2466 Room 2682 2467 901 San Antonio Road 2468 Palo Alto, CA 94303 2469 USA 2471 Phone: +1 415 786-6464 2472 Fax: +1 415 786-6445 2473 E-mail: cperkins@eng.sun.com