idnits 2.17.1 draft-ietf-mobileip-ipv6-02.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 273: '... MUST...' RFC 2119 keyword, line 278: '... MUST NOT...' RFC 2119 keyword, line 283: '... SHOULD...' RFC 2119 keyword, line 290: '... SHOULD NOT...' RFC 2119 keyword, line 298: '... MAY...' (180 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 (26 November 1996) is 10007 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-07 == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-ipv6-tunnel-02 ** Obsolete normative reference: RFC 1883 (ref. '5') (Obsoleted by RFC 2460) -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-04 -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 1970 (ref. '8') (Obsoleted by RFC 2461) -- Unexpected draft version: The latest known version of draft-ietf-ipsec-ah-hmac-md5 is -03, but you're referring to -04. ** Obsolete normative reference: RFC 793 (ref. '11') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '12') (Obsoleted by RFC 3232) == Outdated reference: A later version (-07) exists of draft-teraoka-ipv6-mobility-sup-03 -- Possible downref: Normative reference to a draft: ref. '13' ** Obsolete normative reference: RFC 1971 (ref. '14') (Obsoleted by RFC 2462) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 IBM Corporation 5 26 November 1996 7 Mobility Support in IPv6 9 11 Abstract 13 This document specifies the operation of mobile computers using IPv6. 14 Each mobile node is always identified by its home address, regardless 15 of its current point of attachment to the Internet. While situated 16 away from its home, a mobile node is also associated with a care-of 17 address, which provides information about the mobile node's current 18 location. IPv6 packets addressed to a mobile node's home address are 19 transparently routed to its care-of address. The protocol enables 20 IPv6 nodes to cache the binding of a mobile node's home address with 21 its care-of address, and to then send packets destined for the mobile 22 node directly to it at this care-of address. 24 Status of This Memo 26 This document is a submission by the Mobile IP Working Group of the 27 Internet Engineering Task Force (IETF). Comments should be submitted 28 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 29 Distribution of this memo is unlimited. 31 This document is an Internet-Draft. Internet-Drafts are working 32 documents of the Internet Engineering Task Force (IETF), its areas, 33 and its working groups. Note that other groups may also distribute 34 working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at 38 any time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 To learn the current status of any Internet-Draft, please check 42 the "1id-abstracts.txt" listing contained in the Internet-Drafts 43 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 44 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 45 ftp.isi.edu (US West Coast). 47 Contents 49 Abstract i 51 Status of This Memo 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 62 4. New IPv6 Destination Options 11 63 4.1. Binding Update Option . . . . . . . . . . . . . . . . . . 11 64 4.2. Binding Acknowledgement Option . . . . . . . . . . . . . 14 65 4.3. Binding Request Option . . . . . . . . . . . . . . . . . 17 67 5. Requirements for IPv6 Nodes 18 69 6. Correspondent Node Operation 20 70 6.1. Receiving Binding Updates . . . . . . . . . . . . . . . . 20 71 6.2. Requests to Cache a Binding . . . . . . . . . . . . . . . 21 72 6.3. Requests to Delete a Binding . . . . . . . . . . . . . . 21 73 6.4. Sending Binding Acknowledgements . . . . . . . . . . . . 21 74 6.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 22 75 6.6. Receiving ICMP Error Messages . . . . . . . . . . . . . . 23 76 6.7. Sending Packets to a Mobile Node . . . . . . . . . . . . 24 78 7. Home Agent Operation 26 79 7.1. Primary Care-of Address Registration . . . . . . . . . . 26 80 7.2. Primary Care-of Address De-registration . . . . . . . . . 28 81 7.3. Tunneling Intercepted Packets to a Mobile Node . . . . . 28 82 7.4. Renumbering the Home Subnet . . . . . . . . . . . . . . . 29 84 8. Mobile Node Operation 31 85 8.1. Movement Detection . . . . . . . . . . . . . . . . . . . 31 86 8.2. Forming New Care-of Addresses . . . . . . . . . . . . . . 33 87 8.3. Sending Binding Updates to the Home Agent . . . . . . . . 34 88 8.4. Sending Binding Updates to Correspondent Nodes . . . . . 35 89 8.5. Sending Binding Updates to the Previous Default Router . 37 90 8.6. Retransmitting Binding Updates . . . . . . . . . . . . . 37 91 8.7. Rate Limiting for Sending Binding Updates . . . . . . . . 38 92 8.8. Receiving Binding Acknowledgements . . . . . . . . . . . 38 93 8.9. Using Multiple Care-of Addresses . . . . . . . . . . . . 39 94 8.10. Returning Home . . . . . . . . . . . . . . . . . . . . . 39 96 9. Routing Multicast Packets 41 98 10. Constants 42 100 11. Security Considerations 43 102 Acknowledgements 44 104 A. Open Issues 45 105 A.1. Session Keys with Local Routers . . . . . . . . . . . . . 45 106 A.2. Source Address Filtering by Firewalls . . . . . . . . . . 45 107 A.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 46 108 A.4. Replay Protection for Binding Updates . . . . . . . . . . 46 110 References 47 112 Chair's Address 49 114 Authors' Addresses 50 115 1. Introduction 117 This document specifies the operation of mobile computers using 118 Internet Protocol Version 6 (IPv6) [5]. Without specific support for 119 mobility in IPv6, packets destined to a mobile node (host or router) 120 would not be able to reach it while the mobile node is away from its 121 home IPv6 subnet, since routing is based on the network prefix in a 122 packet's destination IP address. In order continue communication 123 in spite of its movement, a mobile node could change its IP address 124 each time it moves to a new IPv6 subnet, but the mobile node would 125 then not be able to maintain transport and higher-layer connections 126 when it changes location. Mobility support in IPv6 is particularly 127 important, as mobile computers are likely to account for a majority 128 or at least a substantial fraction of the population of the Internet 129 during the lifetime of IPv6. 131 The protocol operation defined here, known as Mobile IPv6, allows a 132 mobile node to move from one IPv6 subnet to another without changing 133 the mobile node's IP address. A mobile node is always addressable 134 by its "home address", the IP address assigned to the mobile node 135 within its home IPv6 subnet. Packets may be routed to it using this 136 address regardless of the mobile node's current point of attachment 137 to the Internet, and the mobile node may continue to communicate with 138 other nodes (stationary or mobile) after moving to a new subnet. 139 The movement of a mobile node away from its home subnet is thus 140 transparent to transport and higher-layer protocols and applications. 142 The Mobile IPv6 protocol is just as suitable for mobility across 143 homogeneous media as for mobility across heterogeneous media. For 144 example, Mobile IPv6 facilitates node movement from one Ethernet 145 segment to another as well as it accommodates node movement from an 146 Ethernet segment to a wireless LAN cell, as long as the mobile node's 147 IP address remains unchanged after such a movement. 149 One can think of the Mobile IPv6 protocol as solving the "macro" 150 mobility management problem. More "micro" mobility management 151 applications -- for example, handoff amongst wireless transceivers, 152 each of which covers only a very small geographic area, are possibly 153 more suited to other solutions. For example, as long as node 154 movement does not occur between link-level points of attachment on 155 different IPv6 subnets, link-layer mobility support offered by a 156 number of current wireless LAN products is likely to offer faster 157 convergence and lower overhead than Mobile IPv6. Extensions to the 158 Mobile IPv6 protocol are also possible to support a more local, 159 hierarchical form of handoff, but such extensions are beyond the sope 160 of this document. 162 2. Terminology 164 2.1. General Terms 166 IP 168 Internet Protocol Version 6 (IPv6). 170 node 172 A device that implements IP. 174 router 176 A node that forwards IP packets not explicitly addressed to 177 itself. 179 host 181 Any node that is not a router. 183 link 185 A communication facility or medium over which nodes can 186 communicate at the link layer, such as an Ethernet (simple or 187 bridged). A link is the layer immediately below IP. 189 interface 191 A node's attachment to a link. 193 network prefix 195 A bit string that consists of some number of initial bits of an 196 IP address. 198 link-layer address 200 A link-layer identifier for an interface, such as IEEE 802 201 addresses on Ethernet links. 203 packet 205 An IP header plus payload. 207 2.2. Mobile IPv6 Terms 209 home address 211 An IP address assigned to a mobile node within its home subnet. 212 The network prefix in a mobile node's home address is equal to 213 the network prefix of the home subnet. 215 home subnet 217 The IP subnet indicated by a mobile node's home address. 218 Standard IP routing mechanisms will deliver packets destined 219 for a mobile node's home address to its home subnet. 221 mobile node 223 A node that can change its link-level point of attachment from 224 one IP subnet to another, while still being addressable via its 225 home address. 227 movement 229 A change in a mobile node's point of attachment to the Internet 230 such that it is no longer link-level connected to the same IP 231 subnet as it was previously. If a mobile node is not currently 232 link-level connected to its home subnet, the mobile node is 233 said to be "away from home". 235 correspondent node 237 A peer with which a mobile node is communicating. The 238 correspondent node may be either mobile or stationary. 240 foreign subnet 242 Any IP subnet other than the mobile node's home subnet. 244 home agent 246 A router on a mobile node's home subnet with which the mobile 247 node has registered its current care-of address. While the 248 mobile node is away from home, the home agent intercepts 249 packets on the home subnet destined to the mobile node's home 250 address, encapsulates them, and tunnels them to the mobile 251 node's registered care-of address. 253 care-of address 255 An IP address associated with a mobile node while visiting 256 a foreign subnet, which uses the network prefix of that 257 foreign subnet. Among the multiple care-of addresses that a 258 mobile node may have at a time (e.g., with different network 259 prefixes), the one registered with its home agent is called its 260 "primary" care-of address. 262 binding 264 The association of the home address of a mobile node with a 265 care-of address for that mobile node, along with the remaining 266 lifetime of that association. 268 2.3. Specification Language 270 In this document, several words are used to signify the requirements 271 of the specification. These words are often capitalized. 273 MUST 275 This word, or the adjective "REQUIRED", means that the 276 definition is an absolute requirement of the specification. 278 MUST NOT 280 This phrase means that the definition is an absolute 281 prohibition of the specification. 283 SHOULD 285 This word, or the adjective "RECOMMENDED", means that there may 286 exist valid reasons in particular circumstances to ignore a 287 particular item, but the full implications must be understood 288 and carefully weighed before choosing a different course. 290 SHOULD NOT 292 This phrase means that there may exist valid reasons in 293 particular circumstances when the particular behavior is 294 acceptable or even useful, but the full implications should be 295 understood and the case carefully weighed before implementing 296 any behavior described with this label. 298 MAY 300 This word, or the adjective "OPTIONAL", means that an item 301 is truly optional. For example, one vendor may choose to 302 include the item because a particular marketplace requires 303 it or because the vendor feels that it enhances the product, 304 while another vendor may omit the same item. An implementation 305 which does not include a particular option MUST be prepared to 306 interoperate with another implementation which does include the 307 option. 309 silently discard 311 The implementation discards the packet without further 312 processing, and without indicating an error to the sender. The 313 implementation SHOULD provide the capability of logging the 314 error, including the contents of the discarded packet, and 315 SHOULD record the event in a statistics counter. 317 3. Overview of Mobile IPv6 Operation 319 A mobile node is always addressable by its home address, whether it 320 is currently attached to its home subnet or is away from home. While 321 a mobile node is at home, packets addressed to the mobile node's 322 home address are routed to it using conventional Internet routing 323 mechanisms in the same way as if the node were never mobile. Since 324 the network prefix of a mobile node's home address is equal to the 325 network prefix of its home subnet, packets addressed to it will be 326 routed to its home subnet. 328 While a mobile node is attached to some foreign subnet away from 329 home, it is also addressable by one or more care-of addresses, in 330 addition to its home address. A care-of address is an IP address 331 associated with a mobile node only while visiting a particular 332 foreign subnet. The network prefix of a care-of address being used 333 by a mobile node is equal to the network prefix of the foreign 334 subnet to which the mobile node is link-level connected, and thus 335 packets addressed to this care-of address will be routed to the 336 mobile node's location away from home. The association between 337 a mobile node's home address and care-of address is known as a 338 "binding" for the mobile node. A mobile node typically acquires its 339 care-of address through stateless [14] or stateful (e.g., DHCPv6 [3]) 340 address autoconfiguration, according to the methods of IPv6 Neighbor 341 Discovery [8], although other methods of acquiring a care-of address 342 are also possible. 344 While away from home, the mobile node registers one of its binding 345 with a router in its home subnet, requesting this router to function 346 as the "home agent" for the mobile node. The care-of address in this 347 binding registered with its home agent is known as the mobile node's 348 "primary care-of address". The mobile node's home agent thereafter 349 uses proxy Neighbor Discovery to intercept any IPv6 packets addressed 350 to the mobile node's home address on the home subnet, and tunnels 351 each intercepted packet to the mobile node's primary care-of address. 352 To tunnel each intercepted packet, the home agent encapsulates the 353 packet using IPv6 encapsulation [4], addressed to the mobile node's 354 primary care-of address. 356 Mobile IPv6 provides a mechanism for IPv6 nodes communicating with 357 a mobile node, to dynamically learn and cache the mobile node's 358 binding. When sending a packet to any IPv6 destination, a node 359 checks its cached bindings for an entry for the packet's destination 360 address. If a cached binding for this destination address is 361 found, the node uses an IPv6 Routing header [5] (instead of IPv6 362 encapsulation) to route the packet to the mobile node through the 363 care-of address indicated in this binding. If, instead, the sending 364 node has no cached binding for this destination address, the node 365 sends the packet normally (with no Routing header), and the packet 366 is subsequently intercepted and tunneled by the mobile node's home 367 agent as described above. A node communicating with a mobile node is 368 referred to in this document as a "correspondent node" of the mobile 369 node. 371 A mobile node's home agent and correspondent nodes learn and 372 cache the mobile node's binding through use of a set of new IPv6 373 destination options [5] defined for Mobile IPv6. Since an IPv6 374 Destination Options header containing one or more destination options 375 can appear in any IPv6 packet, any Mobile IPv6 option can be sent in 376 either of two ways: 378 - A Mobile IPv6 option can be included within any IPv6 packet 379 carrying any payload such as TCP [11] or UDP [10]. 381 - A Mobile IPv6 option can be sent as a separate IPv6 packet 382 containing no payload. In this case, the Next Header field 383 in the Destination Options header is set to the value 59, to 384 indicate "No Next Header" [5]. 386 The following three new IPv6 destination options are defined for 387 Mobile IPv6: 389 Binding Update 391 A Binding Update is used by a mobile node to notify a 392 correspondent node or its home agent of its current binding. 393 The Binding Update sent to the mobile node's home agent is 394 marked as a "home registration". Any packet that includes a 395 Binding Update option MUST also include an IPv6 Authentication 396 header [1]. The Binding Update option is described in detail 397 in Section 4.1. 399 Binding Acknowledgement 401 A Binding Acknowledgement is used to acknowledge receipt of 402 a Binding Update, if an acknowledgement was requested in the 403 Binding Update. Other Binding Updates MAY be acknowledged 404 but need not be. Any packet that includes a Binding 405 Acknowledgement option MUST also include an IPv6 Authentication 406 header [1]. The Binding Acknowledgement option is described in 407 detail in Section 4.2. 409 Binding Request 411 A Binding Request is used to request a mobile node to send a 412 Binding Update to this node, containing its current binding. 414 This option is typically used by a correspondent node to 415 refresh a cached binding for a mobile node, when the lifetime 416 on this cached binding is close to expiration. The Binding 417 Request option is described in detail in Section 4.3. 419 Extensions to the format of these options may be included after the 420 fixed portion of the option data specified in this document. The 421 presence of such extensions will be indicated by the Option Length 422 field within the option. When the Option Length is greater than the 423 length required for the option specified here, the remaining octets 424 are interpreted as extensions. Currently, no extensions have been 425 defined. 427 This document describes the Mobile IPv6 protocol in terms of the 428 following two conceptual data structures used in the maintenance of 429 cached bindings: 431 Binding Cache 433 A cache, maintained by each IPv6 node, of bindings for other 434 nodes. An entry in a node's binding cache for which the node 435 is serving as a home agent is marked as a "home registration" 436 entry and SHOULD NOT be deleted by the home agent until the 437 expiration of its binding lifetime, whereas other Binding Cache 438 entries MAY be replaced at any time by any reasonable local 439 cache replacement policy. The Binding Cache MAY be implemented 440 in any manner consistent with the external behavior described 441 in this document, for example by being combined with the node's 442 Destination Cache as maintained through Neighbor Discovery [8]. 444 Binding Update List 446 A list, maintained by each mobile node, recording information 447 for each Binding Update sent by this mobile node, for which 448 the Lifetime of the binding sent in that Update has not yet 449 expired. For each such Binding Update, the Binding Update List 450 records the IP address of the node to which the Update was 451 sent, the home address for which the Update was sent, and the 452 remaining lifetime of the binding. The Binding Update List 453 MAY be implemented in any manner consistent with the external 454 behavior described in this document. 456 When a mobile node configures a new care-of address and decides to 457 use this new address as its primary care-of address, the mobile 458 node registers this new binding with its home agent by sending 459 the home agent a Binding Update. The mobile node indicates 460 that an acknowledgement is needed for this Binding Update and 461 continues to periodically retransmit it until acknowledged. The 462 home agent acknowledges the Binding Update by returning a Binding 463 Acknowledgement to the mobile node. 465 When a mobile node receives a packet tunneled to it from its 466 home agent, the mobile node assumes that the original sending 467 correspondent node has no binding cache entry for the mobile node, 468 since the correspondent node would otherwise have sent the packet 469 directly to the mobile node using a Routing header. The mobile node 470 thus returns a Binding Update to the correspondent node, allowing 471 it to cache the mobile node's binding for routing future packets. 472 Although the mobile node may request an acknowledgement for this 473 Binding Update, it need not, since subsequent packets from the 474 correspondent node will continue to be intercepted and tunneled by 475 the mobile node's home agent, effectively causing any needed Binding 476 Update retransmission. 478 A correspondent node with a binding cache entry for a mobile node 479 may refresh this binding, for example if the binding's lifetime 480 is near expiration, by sending a Binding Request to the mobile 481 node. Normally, a correspondent node will only refresh a binding 482 cache entry in this way if it is actively communicating with the 483 mobile node and has indications, such as an open TCP connection to 484 the mobile node, that it will continue this communication in the 485 future. When a mobile node receives a Binding Request, it replies by 486 returning a Binding Update to the node sending the Binding Request. 488 A mobile node may use more than one care-of address at the same time, 489 although only one care-of address may be registered for it at its 490 home agent as its primary care-of address. The mobile node's home 491 agent will tunnel all intercepted packets for the mobile node to its 492 registered primary care-of address, but the mobile node will accept 493 packets that it receives at any of its current care-of addresses. 494 Use of more than one care-of address by a mobile node may be useful, 495 for example, to improve smooth handoff when the mobile node moves 496 from one wireless IP subnet to another. If each wireless subnet is 497 connected to the Internet through a separate base station, such that 498 the wireless transmission range from the two base stations overlap, 499 the mobile node may be able to remain link-level connected within 500 both subnets while in the area of overlap. In this case, the mobile 501 node could acquire a new care-of address in the new subnet before 502 moving out of transmission range and link-level disconnecting from 503 the old subnet. The mobile node may thus still accept packets at 504 its old care-of address while it works to update its home agent and 505 correspondent nodes, notifying them of its new care-of address. 507 Since correspondent nodes cache bindings, it is expected that 508 correspondent nodes usually will route packets directly to the mobile 509 node's care-of address, so that the home agent is rarely involved 510 with packet transmission to the mobile node. This is essential for 511 scalability and reliability, and for minimizing overall network load. 512 By caching the care-of address of a mobile node, optimal routing of 513 packets can be achieved from the correspondent node to the mobile 514 node. Routing packets directly to the mobile node's care-of address 515 also eliminates congestion at the mobile node's home agent and home 516 subnet. In addition, the impact of of any possible failure of the 517 home agent, the home subnet, or intervening networks leading to the 518 home subnet is reduced, since these nodes and links are not involved 519 in the delivery of most packets to the mobile node. 521 4. New IPv6 Destination Options 523 4.1. Binding Update Option 525 The Binding Update destination option is used by a mobile node to 526 notify a correspondent node or its home agent of a new care-of 527 address. 529 The Binding Update option is encoded in type-length-value (TLV) 530 format as follows: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Option Type | Option Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |A|H|L| Reserved | Lifetime | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Identification | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 + + 543 | | 544 + Care-of Address + 545 | | 546 + + 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | | 550 + + 551 | | 552 + Home Link-Local Address + 553 | (only present if L bit set) | 554 + + 555 | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Option Type 560 192 ??? 562 Option Length 564 8-bit unsigned integer. Length of the option, in octets, 565 excluding the Option Type and Option Length fields. For the 566 current definition of the Binding Update option, this field 567 MUST be set to 24 if the Home Link-Local Address Present (L) 568 bit is not set, and MUST otherwise be set to 40. 570 Acknowledge (A) 572 The Acknowledge (A) bit is set by the sending node to request a 573 Binding Acknowledgement (Section 4.2) be returned upon receipt 574 of the Binding Update option. 576 Home Registration (H) 578 The Home Registration (H) bit is set by the sending node to 579 request the receiving node to act as this node's home agent. 580 The Destination Address in the IP header of the packet carrying 581 this option MUST be that of a router sharing the same network 582 prefix as the home address of the mobile node in the binding. 584 Home Link-Local Address Present (L) 586 The Home Link-Local Address Present (L) bit indicates the 587 presence of the Home Link-Local Address field in the Binding 588 Update. This bit is set by the sending node to request 589 the receiving node to act as a proxy (for participating in 590 the Neighbor Discovery Protocol) for the node while it is 591 away from home. This bit MUST NOT be set unless the Home 592 Registration (H) bit is also set in the Binding Update. 594 Reserved 596 Sent as 0; ignored on reception. 598 Lifetime 600 16-bit unsigned integer. The number of seconds remaining 601 before the binding must be considered expired. A value of all 602 ones (0xffff) indicates infinity. A value of zero indicates 603 that the Binding Cache entry for the mobile node should be 604 deleted. 606 Identification 608 a 32-bit number used by the receiving node to sequence Binding 609 Updates, and by the sending node to match a returned Binding 610 Acknowledgement message with this Binding Update. 612 Care-of Address 614 The care-of address of the mobile node for this binding. When 615 set equal to the home address of the mobile node, the Binding 616 Update option instead indicates that any existing binding for 617 the mobile node should be deleted; no binding for the mobile 618 node should be created in this case. 620 Home Link-Local Address 622 The link-local address of the mobile node used by the mobile 623 node when it was last attached to its home subnet. This field 624 in the Binding Update is optional and is only present when the 625 Home Link-Local Address (L) bit is set. 627 The home address of the mobile node in the binding is indicated by 628 the Source Address field in the IP header of the packet containing 629 the Binding Update option. 631 Any packet that includes a Binding Update option MUST include an IPv6 632 Authentication header [1] in order to protect against forged Binding 633 Updates. 635 The three highest-order bits of the Option Type are encoded to 636 indicate specific processing of the option [5]. For the Binding 637 Update option, these three bits are set to 110, indicating that the 638 data within the option cannot change en-route to the packet's final 639 destination, and that any IPv6 node processing this option that does 640 not recognize the Option Type must discard the packet and, only if 641 the packet's Destination Address was not a multicast address, return 642 an ICMP Parameter Problem, Code 2, message to the packet's Source 643 Address. 645 Extensions to the Binding Update option format may be included after 646 the fixed portion of the Binding Update option specified above. The 647 presence of such extensions will be indicated by the Option Length 648 field. When the Option Length is greater than 24 octets if the Home 649 Link-Local Address (L) bit is not set, or greater than 40 octets if 650 the Home Link-Local Address (L) bit is set, the remaining octets 651 are interpreted as extensions. Currently, no extensions have been 652 defined. 654 4.2. Binding Acknowledgement Option 656 The Binding Acknowledgement destination option is used to acknowledge 657 receipt of a Binding Update option (Section 4.1). When a node 658 receives a Binding Update addressed to itself, in which the 659 Acknowledge (A) bit set, it MUST return a Binding Acknowledgement. 661 The Binding Acknowledgement option is encoded in type-length-value 662 (TLV) format as follows: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Option Type | Option Length | Status | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Refresh | Lifetime | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Identification | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Option Type 676 193 ??? 678 Option Length 680 8-bit unsigned integer. Length of the option, in octets, 681 excluding the Option Type and Option Length fields. For the 682 current definition of the Binding Acknowledgement option, this 683 field MUST be set to 8. 685 Status 687 8-bit unsigned integer indicating the disposition of the 688 Binding Update. Values of the Status field less than 128 689 indicate that the Binding Update was accepted by the receiving 690 node. The following such Status values are currently defined: 692 0 Binding Update accepted 694 Values of the Status field greater than or equal to 128 695 indicate that the Binding Update was rejected by the receiving 696 node. The following such Status values are currently defined: 698 128 Reason unspecified 699 129 Poorly formed Binding Update 700 130 Administratively prohibited 701 131 Insufficient resources 702 132 Home registration not supported 703 133 Not home subnet 704 134 Identification field mismatch 705 135 Unknown home agent address 707 Up-to-date values of the Status field are to be specified in 708 the most recent "Assigned Numbers" [12]. 710 Refresh 712 The recommended period at which the mobile node should send 713 a new Binding Update to this node in order to "refresh" the 714 mobile node's binding in this node's binding cache, in case 715 the node fails and loses its cache state. The Refresh period 716 is determined by the node sending the Binging Acknowledgement 717 (the node caching the binding). If this node is serving as the 718 mobile node's home agent, the Refresh value may be set, for 719 example, based on whether the node stores the mobile node's 720 binding in volatile storage or in nonvolatile storage. If the 721 node sending the Binding Acknowledgement is not serving as the 722 mobile node's home agent, the Refresh period SHOULD be set 723 equal to the Lifetime period in the Binding Acknowledgement; 724 even if this node loses this cache entry due to a failure of 725 the node, packets from it can still reach the mobile node 726 through the mobile node's home agent, causing a new Binding 727 Update to this node to allow it to recreate this cache entry. 729 Lifetime 731 The granted lifetime for which this node will attempt to retain 732 the entry for this mobile node in its binding cache. If the 733 node sending the Binding Acknowledgement is serving as the 734 mobile node's home agent, the Lifetime period also indicates 735 the period for which this node will continue this service; if 736 the mobile node requires home agent service from this node 737 beyond this period, the mobile node MUST send a new Binding 738 Update to it before the expiration of this period to extend the 739 lifetime. 741 Identification 743 The acknowledgement Identification is copied from the Binding 744 Update option, for use by the mobile node in matching the 745 acknowledgement with an outstanding Binding Update. 747 Any packet that includes a Binding Acknowledgement option MUST 748 include an IPv6 Authentication header [1] in order to protect against 749 forged Binding Acknowledgements. 751 If the node returning the Binding Acknowledgement accepted the 752 Binding Update for which the Acknowledgement is being returned (the 753 value of the Status field in the Acknowledgement is less than 128), 754 this node will have an entry for the mobile node in its Binding 755 Cache, and MUST use this entry (which includes the care-of address 756 received in the Binding Update) in sending the packet containing the 757 Binding Acknowledgement to the mobile node. The details of sending 758 this packet to the mobile node are the same as for sending any packet 759 to a mobile node using a Binding Cache entry, and are described in 760 Section 6.7. The packet is sent using a Routing header, routing the 761 packet to the mobile node through its care-of address recorded in the 762 Binding Cache entry. 764 If the node returning the Binding Acknowledgement instead 765 rejected the Binding Update (the value of the Status field in the 766 Acknowledgement is greater than or equal to 128), this node MUST 767 similarly use a Routing header in sending the packet containing the 768 Binding Acknowledgement, as described in Section 6.7, but MUST NOT 769 use its Binding Cache in forming the IP header or Routing header 770 in this packet. Rather, the care-of address used by this node in 771 sending the packet containing the Binding Acknowledgement MUST be 772 copied from the care-of address received in the rejected Binding 773 Update; this node MUST NOT modify its Binding Cache in response 774 to receiving this rejected Binding Update and MUST ignore its 775 Binding Cache in sending the packet in which it returns this Binding 776 Acknowledgement. The packet is sent using a Routing header, routing 777 the packet to the Source Address of the rejected Binding Update 778 through the care-of address indicated in the Binding Update. 780 The three highest-order bits of the Option Type are encoded to 781 indicate specific processing of the option [5]. For the Binding 782 Acknowledgement option, these three bits are set to 110, indicating 783 that the data within the option cannot change en-route to the 784 packet's final destination, and that any IPv6 node processing this 785 option that does not recognize the Option Type must discard the 786 packet and, only if the packet's Destination Address was not a 787 multicast address, return an ICMP Parameter Problem, Code 2, message 788 to the packet's Source Address. 790 Extensions to the Binding Acknowledgement option format may be 791 included after the fixed portion of the Binding Acknowledgement 792 option specified above. The presence of such extensions will be 793 indicated by the Option Length field. When the Option Length is 794 greater than 8 octets, the remaining octets are interpreted as 795 extensions. Currently, no extensions have been defined. 797 4.3. Binding Request Option 799 The Binding Request destination option is used to request a mobile 800 node's binding from the mobile node. When a mobile node receives 801 a packet containing a Binding Request option, it SHOULD return a 802 Binding Update (Section 4.1) to that node. 804 The Binding Request option is encoded in type-length-value (TLV) 805 format as follows: 807 0 1 808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Option Type | Option Length | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Option Type 815 194 ??? 817 Option Length 819 8-bit unsigned integer. Length of the option, in octets, 820 excluding the Option Type and Option Length fields. For the 821 current definition of the Binding Acknowledgement option, this 822 field MUST be set to 0. 824 The three highest-order bits of the Option Type are encoded to 825 indicate specific processing of the option [5]. For the Binding 826 Request option, these three bits are set to 110, indicating that the 827 data within the option cannot change en-route to the packet's final 828 destination, and that any IPv6 node processing this option that does 829 not recognize the Option Type must discard the packet and, only if 830 the packet's Destination Address was not a multicast address, return 831 an ICMP Parameter Problem, Code 2, message to the packet's Source 832 Address. 834 Extensions to the Binding Request option format may be included after 835 the fixed portion of the Binding Request option specified above. 836 The presence of such extensions will be indicated by the Option 837 Length field. When the Option Length is greater than 0 octets, 838 the remaining octets are interpreted as extensions. Currently, no 839 extensions have been defined. 841 5. Requirements for IPv6 Nodes 843 Mobile IPv6 places some special requirements on the functions 844 provided by different IPv6 nodes. This section summarizes those 845 requirements, identifying the functionality each requirement is 846 intended to support. Further details on this functionality is 847 provided in the following sections. 849 Since any IPv6 node may at any time be a correspondent node of a 850 mobile node, the following requirements pertain to all IPv6 nodes: 852 - Every IPv6 node SHOULD be able to process a received Binding 853 Update option, and to return a Binding Acknowledgement message if 854 requested. 856 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 857 bindings received in accepted Binding Updates. 859 In order for a mobile node to operate correctly while away from 860 home, at least one IPv6 router in the mobile node's home subnet must 861 function as a home agent for the mobile node. The following special 862 requirements pertain to all IPv6 routers capable of serving as a home 863 agent: 865 - Every home agent MUST be able to maintain a registry of mobile 866 node bindings, recording each mobile node's primary care-of 867 address, for those mobile nodes for which it is serving as the 868 home agent. 870 - Every home agent MUST be able to intercept packets (using proxy 871 Neighbor Discovery) on the local subnet addressed to a mobile 872 node for which it is currently serving as the home agent while 873 that mobile node is away from home. 875 - Every home agent MUST be able to encapsulate such intercepted 876 packets in order to tunnel them to the primary care-of address 877 for the mobile node indicated in its binding. 879 - Every home agent MUST be able to return Binding Acknowledgements 880 in response to Binding Updates received from a mobile node. 882 Finally, the following requirements pertain all IPv6 nodes capable of 883 functioning as mobile nodes: 885 - Every IPv6 mobile node MUST be able to perform IPv6 886 decapsulation [4]. 888 - Every IPv6 mobile node MUST support sending Binding Updates, as 889 specified in Sections 8.3, 8.4, and 8.5; and MUST be able to 890 receive and process Binding Acknowledgements, as specified in 891 Section 8.8. 893 - Every IPv6 mobile node MUST maintain a Binding Update List in 894 which it records the IP address of each other node to which it 895 has sent a Binding Update, for which the Lifetime sent in that 896 binding has not yet expired. 898 6. Correspondent Node Operation 900 A correspondent node is any node communicating with a mobile node. 901 The correspondent node, itself, may be fixed or mobile, and may 902 possibly also be functioning as a home agent for Mobile IPv6. The 903 procedures in this section thus apply to all IPv6 nodes. 905 6.1. Receiving Binding Updates 907 Upon receiving a Binding Update option in some packet, the receiving 908 node MUST validate the packet according to the following tests: 910 - The packet contains an IP Authentication header and the 911 authentication is valid [1]. The Authentication header is 912 assumed to provide both authentication and integrity protection. 914 - The Option Length field in the option is greater than or equal to 915 24 octets if the Home Link-Local Address (L) bit is not set, or 916 greater or equal to 40 octets if the Home Link-Local Address (L) 917 bit is set. 919 - The Identification field is valid. 921 Any Binding Update not satisfying all of these tests MUST be silently 922 ignored, although the remainder of the packet (i.e., other options, 923 extension headers, or payload) SHOULD be processed normally according 924 to any procedure defined for that part of the packet. 926 If the Binding Update is valid according to the tests above, then the 927 Binding Update is processed further as follows: 929 - If the Lifetime specified in the Binding Update is nonzero and 930 the specified Care-of Address is not equal to the Source Address 931 in the IP header of the packet carrying the Binding Update, 932 then this is a request to cache a binding for the mobile node 933 (the home address of the mobile node is specified by the Source 934 Address field in the packet's IP header). Processing for this 935 type of received Binding Update is described in Section 6.2. 937 - If the Lifetime specified in the Binding Update is zero or the 938 specified Care-of Address matches the Source Address field in the 939 IP header of the packet carrying the Binding Update, then this is 940 a request to delete the mobile node's binding (as above, the home 941 address of the mobile node is specified by the Source Address 942 field in the packet's IP header). Processing for this type of 943 received Binding Update is described in Section 6.3. 945 6.2. Requests to Cache a Binding 947 If a node receives a valid Binding Update requesting it to cache a 948 binding for a mobile node, as specified in Section 6.1, then the node 949 MUST examine the Home Registration (H) bit in the Binding Update 950 to determine how to further process the Binding Update. If the 951 Home Registration (H) bit is set, the Binding Update is processed 952 according to the procedure specified in Section 7.1. 954 If the Home Registration (H) bit is not set, then the receiving node 955 SHOULD create a new entry in its Binding Cache for this mobile node 956 (or update its existing Binding Cache entry for this mobile node, if 957 such an entry already exists). The home address of the mobile node 958 is taken from the Source Address field in the packet's IP header. 959 The new Binding Cache entry records the association between this 960 address and the Care-of Address specified in the Binding Update. 961 The node must also begin a timer to delete this Binding Cache entry 962 after the expiration of the Lifetime period specified in the Binding 963 Update. 965 6.3. Requests to Delete a Binding 967 If a node receives a valid Binding Update requesting it to delete 968 a binding for a mobile node, as specified in Section 6.1, then the 969 node MUST examine the Home Registration (H) bit in the Binding Update 970 to determine how to further process the Binding Update. If the 971 Home Registration (H) bit is set, the Binding Update is processed 972 according to the procedure specified in Section 7.2. 974 If the Home Registration (H) bit is not set, then the receiving node 975 MUST delete any existing entry in its Binding Cache for this mobile 976 node. The home address of the mobile node is taken from the Source 977 Address field in the packet's IP header. 979 6.4. Sending Binding Acknowledgements 981 When any node receives a packet containing a Binding Update option 982 in which the Acknowledge (A) bit is set, it SHOULD return a Binding 983 Acknowledgement message acknowledging receipt of the Binding 984 Update. If the node accepts the Binding Update and adds the binding 985 contained in it to its Binding Cache, the Status field in the 986 Binding Acknowledgement MUST be set to a value less than 128; if 987 the node rejects the Binding Update and does not add the binding 988 contained in it to its Binding Cache, the Status field in the Binding 989 Acknowledgement MUST be set to a value greater than or equal to 128. 991 Specific values for the Status field are described in Section 4.2 and 992 in the most recent "Assigned Numbers" [12]. 994 As described in Section 4.2, the packet in which the Binding 995 Acknowledgement is returned MUST include an IPv6 Authentication 996 header [1] in order to protect against forged Binding 997 Acknowledgements, and the packet MUST be sent using a Routing 998 header through the care-of address contained in the Binding Update 999 being acknowledged. This ensures that the Binding Acknowledgement 1000 will be routed to the current location of the node sending the 1001 Binding Update, whether the Binding Update was accepted or rejected. 1003 6.5. Cache Replacement Policy 1005 Any entry in a node's Binding Cache MUST be deleted after the 1006 expiration of the Lifetime specified in the Binding Update from which 1007 the entry was created or was last updated. Conceptually, a node 1008 maintains a separate timer for each entry in its Binding Cache. When 1009 creating or updating a Binding Cache entry in response to a received 1010 and accepted Binding Update, the node sets the timer for this entry 1011 to the specified Lifetime period. When a Binding Cache entry's timer 1012 expires, the node deletes the entry. 1014 Each node's Binding Cache will, by necessity, have a finite size. 1015 A node MAY use any reasonable local policy for managing the space 1016 within its Binding Cache, except that any entry marked as a "home 1017 registration" (Section 7.1) MUST NOT be deleted from the cache until 1018 the expiration of its lifetime period. When attempting to add a new 1019 "home registration" entry in response to a Binding Update with the 1020 Home Registration (H) bit set, if insufficient space exists (or can 1021 be reclaimed) in the node's Binding Cache, the node MUST reject the 1022 Binding Update and SHOULD return a Binding Acknowledgement message 1023 to the sending mobile node, in which the Status field is set to 131 1024 (Insufficient resources). When otherwise attempting to add a new 1025 entry to its Binding Cache, a node MAY, if needed, choose to drop any 1026 entry already in its Binding Cache, other than a "home registration" 1027 entry, in order to make space for the new entry. For example, a 1028 "least-recently used" (LRU) strategy for cache entry replacement is 1029 likely to work well. 1031 If a packet is sent by a node to a destination for which it has 1032 dropped the cache entry from its Binding Cache, the packet will be 1033 routed normally, leading to the mobile node's home subnet. There, 1034 the packet will be intercepted by the mobile node's home agent and 1035 tunneled to the mobile node's current primary care-of address. As 1036 when a Binding Cache entry is initially created, this indirect 1037 routing to the mobile node through its home agent will result in the 1038 mobile node sending a Binding Update to this sending node, allowing 1039 this node to add an entry again for this destination to its Binding 1040 Cache. 1042 6.6. Receiving ICMP Error Messages 1044 When a correspondent node sends a packet to a mobile node, if the 1045 correspondent node has a Binding Cache entry for the destination 1046 mobile node's address (its home address), then the correspondent 1047 node uses a Routing header to deliver the packet to the mobile node 1048 through the care-of address recorded in the Binding Cache entry. Any 1049 ICMP error message caused by the packet on its way to the mobile node 1050 will be returned normally to the correspondent node. 1052 On the other hand, if the correspondent node has no Binding Cache 1053 entry for the mobile node, the packet will be routed to the mobile 1054 node's home subnet, where it will be intercepted by the mobile node's 1055 home agent, encapsulated, and tunneled to the mobile node's care-of 1056 address. Any ICMP error message caused by the packet on its way to 1057 the mobile node while in the tunnel, will be returned to the mobile 1058 node's home agent (the source of the tunnel) By the definition of 1059 IPv6 encapsulation [4], this encapsulating node MUST relay certain 1060 ICMP error messages back to the original sender of the packet, which 1061 in this case is the correspondent node. 1063 Likewise, if a packet for a mobile node arrives at the mobile node's 1064 previous default router (e.g., the mobile node moved after the packet 1065 was sent), the router will encapsulate and tunnel the packet to the 1066 mobile node's new care-of address (if it has a Binding Cache entry 1067 for the mobile node). As above, any ICMP error message caused by the 1068 packet while in this tunnel will be returned to the previous default 1069 router (the source of the tunnel), which MUST relay certain ICMP 1070 error messages back to the correspondent node [4]. 1072 Thus, in all cases, any meaningful ICMP error messages caused by 1073 packets from a correspondent node to a mobile node will be returned 1074 to the correspondent node. If the correspondent node receives 1075 persistent ICMP Host Unreachable or Network Unreachable error 1076 messages after sending packets to a mobile node based on an entry in 1077 its Binding Cache, the correspondent node SHOULD delete this Binding 1078 Cache entry. If the correspondent node subsequently transmits 1079 another packet to the mobile node, the packet will be routed to the 1080 mobile node's home subnet, intercepted by the mobile node's home 1081 agent, and tunneled to the mobile node's care-of address using IPv6 1082 encapsulation. The mobile node will then return a Binding Update to 1083 the correspondent node, allowing it to recreate a (correct) Binding 1084 Cache entry for the mobile node. 1086 6.7. Sending Packets to a Mobile Node 1088 Before sending any packet, the sending node SHOULD examine its 1089 Binding Cache for an entry for the destination address to which the 1090 packet is being sent. If the sending node has a Binding Cache entry 1091 for this address, the sending node SHOULD use a Routing header to 1092 route the packet to this mobile node (the destination node) through 1093 the care-of address recorded in that Binding Cache entry. For 1094 example, assuming use of a Type 0 Routing header [5], if no other use 1095 of a Routing header is involved in the routing of this packet, the 1096 mobile node sets the following fields in the packet's IP header and 1097 Routing header as indicated below: 1099 - The Destination Address in the packet's IP header is set to the 1100 mobile node's care-of address copied from the Binding Cache 1101 entry. 1103 - The Routing header is initialized to contain a single route 1104 segment, with an Address of the mobile node's home address (the 1105 original destination address to which the packet was being sent). 1107 Following the definition of a Type 0 Routing header [5], this packet 1108 will routed to the mobile node's care-of address, where it will be 1109 delivered to the mobile node (the mobile node has associated the 1110 care-of address with its network interface). Normal processing of 1111 the Routing header by the mobile node will then proceed as follows: 1113 - The mobile node swaps the Destination Address in the packet's IP 1114 header and the Address specified in the Routing header. This 1115 results in the packet's IP Destination Address being set to the 1116 mobile node's home address. 1118 - The mobile node then resubmits the packet to its IPv6 module for 1119 further processing. Since the mobile node recognizes its own 1120 home address as one if its current IP addresses, the packet is 1121 processed further within the mobile node, in the same way then as 1122 if the mobile node was at home. 1124 If, instead, the sending node has no Binding Cache entry for the 1125 destination address to which the packet is being sent, the sending 1126 node simply sends the packet normally, with no Routing header. If 1127 the destination node is not a mobile node (or is a mobile node that 1128 is currently at home), the packet will be delivered directly to this 1129 node and processed normally by it. If, however, the destination node 1130 is a mobile node that is currently away from home, the packet will 1131 be intercepted by the mobile node's home agent and tunneled (using 1132 IPv6 encapsulation [4]) to the mobile node's current primary care-of 1133 address, as described in Section 7.3. The mobile node will then send 1134 a Binding Update to the sending node, as described in Section 8.4, 1135 allowing the sending node to create a Binding Cache entry for its use 1136 in sending subsequent packets to this mobile node. 1138 7. Home Agent Operation 1140 7.1. Primary Care-of Address Registration 1142 General processing of a received Binding Update that requests a 1143 binding to be cached, is described in Section 6.2. However, if the 1144 Home Registration (H) bit is set in the Binding Update, then the 1145 receiving node MUST process the Binding Update as specified in this 1146 section, rather than following the general procedure specified in 1147 Section 6.2. 1149 To begin processing the Binding Update, the home agent MUST perform 1150 the following sequence of tests: 1152 - If the node is not a router that implements home agent 1153 functionality, then the node MUST reject the Binding Update and 1154 SHOULD return a Binding Acknowledgement message to the mobile 1155 node, in which the Status field is set to 132 (Home registration 1156 not supported). 1158 - Else, if the home address for the binding in the Binding Update 1159 (the Source Address in the packet's IP header) is not an on-link 1160 IPv6 address with respect to the home agent's current Prefix 1161 List, then the home agent MUST reject the Binding Update and 1162 SHOULD return a Binding Acknowledgement message to the mobile 1163 node, in which the Status field is set to 133 (Not home subnet). 1165 - Else, if the home agent chooses to reject the Binding Update for 1166 any other reason (e.g., insufficient resources to serve another 1167 mobile node as a home agent), then the home agent SHOULD return 1168 a Binding Acknowledgement message to the mobile node, in which 1169 the Status field is set to an appropriate value to indicate the 1170 reason for the rejection. 1172 If the home agent does not reject the Binding Update as described 1173 above, then it becomes the home agent for the mobile node. The new 1174 home agent (the receiving node) MUST then create a new entry or 1175 update the existing entry in its Binding Cache for this mobile node's 1176 home address, as described in Section 6.2. In addition, the home 1177 agent MUST mark this Binding Cache entry as a "home registration" 1178 to indicate that the node is serving as a home agent for this 1179 binding. Binding Cache entries marked as a "home registration" MUST 1180 be excluded from the normal cache replacement policy used for the 1181 Binding Cache (Section 6.5) and MUST NOT be removed from the Binding 1182 Cache until the expiration of the Lifetime period. 1184 If the home agent was not already serving as a home agent for this 1185 mobile node (the home agent did not already have a Binding Cache 1186 entry for this address marked as a "home registration"), then the 1187 home agent MUST multicast onto the home subnet (to the all-nodes 1188 multicast address) a Neighbor Advertisement message [8] on behalf 1189 of the mobile node, to advertise the home agent's own link-layer 1190 address for the mobile node's home IP address. The Target Address in 1191 the Neighbor Advertisement message MUST be set to the mobile node's 1192 home address, and the Advertisement MUST include a Target Link-layer 1193 Address option specifying the home agent's link-layer address. The 1194 Solicited Flag (S) in the Advertisement MUST NOT be set, since it was 1195 not solicited by any Neighbor Solicitation message. The Override 1196 Flag (O) in the Advertisement MUST be set, indicating that the 1197 Advertisement SHOULD override any existing Neighbor Cache entry at 1198 any node receiving it. 1200 Any node on the home subnet receiving this Neighbor Advertisement 1201 message will thus update its Neighbor Cache to associate the mobile 1202 node's home address with the home agent's link layer address, causing 1203 it to transmit future packets for the mobile node instead to the 1204 mobile node's home agent. Since multicasts on the local link (such 1205 as Ethernet) are typically not guaranteed to be reliable, the home 1206 agent MAY retransmit this Neighbor Advertisement message up to 1207 MAX_ADVERT_REXMIT times to increase its reliability. It is still 1208 possible that some nodes on the home subnet will not receive any of 1209 these Neighbor Advertisements, but these nodes will eventually be 1210 able to detect the link-layer address change for the mobile node's 1211 home address, through use of Neighbor Unreachability Detection [8]. 1213 In addition, while this node is serving as a home agent to this 1214 mobile node (it still has a "home registration" entry for this mobile 1215 node in its Binding Cache), it MUST act as a proxy for this mobile 1216 node to reply to any received Neighbor Solicitation messages for it. 1217 When a home agent receives a Neighbor Solicitation message, it MUST 1218 check if the Target Address specified in the message matches the home 1219 address of any mobile node for which it has a Binding Cache entry 1220 marked as a "home registration". If such an entry exists in its 1221 Binding Cache, the home agent MUST reply to the Neighbor Solicitation 1222 message with a Neighbor Advertisement message, giving the home 1223 agent's own link-layer address as the link-layer address for the 1224 specified Target Address. Likewise, if the mobile node included its 1225 home link-local address and set the Home Link-Local Address (L) bit 1226 in its Binding Update with which it registered with its home agent, 1227 its home agent MUST also similarly act as a proxy for the mobile 1228 node's home link-local address while it has a "home registration" 1229 entry in its Binding Cache for the mobile node. Acting as a proxy 1230 in this way allows other nodes on the mobile node's home subnet to 1231 resolve the mobile node's IPv6 home address and IPv6 link-local 1232 address, and allows the home agent to to defend these addresses on 1233 the home subnet for Duplicate Address Detection [8]. 1235 7.2. Primary Care-of Address De-registration 1237 General processing of a received Binding Update that requests a 1238 binding to be deleted, is described in Section 6.3. However, if the 1239 Home Registration (H) bit is set in the Binding Update, then the 1240 receiving node MUST process the Binding Update as specified in this 1241 section, rather than following the general procedure specified in 1242 Section 6.3. 1244 To begin processing the Binding Update, the home agent MUST perform 1245 the following sequence of tests: 1247 - If the node is not a router that implements home agent 1248 functionality, then the node MUST reject the Binding Update and 1249 SHOULD return a Binding Acknowledgement message to the mobile 1250 node, in which the Status field is set to 132 (Home registration 1251 not supported). 1253 - Else, if the home address for the binding in the Binding Update 1254 (the Source Address in the packet's IP header) is not an on-link 1255 IPv6 address with respect to the home agent's current Prefix 1256 List, then it MUST reject the Binding Update and SHOULD return a 1257 Binding Acknowledgement message to the mobile node, in which the 1258 Status field is set to 133 (Not home subnet). 1260 If the home agent does not reject the Binding Update as described 1261 above, then it MUST delete any existing entry in its Binding Cache 1262 for this mobile node. 1264 In addition, the home agent MUST multicast a Neighbor Advertisement 1265 message (to the all-nodes multicast address), giving the mobile 1266 node's home address as the Target Address, and specifying the mobile 1267 node's link-layer address in a Target Link-layer Address option in 1268 the Neighbor Advertisement message. The home agent MAY retransmit 1269 this Neighbor Advertisement message up to MAX_ADVERT_REXMIT times 1270 to increase its reliability; any nodes on the home subnet that miss 1271 all of these Neighbor Advertisements can also eventually detect the 1272 link-layer address change for the mobile node's home address, through 1273 use of Neighbor Unreachability Detection [8]. 1275 7.3. Tunneling Intercepted Packets to a Mobile Node 1277 For any packet sent to a mobile node from the mobile node's home 1278 agent, for which the home agent is the original sender of the packet, 1279 the home agent is operating as a correspondent node of the mobile 1280 node for this packet and the procedures described in Section 6.7 1281 apply. The home agent uses a Routing header to route the packet 1282 to the mobile node through the care-of address in the home agent's 1283 Binding Cache (the mobile node's primary care-of address, in this 1284 case). 1286 In addition, while the mobile node is away from home and this node 1287 is acting as the mobile node's home agent, the home agent intercepts 1288 any packets on the home subnet addressed to the mobile node's 1289 home address, as described in Section 7.1. The home agent cannot 1290 use a Routing header to forward these intercepted packets to the 1291 mobile node, since it cannot modify the packet in flight without 1292 invalidating any existing IPv6 Authentication header present in the 1293 packet [1]. 1295 For forwarding each intercepted packet to the mobile node, the 1296 home agent MUST tunnel the packet to the mobile node using IPv6 1297 encapsulation [4]; the tunnel entry point node is the home agent, 1298 and the tunnel exit point node is the mobile node itself (using its 1299 primary care-of address as registered with the home agent). When a 1300 home agent encapsulates an intercepted packet for forwarding to the 1301 mobile node, the home agent sets the Source Address in the prepended 1302 tunnel IP header to its own IP address, and sets the Destination 1303 Address in the tunnel IP header to the mobile node's primary care-of 1304 address. When received by the mobile node (using its primary care-of 1305 address), normal processing of the tunnel header [4] will result in 1306 decapsulation and processing of the original packet by the mobile 1307 node. 1309 7.4. Renumbering the Home Subnet 1311 Neighbor Discovery [8] specifies a mechanism by which all nodes on a 1312 subnet can gracefully autoconfigure new addresses, say by each node 1313 combining a new routing prefix with its existing link-layer address. 1314 As currently specified, this mechanism works when the nodes are on 1315 the same link as the router issuing the necessary multicast packets 1316 to advertise the new routing prefix(es) appropriate for the link. 1318 However, for mobile nodes away from home, special care must be taken 1319 to allow the mobile nodes to renumber gracefully. The most direct 1320 method of ensuring this is for the home agent to encapsulate and 1321 tunnel the multicast packets to the primary care-of address of each 1322 mobile node for which it is serving as the home agent. The rules for 1323 this are as follows: 1325 - A mobile node assumes that its routing prefix has not changed 1326 unless it receives authenticated Router Advertisement messages 1327 from its home agent that the prefix has changed. 1329 - When the mobile node is at home, the home agent does not tunnel 1330 Router Advertisements to it. 1332 - The mobile node's home agent serves as a proxy for the mobile 1333 node's home address and link-local address, including defending 1334 these addresses for Duplicate Address Detection, while the mobile 1335 node is registered with the home agent away from home. 1337 - When a home subnet prefix changes, the home agent tunnels Router 1338 Advertisement packets to each mobile node which is currently 1339 away from home and using a home address with the affected 1340 routing prefix. Such tunneled Router Advertisements MUST be 1341 authenticated [1]. 1343 - When a mobile node receives a tunneled Router Advertisement 1344 containing a new routing prefix, it must perform the standard 1345 autoconfiguration operation to create its new address 1347 - When a mobile node returns to its home subnet, it must again 1348 perform Duplicate Address Detection at the earliest possible 1349 moment after it has registered with its home agent. 1351 - A mobile node may send a Router Solicitation to its home agent at 1352 any time, within the constraints imposed by rate control in the 1353 Neighbor Discovery specification [8] 1355 8. Mobile Node Operation 1357 8.1. Movement Detection 1359 A mobile node MAY use any combination of mechanisms available to 1360 it to detect when its link-level point of attachment has moved 1361 from one IP subnet to another. The primary movement detection 1362 mechanism for Mobile IPv6 defined here uses the facilities of 1363 IPv6 Neighbor Discovery, including Router Discovery and Neighbor 1364 Unreachability Detection. The description here is based on the 1365 conceptual model of the organization and data structures defined by 1366 Neighbor Discovery [8]. 1368 Mobile nodes SHOULD use Router Discovery to discover new routers and 1369 on-link network prefixes; a mobile node MAY send Router Solicitation 1370 messages, or MAY wait for unsolicited (periodic) Router Advertisement 1371 messages, as specified for Router Discovery [8]. Based on received 1372 Router Advertisement messages, a mobile node (in the same way as any 1373 other node) maintains an entry in its Default Router List for each 1374 router, and an entry in its Prefix List for each network prefix, that 1375 it currently considers to be on-link. Each entry in these lists has 1376 an associated invalidation timer value (extracted from the Router 1377 Advertisement) used to expire the entry when it becomes invalid. 1379 While away from home, a mobile node SHOULD select one router from its 1380 Default Router List to use as its default router, and one network 1381 prefix advertised by that router from its Prefix List to use as 1382 the network prefix in its primary care-of address. A mobile node 1383 MAY also have associated additional care-of addresses, using other 1384 network prefixes from its Prefix List. The method by which a mobile 1385 node selects and forms a care-of address from the available network 1386 prefixes is described in Section 8.2. The mobile node registers 1387 its primary care-of address with its home agent, as described in 1388 Section 8.3. 1390 While away from home and using some router as its default router, 1391 it is important for a mobile node to be able to quickly detect when 1392 that router becomes unreachable, so that it can switch to a new 1393 default router and to a new primary care-of address. Since some 1394 links (notably wireless) do not necessarily work equally well in both 1395 directions, it is likewise important for the mobile node to detect 1396 when it becomes unreachable to its default router, so that the mobile 1397 node can take steps to ensure that any correspondent nodes attempting 1398 to communicate with the it can still reach it through some other 1399 route. 1401 To detect when its default router becomes unreachable, a mobile 1402 node SHOULD use Neighbor Unreachability Detection. As specified in 1403 Neighbor Discovery [8], while the mobile node is actively sending 1404 packets to (or through) its default router, the mobile node can 1405 detect that the router is still reachable either through indications 1406 from upper layer protocols on the mobile node that a connection is 1407 making "forward progress" (e.g., receipt of TCP acknowledgements for 1408 new data transmitted), or through receipt of a Neighbor Advertisement 1409 message form its default router in response to an explicit Neighbor 1410 Solicitation messages to it. Note that although this mechanism only 1411 detects that the mobile node's default router has become unreachable 1412 to the mobile node while the mobile node is actively sending packets 1413 to it, this is the only time that this direction of reachability 1414 confirmation is needed. Confirmation that the mobile node is still 1415 reachable from the router is handled separately, as described below. 1417 For a mobile node to detect when it has become unreachable to its 1418 default router, however, the mobile node cannot efficiently rely on 1419 Neighbor Unreachability Detection alone, since the network overhead 1420 would be prohibitively high in many cases for a mobile node to 1421 continually probe its default router with Neighbor Solicitation 1422 messages even when it is not otherwise actively sending packets to 1423 it. Instead, a mobile node SHOULD consider receipt of any IPv6 1424 packets from its current default router as an indication that it is 1425 still reachable from the router. Both packets from the router's IP 1426 address and (IPv6) packets from its link-layer address (e.g., those 1427 forwarded but not originated by the router) SHOULD be considered. 1429 Since the router SHOULD be sending periodic multicast Router 1430 Advertisement messages, the mobile node will have frequent 1431 opportunity to check if it is still reachable to its default router, 1432 even in the absence of other packets to it from the router. On some 1433 types of network interfaces, the mobile node MAY also supplement this 1434 by setting its network interface into "promiscuous" receive mode, 1435 so that it is able to receive all packets on the link, including 1436 those not link-level addressed to it. The mobile node will then 1437 be able to detect any packets sent by the router, in order to to 1438 detect reachability from the router. This may be useful on very low 1439 bandwidth (e.g., wireless) links, but its use MUST be configurable on 1440 the mobile node. 1442 If the above means do not provide indication that the mobile node 1443 is still reachable from its current default router (i.e., the 1444 mobile node receives no packets form the router for a period of 1445 time), then the mobile node SHOULD actively probe the router with 1446 Neighbor Solicitation messages, even if it is not otherwise actively 1447 sending packets to the router. If it receives a solicited Neighbor 1448 Advertisement message in response from the router, then the mobile 1449 node can deduce that it is still reachable. It is expected that the 1450 mobile node will in most cases be able to determine its reachability 1451 from the router by listening for packets from the router as described 1452 above, and thus, such extra Neighbor Solicitation probes should 1453 rarely be necessary. 1455 With some types of networks, it is possible that additional 1456 indications about link-layer mobility can be obtained from 1457 lower-layer protocol or device driver software within the mobile 1458 node. However, a mobile node MUST NOT assume that all link-layer 1459 mobility indications from lower layers indicate a movement of the 1460 mobile node's link-layer connection to a new IP subnet, such that the 1461 mobile node would need to switch to a new default router and primary 1462 care-of address. Upon lower-layer indication of link-layer mobility, 1463 the mobile node SHOULD send Router Solicitation messages to determine 1464 if new routers (and new on-link network prefixes) are present on its 1465 new link. 1467 Such lower-layer information might also be useful to a mobile node in 1468 deciding to switch its primary care-of address to one of the other 1469 care-of addresses it has formed from the on-link network prefixes 1470 currently available through different default routers from which the 1471 mobile node is reachable. For example, a mobile node MAY use signal 1472 strength or signal quality information (with suitable hysteresis) 1473 for its link with the available default routers to decide when to 1474 switch to a new primary care-of address using that default router 1475 rather than its current default router (and current primary care-of 1476 address). Even though the mobile node's current default router may 1477 still be reachable in terms of Neighbor Unreachability Detection, the 1478 mobile node MAY use such lower-layer information to determine that 1479 switching to a new default router would provide a better connection. 1481 8.2. Forming New Care-of Addresses 1483 After detecting that its link-layer point of attachment has moved 1484 from one IPv6 subnet to another (i.e., its current default router 1485 has become unreachable and it has discovered a new default router), 1486 a mobile node SHOULD form a new primary care-of address using one of 1487 the on-link network prefixes advertised by the new router. A mobile 1488 node MAY form a new primary care-of address at any time, except 1489 that it MUST NOT do so too frequently (not more often than once per 1490 MAX_UPDATE_RATE seconds). 1492 In addition, after discovering a new on-link network prefix, a 1493 mobile node MAY form a new (non-primary) care-of address using that 1494 network prefix, even when it has not switched to a new default 1495 router. A mobile node can have only one primary care-of address 1496 at a time (registered with its home agent), but it MAY have an 1497 additional care-of address for each network prefix on its current 1498 link. Furthermore, since a wireless network interface may actually 1499 allow a mobile node to be reachable on more than one link at a time 1500 (i.e., within wireless transmitter range of routers on more than one 1501 separate link), a mobile node MAY have care-of addresses on more than 1502 one link at a time. The use of more than one care-of address at a 1503 time is described in Section 8.9. 1505 As described in Section 3, in order to form a new care-of address, 1506 a mobile node MAY use either stateless [14] or stateful (e.g., 1507 DHCPv6 [3]) address autoconfiguration. If a mobile node needs to 1508 send packets as part of the method of address autoconfiguration, 1509 it MUST use an IPv6 link-local address rather than its own IPv6 1510 home address as the Source Address in the IP header of each such 1511 autoconfiguration packet. 1513 In some cases, a mobile node may already know a (constant) IPv6 1514 address that has been assigned to it for its use only while visiting 1515 a specific foreign subnet. For example, a mobile node may be 1516 statically configured with an IPv6 address assigned by the system 1517 administrator of some foreign subnet, for its use while visiting that 1518 subnet. If so, rather than using address autoconfiguration to form 1519 a new care-of address using this network prefix, the mobile node 1520 SHOULD use its own pre-assigned address as its care-of address on 1521 this subnet. 1523 8.3. Sending Binding Updates to the Home Agent 1525 After deciding to change its primary care-of address as described 1526 in Sections 8.1 and 8.2, a mobile node MUST register this care-of 1527 address with its home agent in order to make this its primary care-of 1528 address. To do so, the mobile node sends a packet to its home agent 1529 containing a Binding Update option with the Home Registration (H) 1530 bit is set in the Binding Update. The mobile node also sets the 1531 Acknowledge (A) bit in the Binding Update, requesting the home 1532 agent to return a Binding Acknowledgement message in response to 1533 this Binding Update. As described in Section 4.2, the mobile node 1534 SHOULD retransmit this Binding Update to its home agent until it 1535 receives a matching Binding Acknowledgement message. Once reaching a 1536 retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile node 1537 SHOULD continue to periodically retransmit the Binding Update at this 1538 rate until acknowledged (or until it begins attempting to register a 1539 different primary care-of address). 1541 8.4. Sending Binding Updates to Correspondent Nodes 1543 A mobile node MAY send a Binding Update to any correspondent node at 1544 any time (subject to the rate limiting defined in Section 8.7). In 1545 any Binding Update sent by a mobile node, the Care-of Address field 1546 MUST be set to one of the care-of addresses currently in use by the 1547 mobile node or to the mobile node's home address. If set to one of 1548 the mobile node's current care-of addresses (the care-of address 1549 given MAY differ from the mobile node's primary care-of address), the 1550 Binding Update requests the correspondent node to create or update 1551 a an entry for the mobile node in the correspondent node's Binding 1552 Cache to record this care-of address for use in sending future 1553 packets to the mobile node. If, instead, the Care-of Address field 1554 is set to the mobile node's home address, the Binding Update requests 1555 the correspondent node to delete any existing Binding Cache entry 1556 that it has for the mobile node. A mobile node MAY set the Care-of 1557 Address field differently for sending Binding Updates to different 1558 correspondent nodes. 1560 When sending any Binding Update, the mobile node MUST record in its 1561 Binding Update List the following fields from the Binding Update: 1563 - The IP address of the node to which the Binding Update was sent. 1565 - The home address for which the Binding Update was sent, 1567 - The remaining lifetime of the binding, initialized from the 1568 Lifetime field of the Binding Update. 1570 The mobile node MUST retain in its Binding Update List information 1571 about all Binding Updates sent, for which the lifetime of the 1572 binding has not yet expired. When sending a Binding Update, if an 1573 entry already exists in the mobile node's Binding Update List for 1574 an earlier Binding Update sent to that same destination node, the 1575 existing Binding Update List is updated to reflect the new Binding 1576 Update rather than creating a new Binding Update List entry. 1578 In general, when a mobile node sends a Binding Update to its home 1579 agent to register a new primary care-of address (as described in 1580 Section 8.3), the mobile node will also typically send a Binding 1581 Update to each correspondent node for which an entry exists in the 1582 mobile node's Binding Update List. Thus, correspondent nodes are 1583 generally kept updated and can send almost all packets directly to 1584 the mobile node using the mobile node's current binding. 1586 The mobile node, however, need not send these Binding Updates 1587 immediately after configuring a new care-of address. For example, 1588 since the Binding Update is a destination option and can be included 1589 in any packet sent by a mobile node, the mobile node MAY delay 1590 sending a new Binding Update to any correspondent node for a 1591 short period of time, in hopes that the needed Binding Update 1592 can be included in some packet that the mobile node sends to that 1593 correspondent node for some other reason (for example, as part of 1594 some TCP connection in use). In this case, when sending a packet 1595 to some correspondent node, the mobile node SHOULD check in its 1596 Binding Update List to determine if a new Binding Update to this 1597 correspondent node is needed, and SHOULD include the new Binding 1598 Update in this packet as necessary. 1600 In addition, when a mobile node receives a packet for which the 1601 mobile node can deduce that the original sender of the packet has no 1602 Binding Cache entry for the mobile node, or for which the mobile node 1603 can deduce that the original sender of the packet has an out-of-date 1604 care-of address in its Binding Cache entry for the mobile node, the 1605 mobile node SHOULD return a Binding Update to the sender giving its 1606 current care-of address. In particular, the mobile node SHOULD 1607 return a Binding Update in response to receiving a packet that meets 1608 all of the following tests: 1610 - The packet was tunneled using IPv6 encapsulation. 1612 - The Destination Address in the tunnel (outer) IP header is equal 1613 to any of the mobile node's care-of addresses. 1615 - The Destination Address in the original (inner) IP header is 1616 equal to the mobile node's home address. If the original packet 1617 contains a Routing header, the final Address indicated in the 1618 Routing header should be used in this comparison rather than the 1619 Destination Address in the original IP header. 1621 - The Source Address in the tunnel (outer) IP header differs from 1622 the Source Address in the original (inner) IP header. 1624 The destination address to which the Binding Update should be sent in 1625 response to receiving a packet meeting all of the tests above, is the 1626 Source Address in the original (inner) IP header of the packet. 1628 Binding Updates sent to correspondent nodes are not generally 1629 required to be acknowledged. However, if the mobile node wants to be 1630 sure that its new care-of address has been added to a correspondent 1631 node's Binding Cache, the mobile node MAY request an acknowledgement 1632 by setting the Acknowledge (A) bit in the Binding Update. In this 1633 case, however, the mobile node SHOULD NOT continue to retransmit the 1634 Binding Update once the retransmission timeout period has reached 1635 MAX_BINDACK_TIMEOUT. 1637 A mobile node MAY choose to keep its location private from certain 1638 correspondent nodes, and thus need not send new Binding Updates to 1639 those correspondents. A mobile node MAY also send a Binding Update 1640 to such a correspondent node to instruct it to delete any existing 1641 binding for the mobile node from its Binding Cache, as described in 1642 Section 4.1. No other IPv6 nodes are authorized to send Binding 1643 Updates on behalf of a mobile node. 1645 8.5. Sending Binding Updates to the Previous Default Router 1647 After switching to a new default router (and thus also changing 1648 its primary care-of address), a mobile node SHOULD send a Binding 1649 Update message to its previous default router, giving its new care-of 1650 address. If the mobile node sends such a Binding Update, the Source 1651 Address in the packet carrying this Binding Update MUST be set the 1652 mobile node's old primary care-of address (that it used while using 1653 this default router), and the Care-of Address field MUST be set to 1654 the mobile node's new primary care-of address. In addition, the Home 1655 Registration (H) bit MUST also be set in this Binding Update, to 1656 request the mobile node's previous default router to temporarily act 1657 as a home agent for the mobile node's old primary care-of address. 1658 Note that the previous router does not necessarily know the mobile 1659 node's home address as part of this sequence of events. 1661 If any subsequent packets arrive at this previous router for 1662 forwarding to the mobile node's old primary care-of address, 1663 the router SHOULD encapsulate each such packet (using IPv6 1664 encapsulation [4]) and tunnel it to the mobile node at its new 1665 primary care-of address. Moreover, for the lifetime of the "home 1666 registration" Binding Cache entry at this router, this router MUST 1667 act as a proxy for the mobile node's previous care-of address, 1668 for purposes of participation in Neighbor Discovery [8], in the 1669 same way as any home agent does for a mobile node's home address 1670 (Section 7.1). This allows the router to intercept packets addressed 1671 to the mobile node's previous care-of address, and to encapsulate and 1672 tunnel them to the mobile node's new care-of address, as described in 1673 Section 7.3. 1675 8.6. Retransmitting Binding Updates 1677 If, after sending a Binding Update in which the Acknowledge (A) 1678 bit is set, a mobile node fails to receive an acceptable Binding 1679 Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the 1680 mobile node SHOULD retransmit the Binding Update until a Binding 1681 Acknowledgement is received. Such a retransmitted Binding 1682 Update MUST use he same Identification value as the original 1683 transmission. The retransmissions by the mobile node MUST use 1684 an exponential back-off process, in which timeout period is 1685 doubled upon each retransmission until either the node receives a 1686 Binding Acknowledgement or the timeout period reaches the value 1687 MAX_BINDACK_TIMEOUT. 1689 8.7. Rate Limiting for Sending Binding Updates 1691 A mobile node MUST NOT send Binding Updates more often than once per 1692 MAX_UPDATE_RATE seconds to any correspondent node. After sending 5 1693 consecutive Binding Updates to a particular correspondent node with 1694 the same care-of address, the mobile node SHOULD reduce its rate 1695 of sending Binding Updates to that correspondent node, to the rate 1696 of SLOW_UPDATE_RATE per second. The mobile node MAY continue to 1697 send Binding Updates at the slower rate indefinitely, in hopes that 1698 the correspondent node will eventually be able to process a Binding 1699 Update and begin to route its packets directly to the mobile node at 1700 its new care-of address. 1702 8.8. Receiving Binding Acknowledgements 1704 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 1705 node MUST validate the packet according to the following tests: 1707 - The packet contains an IP Authentication header and the 1708 authentication is valid [1]. The Authentication header is 1709 assumed to provide both authentication and integrity protection. 1711 - The Option Length field in the option is greater than or equal to 1712 8 octets. 1714 - The Identification field is valid. 1716 Any Binding Acknowledgement not satisfying all of these tests MUST be 1717 silently ignored, although the remainder of the packet (i.e., other 1718 options, extension headers, or payload) SHOULD be processed normally 1719 according to any procedure defined for that part of the packet. 1721 When a mobile node receives a packet carrying a valid Binding 1722 Acknowledgement, the mobile node MUST examine the Status field as 1723 follows: 1725 - If the Status field indicates that the Binding Update was 1726 accepted (the Status field is less than 128), then the mobile 1727 node MUST update the corresponding entry in its Binding Update 1728 List to indicate that the Binding Update has been acknowledged. 1729 The mobile node MUST thus stop retransmitting the Binding Update. 1731 - If the Status field indicates that the Binding Update was not 1732 accepted (the Status field is greater than or equal to 128), then 1733 the mobile node MUST delete the corresponding Binding Update List 1734 entry. Optionally, the mobile node MAY take steps to correct the 1735 cause of the error and retransmit the Binding Update, subject to 1736 the rate limiting restriction specified in Section 8.7. 1738 8.9. Using Multiple Care-of Addresses 1740 As described in Section 8.2, a mobile node MAY have more than 1741 one care-of address at a time. Particularly in the case of many 1742 wireless networks, a mobile node effectively may be reachable 1743 through multiple link-level points of attachment at the same time 1744 (e.g., with overlapping wireless cells), on which different on-link 1745 network prefixes may exist. A mobile node SHOULD select a primary 1746 care-of address from among those care-of addresses it has formed 1747 using any of these network prefixes, based on the movement detection 1748 mechanism in use (Section 8.1). When the mobile node selects a new 1749 primary care-of address, it MUST register it with its home agent 1750 through a Binding Update message with the Home Registration (H) and 1751 Acknowledge (A) bits set, as described in Section 8.3. 1753 To assist with smooth handoffs, a mobile node SHOULD retain 1754 its previous primary care-of address as a (non-primary) care-of 1755 address, and SHOULD still accept packets at this address, even after 1756 registering its new primary care-of address with its home agent. 1757 This is reasonable, since the mobile node could only receive packets 1758 at its previous primary care-of address if it were indeed still 1759 connected to that link. If the previous primary care-of address 1760 was allocated using stateful address autoconfiguration [3], the 1761 mobile node may not wish to release the address immediately upon 1762 switching to a new primary care-of address. The stateful address 1763 autoconfiguration server will allow mobile nodes to acquire new 1764 addresses while still using previously allocated addresses. 1766 8.10. Returning Home 1768 A mobile node detects that it has returned to its home subnet through 1769 the movement detection algorithm in use (Section 8.1), when the 1770 mobile node detects that the network prefix of its home subnet is 1771 again on-link. The mobile node SHOULD then send a Binding Update to 1772 its home agent, to instruct its home agent to no longer intercept 1773 or tunnel packets for it. In this Binding Update, the mobile node 1774 MUST set the Care-of Address field to its own IPv6 home address. As 1775 with other Binding Updates sent to register with its home agent, the 1776 mobile node MUST set the Acknowledge (A) and Home Registration (H) 1777 bits, and SHOULD retransmit the Binding Update until a matching 1778 Binding Acknowledgement message is received. 1780 In addition, the mobile node MUST multicast onto the home subnet 1781 (to the all-nodes multicast address) a Neighbor Advertisement 1782 message [8], to advertise its link-layer address for its own IPv6 1783 home address. The Target Address in this Neighbor Advertisement 1784 message MUST be set to the mobile node's home address, and the 1785 Advertisement MUST include a Target Link-layer Address option 1786 specifying the mobile node's link-layer address. Similarly, the 1787 mobile node MUST multicast a Neighbor Advertisement message to 1788 advertise its link-layer address for its IPv6 link-local address. 1789 The Solicited Flag (S) in these Advertisements MUST NOT be set, since 1790 they were not solicited by any Neighbor Solicitation message. The 1791 Override Flag (O) in these Advertisements MUST be set, indicating 1792 that the Advertisements SHOULD override any existing Neighbor Cache 1793 entries at any node receiving them. 1795 Since multicasts on the local link (such as Ethernet) are typically 1796 not guaranteed to be reliable, the mobile node MAY retransmit 1797 these Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times 1798 to increase their reliability. It is still possible that some 1799 nodes on the home subnet will not receive any of these Neighbor 1800 Advertisements, but these nodes will eventually be able to recover 1801 through use of Neighbor Unreachability Detection [8]. 1803 9. Routing Multicast Packets 1805 A mobile node that is connected to its home subnet functions in the 1806 same way as any other (stationary) node. Thus, when it is at home, 1807 a mobile node functions identically to other multicast senders and 1808 receivers. This section therefore describes the behavior of a mobile 1809 node that is not on its home subnet. 1811 In order receive packets sent to some multicast group, a mobile node 1812 must join the that multicast group. One method by which a mobile 1813 node MAY join the group is via a (local) multicast router on the 1814 foreign subnet being visited. This option assumes that there is a 1815 multicast router present on the foreign subnet. The mobile node 1816 SHOULD use its care-of address sharing a network prefix with the 1817 multicast router, as the source IPv6 address of its multicast group 1818 membership control message packets. 1820 Alternatively, a mobile node MAY join multicast groups via a 1821 bi-directional tunnel to its home agent, assuming that its home agent 1822 is a multicast router. The mobile node tunnels the appropriate 1823 multicast group membership control packets to its home agent, and the 1824 home agent forwards multicast packets down the tunnel to the mobile 1825 node. The home agent MUST tunnel the packet directly to the mobile 1826 node's primary care-of address. 1828 A mobile node that wishes to send packets to a multicast group 1829 also has two options: (1) send directly on the foreign subnet 1830 being visited; or (2) send via a tunnel to its home agent. Because 1831 multicast routing in general depends upon the Source Address used 1832 in the IP header of the multicast packet, a mobile node that sends 1833 multicast packets directly on the foreign subnet MUST use its 1834 care-of address as the IPv6 Source Address of each multicast packet. 1835 Similarly, a mobile node that tunnels a multicast packet to its home 1836 agent MUST use its home address as the IPv6 Source Address of both 1837 the (inner) multicast packet and the (outer) encapsulating packet. 1838 This second option assumes that the home agent is a multicast router. 1840 10. Constants 1842 INITIAL_BINDACK_TIMEOUT 1 second 1844 MAX_BINDACK_TIMEOUT 256 seconds 1846 MAX_UPDATE_RATE once per second 1848 SLOW_UPDATE_RATE once per 10 seconds 1850 MAX_ADVERT_REXMIT 3 1852 11. Security Considerations 1854 The Binding Update option described in this document will result 1855 in packets addressed to a mobile node being delivered instead to 1856 its care-of address. This ability to change the routing of these 1857 packets could be a significant vulnerability if any packet containing 1858 a Binding Update option was not authenticated. Such use of "remote 1859 redirection", for instance as performed by the Binding Update option, 1860 is widely understood to be a security problem in the current Internet 1861 if not authenticated [2]. 1863 The mobile computing environment is potentially very different from 1864 the ordinary computing environment. In many cases, mobile computers 1865 will be connected to the network via wireless links. Such links 1866 are particularly vulnerable to passive eavesdropping, active replay 1867 attacks, and other active attacks. 1869 Users who have sensitive data that they do not wish others to see 1870 should use mechanisms outside the scope of this document (such as 1871 encryption) to provide appropriate protection. Users concerned about 1872 traffic analysis should consider appropriate use of link encryption. 1873 If absolute location privacy is desired, the mobile node can create a 1874 tunnel to its home agent. Then, packets destined for correspondent 1875 nodes will appear to emanate from the home subnet, and it may be 1876 more difficult to pinpoint the location of the mobile node. Such 1877 mechanisms are all beyond the scope of this document. 1879 Acknowledgements 1881 We would like to thank the members of the Mobile IP and IPng Working 1882 Groups for their comments and suggestions on this draft. We would 1883 particularly like to thank Thomas Narten and Erik Nordmark for 1884 their detailed reviews of earlier versions of this draft. Their 1885 suggestions have helped to improve both the design and presentation 1886 of the protocol. 1888 A. Open Issues 1890 A.1. Session Keys with Local Routers 1892 In the IPv4 route optimization proposal [7], a mechanism is outlined 1893 whereby a session key can be established between foreign agents 1894 and mobile nodes, without requiring any pre-established security 1895 relationship between them. A similar mechanism could be defined for 1896 IPv6, to avoid the need for a possibly time-consuming negotiation 1897 between routers and mobile nodes for the purpose of obtaining the 1898 session key, which under many circumstances would only be used once. 1899 This mechanism, if needed, can be specified completely outside 1900 the Mobile IPv6 protocol and would amount to a way of creating a 1901 dynamic security association between two nodes which do not share an 1902 existing trust relationship, but which need to agree on a key for 1903 some particular purpose (here, allowing the future authentication of 1904 a Binding Update). Hopefully, the work of the IP Security Working 1905 Group will allow this function to be performed appropriately for 1906 mobile nodes, say by a Diffie-Hellman key exchange. 1908 A.2. Source Address Filtering by Firewalls 1910 The current specification does nothing to permit mobile nodes to 1911 send their packets through firewalls which filter out packets with 1912 the "wrong" source IPv6 addresses in the IPv6 packet header. The 1913 mobile node's home address may be unlikely to fall within the ranges 1914 required to satisfy the firewall's criteria for further delivery. 1916 As indicated by recent discussion, firewalls are unlikely to 1917 disappear. Any standardized solution [13] to the firewall problem 1918 based on hiding the non-local source address outside the source 1919 address field of the IP header is likely to fail. Any vendor or 1920 facilities administrator wanting to filter based on the address in 1921 the IPv6 source address field would also quickly begin filtering on 1922 hidden source addresses. 1924 Assume, for the moment, that a mobile node is able to establish a 1925 secure tunnel through a firewall protecting the domain in which 1926 a correspondent node is located. The mobile node could then 1927 encapsulate its packet so that the outer IP header was addressed 1928 to the firewall and used the mobile node's care-of address as the 1929 source address. When the firewall decapsulates, it would be able to 1930 authenticate the inner packet based (correctly) on the mobile node's 1931 home address. After the authentication is performed, the firewall 1932 could forward the packet to the correspondent node as desired. This 1933 simple procedure has the feature that it requires the minimal amount 1934 of encapsulation, no assistance by routers or other agents, and that 1935 the firewall can establish a security relationship with the mobile 1936 node based on its home (i.e., permanent) address. 1938 A.3. Dynamic Home Agent Address Discovery 1940 It is useful for a mobile node to be able to send a Binding Update 1941 its home agent without explicitly knowing the home agent's address. 1942 For example, since the mobile node was last at home, it may have 1943 become necessary to replace the node serving as its home agent due 1944 to the failure of the original node or due to reconfiguration of the 1945 home subnet. It thus may not always be possible or convenient for a 1946 mobile node to know the exact address of its own home agent. Several 1947 methods of allowing a mobile node to dynamically discover the address 1948 of a router in its home subnet are currently under consideration. 1950 A.4. Replay Protection for Binding Updates 1952 Some transforms for use in conjunction with the IP Authentication 1953 Header [1] provide support for replay protection [9, 6]. Ideally, 1954 such transforms would directly support the needs of Mobile IPv6 1955 for providing replay protection for Binding Updates and Binding 1956 Acknowledgements. However, this does not currently appear to be 1957 the case. These transforms provide optional support for accepting 1958 packets out of order, through use of an "out of order window" in the 1959 receiver, and it does not currently seem to be specified how the 1960 size (or presence) of such a window can be controlled. For Binding 1961 Updates, it is important that any packets containing a Binding 1962 Update that arrive at the receiver do so strictly in the order sent 1963 (although some may harmlessly be dropped, as long as a later Binding 1964 Update does arrive). Without control of the window at the receiver, 1965 this ordering requirement on Binding Update delivery cannot be 1966 supported directly by these transforms, although these transforms do 1967 use a sequence number to support their own replay protection. 1969 The Identification field in the Binding Update (and Binding 1970 Acknowledgement) is currently specified in this document for use 1971 in sequencing Binding Updates at the receiver, and in matching 1972 returned Binding Acknowledgements with outstanding Binding Updates 1973 at the sender. The use of this field in this manner, together with 1974 the use of the current IP Authentication transforms that supports 1975 replay protection, seems to support the necessary replay protection 1976 requirements for Mobile IPv6, although it seems that the need for two 1977 sequence numbers in the packet (one for IP Authentication and one for 1978 Mobile IPv6) could be simplified. 1980 References 1982 [1] Randall Atkinson. IP Authentication header. RFC 1826, August 1983 1995. 1985 [2] S. M. Bellovin. Security problems in the TCP/IP protocol suite. 1986 ACM Computer Communications Review, 19(2), March 1989. 1988 [3] Jim Bound and Charles Perkins. Dynamic Host Configuration 1989 Protocol for IPv6 (DHCPv6). Internet-Draft, 1990 draft-ietf-dhc-dhcpv6-07.txt, August 1996. Work in progress. 1992 [4] Alex Conta and Stephen Deering. Generic packet 1993 tunneling in IPv6 specification. Internet-Draft, 1994 draft-ietf-ipngwg-ipv6-tunnel-02.txt, June 1996. Work 1995 in progress. 1997 [5] Stephen E. Deering and Robert M. Hinden. Internet Protocol 1998 version 6 (IPv6) specification. RFC 1883, December 1995. 2000 [6] Shu jen Chang and Robert Glenn. HMAC-SHA IP authentication with 2001 replay prevention. Internet-Draft, 2002 draft-ietf-ipsec-ah-hmac-sha-04.txt, November 1996. Work in 2003 progress. 2005 [7] David B. Johnson and Charles Perkins. Route optimization in 2006 Mobile IP. Internet-Draft, draft-ietf-mobileip-optim-04.txt, 2007 February 1996. Work in progress. 2009 [8] Thomas Narten, Erik Nordmark, and William Allen Simpson. 2010 Neighbor Discovery for IP version 6 (IPv6). RFC 1970, August 2011 1996. 2013 [9] Michael J. Oehler and Robert Glenn. HMAC-MD5 IP 2014 authentication with replay prevention. Internet-Draft, 2015 draft-ietf-ipsec-ah-hmac-md5-04.txt, November 1996. Work in 2016 progress. 2018 [10] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 2020 [11] J. B. Postel, editor. Transmission Control Protocol. RFC 793, 2021 September 1981. 2023 [12] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, 2024 October 1994. 2026 [13] Fumio Teraoka. Mobility support in IPv6. Internet-Draft, 2027 draft-teraoka-ipv6-mobility-sup-03.txt, April 1996. Work in 2028 progress. 2030 [14] Susan Thomson and Thomas Narten. IPv6 stateless address 2031 autoconfiguration. RFC 1971, August 1996. 2033 Chair's Address 2035 The Working Group can be contacted via its current chairs: 2037 Jim Solomon 2038 Motorola, Inc. 2039 1301 E. Algonquin Rd. 2040 Schaumburg, IL 60196 2041 USA 2043 Phone: +1 847 576-2753 2044 E-mail: solomon@comm.mot.com 2046 Erik Nordmark 2047 Sun Microsystems, Inc. 2048 2550 Garcia Avenue 2049 Mt. View, CA 94041 2050 USA 2052 Phone: +1 415 786-5166 2053 Fax: +1 415 786-5896 2054 E-mail: nordmark@sun.com 2056 Authors' Addresses 2058 Questions about this document can also be directed to the authors: 2060 David B. Johnson 2061 Carnegie Mellon University 2062 Computer Science Department 2063 5000 Forbes Avenue 2064 Pittsburgh, PA 15213-3891 2065 USA 2067 Phone: +1 412 268-7399 2068 Fax: +1 412 268-5576 2069 E-mail: dbj@cs.cmu.edu 2071 Charles Perkins 2072 IBM Corporation 2073 T. J. Watson Research Center 2074 Room H3-D34 2075 30 Saw Mill River Rd. 2076 Hawthorne, NY 10532 2077 USA 2079 Phone: +1 914 789-7350 2080 Fax: +1 914 784-6205 2081 E-mail: perk@watson.ibm.com