idnits 2.17.1 draft-perkins-ipv6-mobility-sup-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-26) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** 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. ** There are 2 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** 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 289: '...s binding update MUST set the (A) bit,...' RFC 2119 keyword, line 348: '... home agent MAY shorten the lifetime...' RFC 2119 keyword, line 351: '... time MUST be ignored. When the lif...' RFC 2119 keyword, line 352: '...r binding update SHOULD be sent before...' 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 (8 July 1995) is 10520 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) -- No information found for draft-atkinson-ipng-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 1541 (ref. '3') (Obsoleted by RFC 2131) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-00 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-02) exists of draft-simpson-ipv6-discov-formats-01 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group Charles Perkins 2 INTERNET DRAFT IBM Corporation 3 David B. Johnson 4 Carnegie Mellon University 5 8 July 1995 7 Mobility Support in IPv6 9 11 Abstract 13 This document presents some suggestions for mobility support in 14 IPv6, drawing on the experiences of the authors in our work with 15 IPv4 mobility within the Mobile IP Working Group of the IETF. The 16 development of IPv6 presents a rare opportunity to consider in what 17 ways mobility could explicitly be taken into account in the design of 18 IPv6, and in what ways the current work on mobility within IPv4 can 19 or should be changed to take advantage of IPv6. We believe that the 20 most important function needed to support mobility is the reliable 21 and timely notification of a mobile node's current location to other 22 nodes that need it: the home agent, the correspondent nodes, and its 23 nearest router. 25 Status of This Memo 27 This document is an Internet-Draft. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its areas, 29 and its working groups. Note that other groups and individuals may 30 also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at 34 any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as ``work in progress.'' 37 To learn the current status of any Internet-Draft, please check 38 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 39 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 40 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 41 Rim). 43 1. Introduction 45 A new version of the Internet Protocol, IPv6, is being developed 46 with 128-bit addresses, which remedies many perceived flaws with 47 the existing version (that is, IPv4). This document draws on the 48 experiences of the authors during the design of a set of protocols 49 for the operation of mobile computers for IPv4, in our work within 50 the Mobile IP Working Group of the IETF [4]. Mobile computers are 51 very likely to account for a substantial fraction of the future 52 population of the Internet during the lifetime of IPv6. We expect 53 that the combination of a projected need for mobile computing, and 54 clearly specified features within IPv6 to enable it, should make the 55 necessary operations essentially automatic and universally available. 57 The IETF Mobile IP Working Group's current protocol design for 58 mobility in IPv4 could be adapted for use in IPv6, with only the 59 straightforward changes needed to accommodate differences between 60 IPv4 and IPv6 such as the size of addresses [4]. However, the 61 development of IPv6 presents a rare opportunity, in that there is no 62 existing installed base of IPv6 hosts or routers with which we must 63 be compatible, and in that the design of IPv6 may still be adjusted 64 to account for the few special needs of mobile nodes. This draft, 65 therefore, considers how IPv6 can most naturally fulfill the support 66 requirements for mobile nodes. and in what ways the IPv4 mobility 67 design can or should be changed to take advantage of IPv6. 69 We believe that the most important function needed to support 70 mobility is the reliable and timely notification of a mobile node's 71 current location to other nodes that need it. The home agent needs 72 this location information in order to forward intercepted packets 73 from the home network to the mobile node, and correspondent nodes 74 need this information in order to send their own packets directly to 75 the mobile node. 77 In this document, we will first specify the way that the mobile node 78 can send notifications about its current whereabouts, using mostly 79 existing mechanisms available already in IPv6. Then we describe the 80 mechanism by which a routing header can be used to deliver packets to 81 the mobile node at its current whereabouts. We suppose that all IPv6 82 nodes and routers can support the operations required for mobility, 83 since the additional overhead of doing so is not very high. This 84 leads to dramatic simplifications in the required protocols. In 85 this proposal, we preserve features analogous to all of the features 86 available to mobile nodes using the IPv4 mobile-IP protocol. 88 2. Basic Operation 90 From the model of operation developed for enabling mobile networking 91 for IPv4, we borrow the concepts of home network, home address, home 92 agent, care-of address, and binding. Accordingly, mobile computers 93 will use (at least) two IPv6 addresses whenever they are roaming away 94 from their home network. One is permanent; the other is temporary. 96 In brief, using the IPv4 language, we have a basic model of operation 97 in which a mobile node can always be reached by sending packets 98 to its home (permanent) address. Assuming the mobile node is not 99 present on its home network, packets arriving for it there will be 100 intercepted by the home agent, and tunneled to a care-of address. 102 In the configurations described first in this document, the mobile 103 node can itself receive packets addressed to the care-of address. 104 Alternatively, a router will receive the tunneled packets, and 105 deliver them directly to the mobile node. 107 Generally, mobile nodes will select one or more of the available 108 care-of addresses, possibly by collecting offers of service from 109 routers in the area, and make sure the home agent is aware of its 110 currently valid care-of address(es). The method of reporting the 111 binding to the home agent (i.e., the association between care-of 112 address and home address) is substantially different than what is 113 currently specified for IPv4. The method by which care-of addresses 114 can be discovered will depend on the final form the Neighbor 115 Discovery Protocol [7] for IPv6. The packets are preferentially 116 delivered to mobile nodes by using routing headers instead of 117 encapsulation. 119 3. Binding Updates 121 Also borrowed from existing work on route optimization for IPv4 122 mobility is the concept of a location cache for mobile node bindings. 123 In IPv6, we specify that all IPv6 nodes be capable of caching the 124 location of mobile nodes with which they want to communicate, and 125 recommend that this location cache be integrated with the node's 126 conventional routing table. 128 We view it as essential for scalability and performance that 129 correspondent nodes be able to learn the location of a mobile node 130 and to be able to cache this knowledge for use in sending future 131 packets directly to the mobile node. By caching the location of a 132 mobile node, optimal routing of packets can be achieved between the 133 correspondent node and the mobile node. Routing packets directly 134 to the mobile node also eliminates congestion at the home agent 135 and thus contributes significantly to the overall health of the 136 Internet. Moreover, many communications between the mobile nodes and 137 its correspondent nodes can be carried out with no assistance from 138 the home agent. Thus, the impact of failure at the home agent can be 139 drastically reduced. This is important because many administrative 140 domains will have a single home agent to serve a particular home 141 network, and thus a single point of failure for communications 142 to nodes on that home network. Besides that, communications 143 between the home agent and any mobile node depend on perhaps many 144 intervening networks; thus, there are many more ways that packets 145 can fail to reach a mobile node when the home agent is required as 146 an intermediate node. This would be particularly relevant on, say, 147 trans-oceanic links between home agent and mobile node. Caching 148 the binding of a mobile node at the correspondent node enables 149 communication with the mobile nodes even if the home agent fails or 150 is difficult to contact over the Internet. 152 Binding updates should be considered a form of routing updates; thus, 153 handled incorrectly, they could be a source of security problems 154 and routing loops. We assume that in the deployed IPv6 systems 155 there will be access to suitable authentication mechanisms which can 156 authenticate binding updates. 158 3.1. Binding Update Option Format 160 We introduce a new IPv6 destination option by which a mobile node 161 can transmit a binding update to another IPv6 node. A mobile node 162 uses the Binding Update option to notify another node of its current 163 care-of address. The binding update should be placed in the IPv6 164 packet after any routing header, since the binding update should only 165 be processed by the destination node rather than by each hop along 166 the path. The binding update is encoded as an option within the 167 destination extension header. This alternative has the advantage 168 that it does not require the allocation of any new protocol number, 169 although there isn't any shortage yet of protocol numbers for IPv4 or 170 IPv6. By encoding the binding update in this way, it can be included 171 in any normal data packet or can be sent in a separate packet 172 containing no data. The binding update should contain the mobile 173 node's care-of address, an identification for the binding (to protect 174 against attempts to replay the update), and possibly a lifetime for 175 the binding. Note that the binding update is functionally similar to 176 the previously suggested [9] "Remote Redirect", which was intended 177 to facilitate the dissemination of mobility bindings to those 178 correspondent hosts that need them. 180 This option format is adapted from that suggested in the IPv4 route 181 optimization proposal [6]. Note that the home address is required 182 to be the source address of IPv6 packet containing the binding 183 update, and thus is not required to be located within the data of the 184 destination option. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Option Type | Option Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |A|C|I|S|E|B| Reserved | Lifetime | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 | Care-of Address | 195 | | 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Identification | 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Option Type 204 8-bit identifier of the type of option. The first three bits 205 of the option are 000, indicating first that a node receiving 206 the option may discard the option and still process the rest 207 of the packet, and second that the option may not be modified 208 enroute. 210 Option Length 212 8-bit unsigned integer. Length of the Option Data field of 213 this option, in octets. 215 Acknowledge (A) 217 The Acknowledge (A) bit is set by a node if it wants a a 218 Binding Acknowledge message to be returned upon receipt of the 219 Binding Update Option. 221 Co-location (C) 223 The mobile node is itself the agent receiving datagrams at the 224 care-of address. 226 Identification Present (I) 228 The (I) bit is set by the node sending the Binding Update 229 option to indicate whether or not the Identification field is 230 present. 232 Simultaneous (S) 234 The (S) bit is set by the mobile node if it wishes the receiver 235 to maintain multiple simultaneous bindings for the mobile node. 237 Encapsulation (E) 239 The (E) bit is set by the mobile node to request that the 240 receiving agent send encapsulated packets to the mobile node, 241 instead of packets containing the care-of address in a routing 242 header. 244 Broadcast (B) 246 The (B) bit is set by the mobile node to request that the home 247 agent encapsulate and send broadcast packets to the mobile node 248 at its care-of address. The (B) bit must only be used when 249 sending binding updates to the home agent. 251 Reserved 253 Sent as 0; ignored on reception. 255 Lifetime 257 The number of seconds remaining before the location cache entry 258 must be considered expired. A value of all ones indicates 259 infinity. A value of zero indicates that the indicated 260 location cache entry (or route table entry, in the case of a 261 mobile node's previous router) for the mobile node should be 262 deleted. The lifetime is typically equal to the remaining 263 lifetime of the mobile node's binding with its care-of address. 265 Care-of Address 267 The current care-of address of the mobile node. When set equal 268 to the home address of the mobile node, the Binding Update 269 option instead indicates that no location cache entry for the 270 mobile node should be created, and any existing location cache 271 entry (and route table entry, in the case of a mobile node's 272 previous router) for the mobile node should be deleted. 274 Identification 276 If present, a 64-bit number, used to assist in matching 277 acknowledgements with binding updates, and in protecting 278 against replay attacks. 280 The receiver of this message must be able to tell, say by employing 281 whatever means adopted by the IPv6 working group for authenticating 282 network-layer packets [1], that the mobile node is truly the agent 283 which has generated the binding update. 285 4. Sending Binding Updates 287 After moving to a new location, the mobile node registers its new 288 binding with its home agent by sending a packet containing a binding 289 update to its home agent. This binding update MUST set the (A) bit, 290 instructing the home agent to send an acknowledgement. 292 A binding update within an IPv6 header may also be included, when 293 necessary, in any normal data packet sent to a correspondent node. 294 For each correspondent node, an indication is kept by the mobile 295 node to determine whether or not the correspondent node has been 296 sent a fresh binding update since the last time any movement to 297 a new care-of address has occurred. When a packet is sent to 298 a correspondent node which hasn't been sent a fresh update, the 299 mobile node includes the update within the packet's IPv6 header, 300 and indicates that the update has been sent. Thus, correspondent 301 nodes are generally kept updated and can send almost all data packets 302 directly to the mobile node. Such binding updates are not generally 303 required to be acknowledged. However, if the mobile node wants to be 304 sure, an acknowledgment can be requested. 306 The binding update can also be sent in an otherwise empty packet 307 whenever the mobile node wishes to update its correspondents. This 308 would only be done if the mobile node suspects that its home agent is 309 not operational, too far away, or that there may be an immediate need 310 for the correspondent node to obtain the location information. 312 An IPv6 authentication header must be used so that the recipient can 313 be assured that the routing information is authentic. 315 The mobile node achieves location privacy simply by limiting the 316 correspondents to which it will send binding updates. No other IPv6 317 nodes are authorized to send binding updates on behalf of the mobile 318 node. 320 No matter how binding updates are transmitted to correspondent nodes, 321 some sort of back-off scheme must be implemented in the mobile node's 322 software to avoid a rush of updates upon every movement to a new 323 service area. Finally, some consideration should be made for the 324 continued existence of IPv4 correspondent nodes, which are less 325 likely to cache bindings. 327 5. Binding Acknowledgement Message 329 A Binding Acknowledge message is used to acknowledge receipt of 330 a Binding Update (section 3.1) option, if that option has the 331 Acknowledge (A) bit set. 333 Since the Binding Acknowledgement is mostly used by home agents 334 and is not associated with any transmission of data packets, it is 335 specified here as an informational ICMP message to the mobile node. 336 However, all of the error conditions specified in the Registration 337 Reply message of the IPv4 mobile-IP protocol may apply, so the 338 general format and codes of that message are adapted here to fit the 339 ICMP packet layout for IPv6 [2]. 341 Nodes should send Binding Acknowledgement messages addressed to the 342 mobile node originating the Binding Update, and if necessary use a 343 routing header (routing type 0) containing the care-of address given 344 in the Binding Update. 346 The acknowledgement message contains the necessary codes to inform 347 the mobile node about the status of its binding. Additionally, the 348 home agent MAY shorten the lifetime to be smaller than indicated 349 in the original binding update. When the lifetime of the reply is 350 greater than what was contained in the binding update, the excess 351 time MUST be ignored. When the lifetime of the reply is smaller than 352 the original request, another binding update SHOULD be sent before 353 the lifetime expires. 355 If the mobile node is using a care-of address offered by a local 356 router, the acknowledgement from the home agent will be sent to that 357 care-of address and (presumably) relayed to the mobile node. Routers 358 offering care-of addresses match incoming acknowledgements with 359 previous routing entries by using the Identification field supplied 360 with the binding acknowledgment. 362 The ICMP packet is organized as follows: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Code | Checksum | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Reserved | Lifetime | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Identification | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Type (provisionally) 192 377 Code One of the following codes: 379 0 service will be provided 380 1 service will be provided; simultaneous 381 mobility bindings unsupported 383 Service denied by the owner of the care-of 384 address: 386 16 reason unspecified 387 17 administratively prohibited 388 18 insufficient resources 389 19 mobile node failed authentication 390 20 home agent failed authentication 391 21 requested lifetime too long 392 22 home agent unreachable (ICMP error) 393 23 poorly formed binding update 394 24 poorly formed binding acknowledgement 396 Service denied by the home agent: 398 32 reason unspecified 399 33 administratively prohibited 400 34 insufficient resources 401 35 mobile node failed authentication 402 36 agent at care-of address failed authentication 403 37 identification mismatch 404 38 poorly formed binding update 405 39 too many simultaneous mobility bindings 407 Lifetime The seconds remaining before the binding is 408 considered expired. A value of zero confirms a 409 request for removal of a binding. A value of all 410 ones indicates infinity. 412 Identification The acknowledgment identification is derived 413 from the binding update message, for use by the 414 mobile node in matching the acknowledgment with 415 an outstanding update. 417 6. Delivering Packets to a Mobile Node 419 By default, the routing infrastructure of the Internet will route 420 packets for a mobile node to its home network; this is true of any 421 hierarchical routing and addressing scheme, whether provider-based 422 or geographical. Since the mobile node's location is known on the 423 home network (namely, by the home agent), packets can be addressed to 424 the mobile node and intercepted by the home agent without the sender 425 knowing that the node is mobile, and without requiring any special 426 routing support for mobile nodes anywhere else in the Internet. 428 Placing the registry of a mobile node's current location at the home 429 network also has the benefit of allowing each organization owning a 430 home network to manage the home agent for the mobile nodes assigned 431 to the organization's own network. 433 Correspondent nodes that have received a binding update for a mobile 434 node, can send packets directly to that mobile node's current care-of 435 address. There is already a routing header defined within the 436 current IPv6 specification which is well-suited for this purpose, 437 the routing header (routing type 0). To use the routing header for 438 delivery of packets to a mobile node, a correspondent host just 439 specifies the care-of address as the intermediate routing point and 440 the mobile node as the (final) destination. When the packet arrives 441 at the care-of address, normal processing of the routing header will 442 ensure delivery to the mobile node. 444 The IPv6 routing header avoids the unfortunate semantics of the IPv4 445 loose source routing option which made it unsuitable for use with 446 IPv4 mobility. In particular, it is fortunate that IPv6 routing 447 headers do not carry the semantics which require reversal of source 448 routes. Since the reversed source route will not be used by the 449 mobile node, no additional security risks are introduced by using 450 routing headers to deliver packets via the care-of address. 452 There is only one possible advantage afforded by the use of 453 encapsulation, compared to the use of the existing routing header 454 defined for IPv6. That only occurs when a mobile node uses a care-of 455 address associated with a nearby router. If a mobile node has a link 456 to a router over a low speed wireless link, and the router receives 457 encapsulated packets for the mobile node, the encapsulation is 458 stripped away before final delivery is made to the mobile node. In 459 that case, fewer bytes are transmitted over the low-speed link, than 460 would be the case for a normally processed routing header specifying 461 the address of the nearby router (see also section 11.1). 463 Home agents are often unable to use routing headers to deliver 464 packets to the mobile node, because they can't modify the packet and 465 add to it in flight; therefore, we specify that they must always 466 use encapsulation [8] for this purpose(section 9). It is unknown 467 at this time whether there is sufficient reason to allow the use of 468 alternative encapsulation protocols other than IPv6-within-IPv6, as 469 is done in the mobile-IP specification for IPv4. 471 If a packet to the mobile node is encapsulated, it uses the care-of 472 address as the destination address in the outer IPv6 header. Then, 473 when the the encapsulated packet arrives at the care-of address, 474 the encapsulation is stripped away and the packet delivered (if 475 possible) to the mobile node. Of course, if the mobile node is 476 itself receiving packets addressed to the care-of address, the 477 delivery path is trivial. In that case, however, it is more likely 478 that the packet would have been delivered using the care-of address 479 and a routing header. 481 6.1. Smooth Handoffs 483 As the mobile node moves from one place to another, in the case of 484 wireless communications with the existing local area networks, it 485 is probable that the mobile node will often reside within range of 486 multiple wireless network points of attachment. If the mobile node 487 obtains a new care-of address while it is still within range for 488 delivery of packets to its old care-of address, then it is reasonable 489 to expect that movement from one care-of address to the next can 490 occur without dropping any packets. 492 It is likely that, when a mobile node obtains a new care-of address 493 from an address allocation authority, it would explicitly deallocate 494 the previous care-of address. For smooth handoffs, we specify that 495 the mobile client must still accept packets at both addresses for a 496 short time after configuring its newly allocated IPv6 address. If 497 the previous address were allocated by a stateful address server, 498 then the mobile client must not release the address immediately upon 499 acquisition of a new care-of address, and the stateful address server 500 must allow mobile clients to acquire multiple addresses. 502 7. Foreign Agents 504 In the IPv4 mobility protocol, packets for a mobile node are tunneled 505 to the mobile node's current care-of address, for delivery to the 506 mobile node. The care-of address must be an address associated with 507 a router neighboring the mobile node, or the network being visited 508 by the mobile node, so that the normal routing of the Internet will 509 deliver the packet to the appropriate network. The care-of address 510 may either be the address of a foreign agent in that network, or may 511 be a temporary local address obtained by means such as DHCP [3]. 513 One reason for favoring the use of a foreign agent in IPv4 is the 514 preservation the limited IPv4 address space. To require each mobile 515 node to acquire its own temporary local address within the network 516 it is visiting would force possibly large portions of the address 517 space to be left available for such dynamic allocation. Any network 518 willing to have mobile nodes visit would need to leave a pool of 519 available addresses, and the number of visiting mobile nodes would be 520 limited to the size of that pool. The address space size is less a 521 concern in IPv6, and so it is feasible to allow each mobile node to 522 obtain a new care-of address each time it enters a new area of mobile 523 services. 525 In this section, we outline the advantages afforded by the use of 526 care-of addresses associated with routers nearby the mobile node, 527 and modifications to the previously outlined methods which are made 528 necessary when a mobile node wishes to use such care-of addresses. 530 Many other operations, related to registration of the mobile node in 531 a new service area, are likely to become important as mobile nodes 532 become more prevalent. For instance, it may be required to: 534 - authenticate the identity of mobile clients 536 - charge for connection services 538 - produce or share a session key for use by new mobile clients 539 (say, for encryption) 541 - negotiate a compression algorithm 543 - manage the resources of router's communications devices 545 These considerations are mostly outside the scope of this document. 546 In all cases, though, we suggest that the need for performing 547 such protocol actions, to satisfy additional requirements, must be 548 indicated in extensions to the basic service advertisement protocol; 549 this may depend on the form of neighbor discovery finally adopted by 550 the IPv6 working group. The actual protocol actions performed in 551 response to the extensions would be carried out at layers above IPv6 552 (e.g., UDP). 554 For instance, if a router wishes to authenticate the identity of 555 its prospective clients, it should use an extension to the service 556 advertisement message to indicate this. Then, the mobile host will 557 satisfy the router's requirement by responding with the appropriate 558 protocol operations (which are undefined here). Note that if the 559 router can authenticate any binding update issued by the mobile node 560 during operation, that authentication is likely to be good enough to 561 also authenticate the identity of the mobile node. 563 If the mobile node is to be billed for services, then surely 564 authentication will be needed. In addition, if billing is managed by 565 the routers, then the billing agent should append a billing extension 566 to its basic advertisement, so that the mobile node can select among 567 competing services if they are available, and so that the mobile 568 node can supply the information needed by the router to effect the 569 financial transactions. Similarly, encryption and/or compression 570 services might be advertised by extensions to the basic service 571 advertisements. 573 A nearby router can provide services to mobile nodes without 574 requiring any registration transactions. It is also suggested that 575 service advertisement messages issued by the router contain an 576 indication whether additional resources are currently available, so 577 that the mobile node does not have to waste time sending packets 578 through an agent which cannot forward them. Otherwise, if a mobile 579 node receives a broadcast or multicast advertisement for service 580 that the router is not really equipped to provide, then the router 581 might have to reject attempts by that mobile node to transmit data 582 through its interfaces. The router could do that by sending an ICMP 583 'Resource Unavailable' message back to the mobile node. 585 7.1. Sending a Binding Update via a Foreign Agent 587 When a mobile node is attached to the network via a foreign agent, it 588 is no longer possible to send binding updates directly to its home 589 agent. The mobile node can still send the update to its home agent, 590 through the foreign agent, by using a routing header and inserting 591 the foreign agent as an intermediate router. In this case, however, 592 the foreign agent has to remember that the mobile node, using its 593 home address, is its neighbor. Otherwise, the foreign agent would 594 not know how to deliver packets after decapsulation, or packets sent 595 to the home address using the foreign agent's care-of address in a 596 routing header. The foreign agent will already know the mobile node 597 by the mobile node's local-use only address, and by the mobile node's 598 globally routable or site-local address which was obtained from the 599 Neighbor Discovery protocol, but those two addresses are logically 600 different than the mobile node's home address. 602 We can insure this effect by by requiring the routing header used 603 with the binding update to have a new routing type (routing type 604 1). With this routing type, the foreign agent will be required to 605 transmit the expected binding acknowledgement back to the mobile node 606 when it is received from the home agent. 608 Another strategy for ensuring that the foreign agent will associate 609 the mobile node by its home address is to require the mobile node 610 to deliver its binding update to the home agent through the foreign 611 agent using encapsulation. The encapsulated binding update could 612 itself have another binding update destination option, or some more 613 economical means can be devised. 615 7.2. Smooth Handoffs between Routers 617 Given the ability to securely notify other IPv6 nodes of its current 618 location, a mobile node can also facilitate a smooth transition 619 between service from one router to another one simply by sending a 620 binding update to its previous router. This binding update must 621 be acknowledged by the previous router. Then, the router (acting 622 as a cache agent) can forward packets to the new router for direct 623 delivery to the mobile node. If a packet arrives at the previous 624 router for the mobile node, the previous router encapsulates the 625 packet and delivers it to the new router. If the previous router 626 does not receive such a binding update, and the packet cannot be 627 delivered to the mobile node, it encapsulates the packet for delivery 628 to the home agent, using its own address as the source address in the 629 outer header and the address of the mobile node as the destination 630 address. 632 It is suggested that mobile nodes continue to receive packets at 633 previous care-of addresses for as long as physically possible. This 634 can be done with care-of addresses obtained by automatic or dynamic 635 address configuration as well as those associated with routers. If 636 wireless communications are continuously available in overlapping 637 service areas, then mobile computers using such devices could thus 638 reasonably expect to move between routers without dropping any 639 packets. 641 8. After Decapsulating 643 After the router strips the encapsulation, it is no longer possible 644 for the mobile node to determine whether the packet was encapsulated 645 by the home agent, or by a correspondent node. If the packet was 646 encapsulated by the home agent, then the correspondent node must have 647 been unaware of the current location of the mobile node, and the 648 mobile node should be advised to send its correspondent a binding 649 update. This advice can be obtained in several ways, but perhaps 650 the cleanest technique is for the router to re-encapsulate the 651 packet (using essentially the same encapsulation protocol) before 652 transmitting the packet to the mobile node. The extra transmission 653 time from the router to the mobile node due to the encapsulation 654 should not be an issue since this action will occur only rarely, 655 compared to the flow of normal data packets. Re-encapsulation 656 will be even rarer if the mobile node does a good job of including 657 binding updates in the data packets it sends to its correspondent 658 nodes. Note that, for implementation, no copying need occur for 659 this operation; the encapsulating router may just replace the source 660 address in the encapsulating header, and make other minor adjustments 661 like resetting the hop limit, or the flow label. 663 A mobile node receiving such an encapsulated packet will send the 664 correspondent node a binding update. Thus, the mobile node can 665 quickly inform the correspondent node of its current care-of address, 666 and the home agent will be relied upon for only a small percentage of 667 the overall data traffic destined for the mobile node. Routers would 668 only rarely have to perform this reencapsulation for the purposes of 669 transmitting such advice. Another important advantage of this scheme 670 is that the mobile node can send binding updates to its correspondent 671 hosts without requiring any acknowledgement. Occasionally, the 672 binding update might be lost, but in that case the mobile node will 673 retransmit after a short timeout when it determines (say, with the 674 help of its router) that the first attempt probably failed. Since 675 the mobile host sends binding updates to its active correspondents 676 soon after entering the service area of a new router, any delays due 677 to stale or nonexistent location caches at correspondent nodes will 678 be short-lived. 680 Just as a mobile node should avoid sending a rush of binding updates 681 to its correspondent hosts when it migrates to a new care-of address, 682 it would be advantageous if any nearby router could avoid sending a 683 rush of advisory encapsulations to any of its newly acquired mobile 684 clients. 686 9. Home Agent Considerations 688 When the home agent receives a packet for the mobile node, it 689 encapsulates the packet and delivers it to the mobile node. Methods 690 by which the home agent could insert a routing header, or modify the 691 destination address of the mobile node, may be unavailable because 692 of the expected prevalence and operation of IPv6 authentication 693 mechanisms [1]. 695 If the home agent receives such an encapsulated packet for the 696 mobile node, it decapsulates and re-encapsulates the packet (some 697 optimization may be available here) for delivery to the mobile node's 698 new care-of address. In this situation, the home agent must check 699 that it is not trying to deliver the packet back to the same care-of 700 address from which it came; otherwise, routing loops might develop. 701 If the home agent determines that it does not have a valid binding 702 for the mobile node, it may deliver the unencapsulated packet onto 703 the home network, and should discontinue any proxy ARP operations it 704 may be performing for the mobile node. 706 It is useful to be able to send a packet to a mobile node's home 707 agent without explicitly knowing the home agent's address. For 708 example, a mobile node must communicate with its home agent to 709 send it a binding update; but since the mobile node was last at 710 home, it may have become necessary to replace the node serving as 711 its home agent due to the failure of the original node or due to 712 reconfiguration of the home network. It thus may not always be 713 possible or convenient for a mobile node to know the exact address of 714 its own home agent. 716 In IPv4, one method for accomplishing this is for the mobile node to 717 use the directed broadcast address for its home IP subnet. When the 718 packet reaches the nearest router on the home network, a copy will 719 be broadcast onto the local subnet, thus reaching the home agent, 720 although all other nodes on the home network will also receive a 721 copy of the packet and must ignore it. Then, any home agent on the 722 home network which chooses to respond will inform the mobile node of 723 its address, and the mobile node can subsequently perform the IPv4 724 registration procedure with the newly discovered home agent address. 726 In the current IPv6 specification [5], no directed broadcast 727 technique is available. The anycast addresses proposed in IPv6 728 provide a similar functionality, but are restricted to addressing 729 only the nearest of those routers at the boundary of those nodes 730 identified by a common routing prefix. The home agent, though, may 731 not be the nearest boundary router or may not be a boundary router at 732 all. 734 Since all routers on the home network are assumed to process binding 735 updates, we can be assured at least that any binding update sent to 736 the anycast address will be processed correctly. Other routers on 737 the home network must be instructed to forward packets to the current 738 router which is serving as the mobile node's home agent. This can 739 be done using the same proxy mechanisms already made available in 740 Neighbor Discovery. The current home agent multicasts the equivalent 741 of a Proxy ARP onto the home network, and subsequently the other 742 routers on the home network will forward packets destined to the 743 mobile node to the particular router which is serving as the home 744 agent for that mobile node. 746 10. Compatibility with ICMP 748 When sending a packet to a mobile node, it is important to correctly 749 return to the original sender any ICMP error messages generated by 750 this packet. Since in most cases such packets use a routing header 751 containing the care-of address, this is usually not a problem. 753 However, when a packet encapsulated at the home agent encounters 754 such an error condition, returning the ICMP error message to mobile 755 nodes away from home is more complicated: the ICMP error message 756 should travel back to the original sender along the same path as 757 the original packet, and must be in a form that makes sense to the 758 original sender when it gets there. 760 For example, if the original sender did not know that the mobile node 761 is mobile, the original packet would have been routed to the mobile 762 node's home agent, which then should have tunneled the packet to 763 the mobile node's care-of address. If an ICMP error message were 764 generated along the path between the home agent and the care-of 765 address, the ICMP error message should have been returned first to 766 the home agent, so that it could process the message and possibly 767 attempt to recover from the error. If appropriate for the type of 768 error, the ICMP error message should then be forwarded back to the 769 original sender so that it may also process the error. Since the 770 home agent added the tunneling to the original packet, it should 771 remove this from the copy of the returned packet in the ICMP error 772 message before returning it to the original sender. 774 In IPv4, this handling of returned ICMP error messages was 775 complicated by the definition of the ICMP protocol. Originally, 776 ICMP was specified to return only the first 8 data octets of the 777 packet in error, and even though this has been changed in the current 778 ``Host Requirements'' RFC to specify the return of AT LEAST the first 779 8 octets, many implementations still return only 8 octets. The 780 problem is that no matter how tunneling is encoded in the packet to 781 the mobile node, returning only 8 data octets form the packet cannot 782 return both the tunneling information and a portion of the original 783 data of the packet. 785 ICMP for IP version 6 has been specified to return as much of the 786 original packet as will fit in the ICMP error message without the 787 ICMP packet exceeding 576 octets [2]. This size should be sufficient 788 for correctly returning ICMP error messages backwards along the 789 tunnel, as long as the original sender does not expect to get this 790 full size returned. Since the tunneling information is removed from 791 the original packet by the home agent, the length of the ICMP packet 792 will in this case be less than 576 octets, and correspondingly less 793 of the original packet will be returned in the ICMP error message. 795 11. Summary 797 In this protocol document, we have proposed a departure from the 798 mobile-IP protocol for IPv4 in several important ways: 800 - We propose the use of routing headers instead of encapsulation 801 for common traffic destined to a mobile node, since the problems 802 with loose source routing in IPv4 are no longer present in IPv6 804 - We build upon the commonality between IPv4 registration and route 805 optimization protocols to permit a cleaner and smaller mechanism 806 for accomplishing the same things 808 - We emphasize the need for distributing bindings to the entities 809 that need them, in order to reduce drastically the role of the 810 home agent in handling traffic destined for the mobile node 812 - We build on the expected capability for mobile nodes to receive 813 datagrams at several IPv6 addresses, to suggest the reduced need 814 for external care-of addresses in some common circumstances. 816 - We specify that all IPv6 routers and nodes accept binding 817 updates, and thus that all IPv6 routers be able to operate as 818 home agents, affording major simplifications and optimization at 819 reasonable implementation cost. 821 11.1. Open issues 823 The common use of binding updates as Destination Options is 824 architecturally very clean, but the IPv4 registration request has 825 a more extensible mechanism for adding future functionality via 826 Mobility Extensions. If the need for additional flexibility becomes 827 important soon enough to affect this specification, then we will 828 suggest a return to the IPv4 registration requests and replies for 829 delivering binding updates to the home agents. 831 When a mobile node migrates away from an area in which it had its own 832 care-of address, there won't be any way for "straggling packets" to 833 be redirected back to the home agent, or to the new care-of address 834 for the mobile nodes. This probably isn't any worse than IPv4 835 traffic delivery anyway, as far as we know now. Nevertheless, mobile 836 nodes can alleviate this problem if the areas of service overlap 837 sufficiently, and they continue to receive packets at their previous 838 care-of address. How important is it to save such straggling 839 packets? Should we emphasize the need to overlap service areas, 840 or build additional protocol requirements to minimize the problems 841 resulting from non-overlapped service? 843 Should alternative encapsulation techniques be defined for use with 844 these protocols? Should a minimal encapsulation be defined and 845 specified as the default? Perhaps this would be better taken care of 846 by defining something like TCP header compression over the link from 847 the router to the mobile node. 849 Another alternative would be to provide another type of routing 850 header (routing type == 2, say) which would allow an intermediate 851 node to delete itself from the list instead of just rearranging the 852 list. This would completely eliminate the need for encapsulation for 853 normal datagrams from correspondent host to mobile node. 855 In the IPv4 route optimization proposal, a mechanism is outlined 856 whereby a session key can be established between foreign agents 857 and mobile clients, without requiring any pre-established security 858 relationship between them. It could very well be the case that a 859 similar mechanism should be defined for IPv6, to avoid the need for 860 a possibly time-consuming negotiation between routers and mobile 861 nodes for the purpose of obtaining the session key, which under many 862 circumstances would only be used once. 864 References 866 [1] R. Atkinson. IPv6 Authentication Header. draft-atkinson-ipng-auth-02.txt, 867 work in progress, June 1995. 869 [2] A. Conta and S. Deering. ICMP for the Internet Protocol Version 870 6 (IPv6). draft-ietf-ipngwg-icmp-02.txt -- work in progress, 871 June 1995. 873 [3] R. Droms. Dynamic Host Configuration Protocol. RFC 1541, 874 October 1993. 876 [4] IETF Mobile-IP Working Group. IPv4 Mobility Support. 877 ietf-draft-mobileip-protocol-10.txt -- work in progress, May 878 1995. 880 [5] Bob Hinden. Internet Protocol, Version 6 (IPv6) Specification. 881 Internet draft -- work in progress, October 1994. 883 [6] David B. Johnson and Charles E. Perkins. Route Optimization in 884 Mobile-IP. Internet Draft -- work in progress, January 1995. 886 [7] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor Discovery. 887 draft-ietf-ipngwg-discovery-00.txt -- work in progress, June 888 1995. 890 [8] C. Perkins. IPv6 Mobility Support. draft-perkins-mobility-ipv6-00.txt 891 -- work in progress, May 1995. 893 [9] Bill Simpson. IPv6 Neighbor Discover -- ICMP Message Formats. 894 draft-simpson-ipv6-discov-formats-01.txt -- work in progress, 895 November 1994. 897 Authors' Addresses 899 Charles Perkins 900 Room J1-A25 901 T. J. Watson Research Center 902 IBM Corporation 903 30 Saw Mill River Rd. 904 Hawthorne, NY 10532 906 Work: +1 914 789-7350 907 Fax: +1 914 784-7007 908 E-mail: perk@watson.ibm.com 910 David B. Johnson 911 Computer Science Department 912 Carnegie Mellon University 913 5000 Forbes Avenue 914 Pittsburgh, PA 15213-3891 916 Work: +1 412 268-7399 917 Fax: +1 412 268-5576 918 E-mail: dbj@cs.cmu.edu