idnits 2.17.1 draft-ietf-mobileip-ipv6-00.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-25) 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. ** 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 96: '...r advertisments, it MUST use automatic...' RFC 2119 keyword, line 214: '... binding updates MUST also include an ...' RFC 2119 keyword, line 235: '... Optimization [7]. Note that the home address MUST be the source...' RFC 2119 keyword, line 349: '...s binding update MUST have the (A) bit...' RFC 2119 keyword, line 358: '...o its home agent MUST contain the mobi...' (17 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 January 1996) is 10317 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) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-03 == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-ipv6-tunnel-00 ** Obsolete normative reference: RFC 1885 (ref. '4') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1883 (ref. '5') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-03 -- Possible downref: Normative reference to a draft: ref. '7' -- No information found for draft-ietf-ipsec-photuris - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-03 ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) == Outdated reference: A later version (-07) exists of draft-teraoka-ipv6-mobility-sup-02 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-07) exists of draft-ietf-addrconf-ipv6-auto-06 Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 7 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 26 January 1996 7 Mobility Support in IPv6 9 11 Abstract 13 This document specifies mobility messages that allow transparent 14 routing of IP datagrams to mobile nodes in the Internet. Each 15 mobile node is always identified by its home address, regardless of 16 its current point of attachment to the Internet. While situated 17 away from its home, a mobile node is also associated with a 18 care-of address, which provides information about its current 19 point of attachment to the Internet. The protocol provides for 20 notifying the mobile node's home agent, and any other interested IPv6 21 addressable entities, about the care-of address of the mobile node. 22 When necessary, the home agent sends packets destined for the mobile 23 node through a tunnel to the care-of address. After arriving at the 24 end of the tunnel, the packets are then delivered to the mobile node. 26 Status of This Memo 28 This document is an Internet-Draft. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at 35 any time. It is inappropriate to use Internet- Drafts as reference 36 material or to cite them other than as ``work in progress.'' 38 To learn the current status of any Internet-Draft, please check the 39 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 40 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 41 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 42 ftp.isi.edu (US West Coast). 44 1. Introduction 46 A new version of the Internet Protocol, IPv6, is being developed with 47 128-bit addresses, which remedies perceived flaws with the existing 48 version (that is, IPv4). This document specifies messages and a 49 simple protocol for the operation of mobile computers for IPv6. 50 Mobile computers are likely to account for a substantial fraction of 51 the population of the Internet during the lifetime of IPv6. 53 The development of IPv6 presents a rare opportunity, in that there 54 is no existing installed base of IPv6 hosts or routers with which 55 compatibility must be maintained, and all IPv6 nodes may be assumed 56 to perform the few operations needed to support Internet-wide 57 mobility. The most important function needed to support mobility 58 is the reliable and timely notification of a mobile node's current 59 location those other nodes that need it. The home agent needs this 60 location information in order to forward intercepted packets from the 61 home network to the mobile node, and correspondent nodes need this 62 information in order to send their own packets directly to the mobile 63 node. 65 In this document, we specify the way that the mobile node can notify 66 other nodes about its current whereabouts, using a Destination option 67 which fits naturally in IPv6. We describe the mechanism by which a 68 routing header can be used to deliver packets to the mobile node at 69 its current whereabouts. All IPv6 nodes and routers are assumed to 70 perform the few operations required for mobility, since doing so adds 71 little additional overhead. This leads to dramatic simplifications 72 in the required protocols, compared to the methods required for IPv4. 74 2. Basic Operation 76 From the model of operation developed for enabling mobile networking 77 for IPv4, we borrow the concepts of home network, home address, 78 home agent, care-of address, and binding. Mobile computers will 79 have assigned to their interface(s) (at least) two IPv6 addresses 80 whenever they are roaming away from their home network. One (the 81 home address) is permanent; the other (the IPv6 link-local address) 82 is used temporarily. In addition, the mobile node will typically 83 autoconfigure a globally-routable address at each new point of 84 attachment [12]. Every IPv6 router supports encapsulation, so every 85 router is capable of serving as a home agent on the network(s) to 86 which it is attached. 88 In brief, using the IPv4 language, we have a basic model of operation 89 in which a mobile node can always be reached by sending packets 90 to its home (permanent) address. Assuming the mobile node is not 91 present on its home network, packets arriving for it there will be 92 intercepted by the home agent, and tunneled to a care-of address. 94 Care-of addresses can be constructed by the mobile node using 95 the methods of automatic address configuration [12]. If the 96 mobile node receives router advertisments, it MUST use automatic 97 address configuration to construct a globally unique, routable 98 address. This routable address can be used by the mobile node as its 99 care-of address. After determining its care-of address, a mobile 100 node must send a binding update containing that care-of address 101 to the home agent (and any other correspondent nodes that may 102 have out-of-date bindings in their binding cache). By default, 103 correspondent nodes send packets to mobile nodes by using routing 104 headers instead of encapsulation. As detailed in the next section, 105 correspondent nodes are usually expected to deliver packets directly 106 to the mobile node's care-of address, so that the home agent is 107 rarely involved with packet transmission to the mobile node. 109 It is essential for scalability and minimizing network load that 110 correspondent nodes be able to learn the care-of address of a mobile 111 node, and to be able to cache this information for use in sending 112 future packets to the mobile node's care-of address. By caching the 113 care-of address of a mobile node, optimal routing of packets can be 114 achieved between the correspondent node and the mobile node. Routing 115 packets directly to the mobile node's care-of address also eliminates 116 congestion at the home agent and thus contributes significantly to 117 the overall health of the Internet. Moreover, many communications 118 between the mobile nodes and its correspondent nodes can be carried 119 out with no assistance from the home agent. Thus, the impact 120 of failure at the home agent can be drastically reduced; this is 121 important because many administrative domains will have a single home 122 agent to serve a particular home network, and thus a single point of 123 failure for communications to nodes using that home agent. Besides 124 that, communications between the home agent and a mobile node may 125 depend on a number of intervening networks; thus, there are many more 126 ways that packets can fail to reach a mobile node when the home agent 127 is required as an intermediate node. This would be particularly 128 relevant on, say, trans-oceanic links between home agent and mobile 129 node. Caching the binding of a mobile node at the correspondent node 130 enables communication with the mobile nodes even if the home agent 131 fails or is difficult to contact over the Internet. 133 In the typical case when a mobile node has configured its 134 care-of address at one of its own interfaces, transferring data to 135 the mobile node means no more work for routers on link at its current 136 point of attachment, than transferring data to any other node on that 137 link. This affords another substantial performance improvement in 138 the typical case. 140 3. Terminology 142 Mobile IPv6 defines these terms: 144 Binding 146 The association of a home address with a care-of address, along 147 with the remaining lifetime of that association. 149 Care-of Address 151 The care-of address is the termination point of a tunnel toward 152 a mobile node that is away from its home network. 154 Correspondent 156 A peer with which a mobile node is communicating. The 157 correspondent may be either mobile or stationary. 159 Foreign Network 161 Any network other than the mobile node's Home Network. 163 Home Address 165 An IPv6 address that is assigned for an extended period of time 166 to a mobile node. It remains unchanged regardless of where the 167 node is attached to the Internet. 169 Home Agent 171 A router on a mobile node's home network which tunnels packets 172 for delivery to the mobile node when it is away from home, and 173 maintains current location information for the mobile node. 175 Home Network 177 A network, possibly virtual, having a network prefix matching 178 that of a mobile node's home address. Note that standard IP 179 routing mechanisms will deliver packets destined to a mobile 180 node's Home Address to the mobile node's Home Network. 182 Link 184 A facility or medium over which nodes can communicate at the 185 link layer. A link underlies the network layer. 187 Mobile Node 189 A host or router that changes its point of attachment from one 190 network or subnetwork to another. A mobile node may change its 191 location without losing connectivity and without changing its 192 IPv6 address. 194 Node 196 A host or a router. 198 Tunnel 200 The path followed by a packet while it is encapsulated. The 201 model is that, while it is encapsulated, a packet is routed 202 to a knowledgeable decapsulating agent, which decapsulates 203 the packet and then correctly delivers it to its ultimate 204 destination. 206 4. Binding Updates 208 In IPv6, all IPv6 nodes must be capable of caching the care-of 209 address of mobile nodes with which they want to communicate. This 210 cached address information can be integrated with the node's 211 Destination Cache [9]. Binding updates should be considered a 212 form of routing updates; thus, handled incorrectly, they could 213 be a source of security problems and routing loops. Therefore, 214 packets which include binding updates MUST also include an IPv6 215 authentication header [1]; replay protection is then achieved by use 216 of the Identification field in the binding update. 218 4.1. Binding Update Option Format 220 The Binding Update Option is an option within the Destination 221 Header [5]. 223 A mobile node uses the Binding Update destination option to notify 224 another node (e.g., correspondent node or home agent) of its current 225 care-of address. The binding update should be placed in the IPv6 226 packet after any routing header, since the binding update should 227 only be processed by the destination node rather than by each hop 228 along the path. The binding update is encoded as destination option 229 type 16 (TBD). By encoding the binding update in this way, it can 230 be included in any normal data packet or can be sent in a separate 231 packet containing no data. The binding update contains the mobile 232 node's care-of address, an identification for the update (to protect 233 against attempts to replay it), and a lifetime for the binding. 234 This option format is adapted from that used in the IPv4 Route 235 Optimization [7]. Note that the home address MUST be the source 236 address of the IPv6 packet containing the binding update, and thus is 237 not required to be located within the data of the destination option. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Option Type | Option Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |A|C|I|E|B| Reserved | Lifetime | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 | Care-of Address | 248 | | 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Identification | 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Option Type 257 8-bit identifier of the type of option. The first three bits 258 of the option are 000, indicating first that a node receiving 259 the option may discard the option and still process the rest 260 of the packet, and second that the option may not be modified 261 enroute. 263 Option Length 265 8-bit unsigned integer. Length of the Option Data field of 266 this option, in octets. 268 Acknowledge (A) 270 The Acknowledge (A) bit is set by a node if it wants a a 271 Binding Acknowledge message to be returned upon receipt of the 272 Binding Update Option. 274 Co-location (C) 276 The mobile node is itself the agent receiving datagrams at the 277 care-of address. 279 Identification Present (I) 281 The (I) bit is set by the node sending the Binding Update 282 option to indicate whether or not the Identification field is 283 present. 285 Encapsulation (E) 287 The (E) bit is set by the mobile node to request that the 288 receiving node use IPv6-within-IPv6 encapsulation when sending 289 any future packets to the mobile node's care-of address, 290 instead of packets containing the care-of address in a routing 291 header. See subsection 7. 293 "All-Nodes Multicast" (B) 295 The (B) bit is set by the mobile node to request that the home 296 agent encapsulate and send "all-nodes multicast" packets to the 297 mobile node at its care-of address. The (B) bit must only be 298 used when sending binding updates to the home agent. Note that 299 the home agent may be manually configured to send only a subset 300 of such packets to the mobile node -- for instance, the home 301 agent may inspect the port number of UDP packets, or the ICMP 302 packet type, to determine whether or not the packet should be 303 forwarded to the mobile node. 305 Reserved 307 Sent as 0; ignored on reception. 309 Lifetime 311 The number of seconds remaining before the binding must be 312 considered expired. A value of all ones indicates infinity. 313 A value of zero indicates that the indicated binding (or 314 route table entry, in the case of a mobile node's previous 315 router) for the mobile node should be deleted. The lifetime is 316 typically equal to the remaining lifetime of the mobile node's 317 binding with its care-of address. 319 Care-of Address 321 The current care-of address of the mobile node. When set equal 322 to the home address of the mobile node, the Binding Update 323 option instead indicates that any existing binding for the 324 mobile node should be deleted; no binding for the mobile node 325 should be created. 327 Identification 329 If present, a 64-bit number used to protect against replay 330 attacks. 332 The receiver of this message must be able to determine that the 333 mobile node is truly the agent which has generated the binding 334 update, by verifying a subsequent IPv6 authentication header [1] 335 within the packet. 337 Extensions to the Binding Update Options format may be included after 338 the fixed portion of the Binding Update option. The presence of such 339 extensions will be indicated by the option length field. When the 340 option length is greater than the size of the fixed fields of the 341 Binding Update Option, the remainder is interpreted as extensions. 342 Currently no extensions have been defined. 344 5. Sending Binding Updates 346 After moving away from its home network to a new location (see 347 subsection 5.1), the mobile node registers its new binding with 348 its home agent by sending a packet containing a binding update to 349 its home agent. This binding update MUST have the (A) bit set, 350 instructing the home agent to send an acknowledgement. If not 351 already doing so, the home agent must send out onto the Home Network 352 a proxy Neighbor Advertisment on behalf of the mobile node, with the 353 Override flag set [9]. This will ensure that other nodes on the home 354 network are able to send packets to the mobile node by using the 355 services of the home agent. 357 In the case when the mobile node is returning to its home network, 358 the binding update sent to its home agent MUST contain the mobile 359 node's home address in place of any care-of address. The mobile node 360 MUST also send out the appropriate Neighbor Advertisment packets with 361 the Override flag set, so that its neighbors on its home network will 362 update the relevant information for the mobile node in their Neighbor 363 Caches. This Neighbor Advertisement packet can be repeated a small 364 number of times to guard against occasional loss of packets on the 365 home network. 367 A binding update may also be included, whenever necessary, in 368 a normal data packet sent to a correspondent node. For each 369 correspondent node, information is kept by the mobile node to 370 determine whether or not the correspondent node has been sent a 371 fresh binding update since the last time any movement by the mobile 372 node to a new care-of address has occurred. When a packet is to be 373 sent to a correspondent node which hasn't been sent a fresh binding 374 update, the mobile node SHOULD include the update within the packet, 375 and indicate that the update has been sent. Thus, correspondent 376 nodes are generally kept updated and can send almost all data packets 377 directly to the mobile node. Such binding updates are not generally 378 required to be acknowledged. However, if the mobile node wants to be 379 sure, an acknowledgment can be requested. 381 The binding update can also be sent in an otherwise empty packet 382 whenever the mobile node wishes to update its correspondents. This 383 is normally done only if the mobile suspects that its home agent is 384 not operational, too far away, a correspondent node is not sending 385 the traffic to the proper care-of address, or there is an immediate 386 need for the correspondent node to obtain the binding. The mobile 387 node must not send binding updates more often than MAX_UPDATE_RATE to 388 any correspondent host, since it is not allowed to change its point 389 of attachment more often than MAX_UPDATE_RATE. A mobile node can 390 detect that a correspondent node is not sending packets to the proper 391 care-of address because in that case the packets arrive at the mobile 392 node's care-of address by encapsulation instead by inclusion in a 393 routing header within the packet. 395 The mobile node may choose to keep its location private from certain 396 correspondent nodes. The mobile node need not send binding updates 397 to those correspondents. No other IPv6 nodes are authorized to send 398 binding updates on behalf of the mobile node. 400 When sending binding updates, a mobile node uses the Identification 401 field of the destination option, in conjunction with the IPv6 402 Authentication Header, to protect against replays. One style 403 of replay protection involves the use of a timestamp as the 404 Identification data. The result would be that the mobile node and 405 the target of its binding update would have to roughly agree on 406 the current time, and that stale binding updates would have to be 407 rejected. The exact mechanisms by which the Identification field is 408 created and interpreted by the sending and receiving parties depends 409 on the Security Association existing between them. This subject is 410 discussed thoroughly in the mobile-IPv4 specification [6]. 412 5.1. Detecting movement 414 A mobile node may detect that it has changed its point of attachment 415 to the Internet by several means. The usual method involves 416 reception of router advertisements from previously undetected 417 routers. This may also be augmented by a determination that a 418 previously accessible router is no longer accessible (using Neighbor 419 Unreachability Detection (NUD) as specified in [9]). 421 It is also possible that indications about changes of point of 422 attachment can be obtained from lower-level protocol or device driver 423 software. 425 6. Binding Acknowledgement Message 427 A Binding Acknowledge message is used to acknowledge acceptance 428 of a Binding Update (section 4.1) option, if that option has the 429 Acknowledge (A) bit set. Binding Acknowledgement messages should be 430 sent addressed to the mobile node originating the Binding Update, 431 using if necessary a routing header containing the care-of address 432 given in the Binding Update. 434 Since the Binding Acknowledgement is mostly used by home agents 435 and is not associated with any transmission of data packets, it is 436 specified here as an informational ICMP message to the mobile node. 437 However, all of the error conditions specified in the Registration 438 Reply message of the IPv4 mobile-IP protocol may apply, so the 439 general format and codes of that message are adapted here to fit the 440 ICMP packet layout for IPv6 [4]. 442 The acknowledgement message contains the necessary codes to inform 443 the mobile node about the status of its binding. Additionally, the 444 home agent MAY shorten the lifetime to be smaller than indicated 445 in the original binding update. When the lifetime of the reply is 446 greater than what was contained in the binding update, the excess 447 time MUST be ignored. When the lifetime of the reply is smaller than 448 the original request, another binding update SHOULD be sent before 449 the lifetime expires. 451 If a mobile node fails to receive an acceptable Binding 452 Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds after 453 transmitting the binding update, it must retransmit the binding 454 update with the same identification, and begin an exponential 455 back-off process of retransmission. The time-out period is doubled 456 upon each retransmission until the target of the binding update 457 sends an acknowledgement, or the time-out period reaches the value 458 MAX_BINDACK_TIMEOUT. 460 The ICMP Binding Acknowledgment packet has the following format: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type | Code | Checksum | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Reserved | Lifetime | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Identification | 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Type 192 (TBD) 475 Code One of the following codes: 477 0 service will be provided 478 128 service denied: reason unspecified 479 129 service denied: administratively prohibited 480 130 service denied: insufficient resources 481 133 service denied: identification mismatch 482 134 service denied: poorly formed request 483 136 service denied: unknown home agent address 485 Lifetime The seconds remaining before the binding is 486 considered expired. A value of zero indicates 487 removal of a binding. A value of all ones 488 indicates infinity. 490 Identification The acknowledgment identification is derived 491 from the binding update message, for use by the 492 mobile node in matching the acknowledgment with 493 an outstanding Binding Update. 495 Up-to-date values of the Code field are to be specified in the most 496 recent "Assigned Numbers" [10]. 498 7. Delivering Packets to a Mobile Node 500 If a routing header is not present, the routing infrastructure will 501 route packets addressed to a mobile node to its home network. Since 502 the mobile node's location is known on the home network (namely, by 503 the home agent), packets can be addressed to the mobile node and 504 intercepted by the home agent without the sender knowing that the 505 node is mobile. 507 Correspondent nodes that have accepted a binding update for a 508 mobile node, can send packets directly to that mobile node's current 509 care-of address by including a routing header in them. To use 510 the routing header for delivery of packets to a mobile node, a 511 correspondent host just specifies the care-of address as the (last) 512 intermediate routing point and the mobile node as the destination. 513 When the packet arrives at the care-of address, normal processing of 514 the routing header will ensure delivery to the mobile node. IPv6 515 routing headers do not carry the semantics which require reversal of 516 source routes. 518 Home agents cannot use routing headers to deliver packets to the 519 mobile node, because they can't modify the packet and add to it in 520 flight. They must always use encapsulation [3] for this purpose 521 (section 8). 523 If a packet to the mobile node is encapsulated, it uses the care-of 524 address as the destination address in the outer IPv6 header. Then, 525 when the the encapsulated packet arrives at the care-of address, 526 the encapsulation is stripped away and the packet delivered (if 527 possible) to the mobile node. Of course, if the mobile node is 528 itself receiving packets at the care-of address, the delivery path is 529 trivial. 531 If a correspondent node receives ICMP Host Unreachable or Network 532 Unreachable after sending a packet to a mobile node using its cached 533 care-of address, it SHOULD delete the cache entry until information 534 about the mobile node's current care-of address becomes available 535 (via a binding update). 537 7.1. Smooth Handoffs 539 If a mobile node obtains a new care-of address from an stateful 540 address allocation authority (e.g, [2]), it should soon explicitly 541 deallocate the previous care-of address. For smooth handoffs, a 542 mobile client may still accept packets at both addresses for a short 543 time after configuring its newly allocated IPv6 address. If the 544 previous address is allocated by such a stateful address server, then 545 such a mobile client may not wish to release the address immediately 546 upon acquisition of a new care-of address. The stateful address 547 server will allow mobile clients to acquire new addresses while still 548 using previously allocated addresses. 550 Routers must (just as any IPv6 node) be able to accept authenticated 551 binding updates for the mobile node and, subsequently, act on the 552 cached binding by encapsulating packets for intermediate delivery 553 to the care-of address specified in the binding. In cases where 554 a mobile node moves from one care-of address to another with no 555 delay, but without being able to maintain simultaneous connectivity 556 at both care-of addresses, it SHOULD send a binding update to the 557 router servicing the previous care-of address, so that packets 558 for the mobile node can be delivered to the new care-of address 559 immediately. For example, a mobile node may move from one radio link 560 to another on a different channel, and be unable to monitor packets 561 delivered over two channels at once. In this example, the mobile 562 node should send a binding update to the entity delivering packets 563 over the previous radio channel so that those packets will instead be 564 delivered via a new care-of address. This binding update associates 565 the mobile node's previous care-of address to the mobile node's new 566 care-of address, and is authenticated using the IPv6 Authentication 567 Header with whatever security association the previous router had 568 with the mobile node's previous care-of address. 570 For this purpose, the mobile node must have some security association 571 with the entity serving the previous care-of address. In the typical 572 case specified within this document, a mobile node has obtained a 573 care-of address via autoconfiguration and is receiving tunneled 574 packets at that care-of address. When the mobile node moves, routers 575 serving the link at its previous point of attachment may find that 576 the mobile node's previous care-of address has become inaccessible. 578 Note that the previous router does not necessarily know anything 579 about the mobile node's home address as part of this sequence of 580 events; the routers may only know about things associated with the 581 (e.g., autoconfigured) care-of addresses used by the mobile node at 582 the previous and current points of attachment. 584 Since only one binding update is expected to be sent to the previous 585 router, the mobile node MAY elect to omit the Identification field. 586 If the mobile node omits the Identification field from the binding 587 update, there is no replay protection and the security association 588 with the previous router can only be used one time. In this case, 589 the router should only accept the binding update if the mobile node's 590 care-of address is still present in its Neighbor Cache. In this 591 situation, the mobile node SHOULD request an acknowledgment for the 592 binding update. Thus, the previous router should keep the security 593 association around for the mobile node's previous care-of address in 594 case the mobile node loses the acknowledgment and retransmits the 595 binding update (with the same new care-of address). 597 The previous router then operates the same way as when the mobile 598 node's home agent receives a binding update from the mobile node. 599 That is, the previous router must inspect packets, and redirect the 600 packets destined for the care-of address indicated in the binding 601 update. Packets which need to be redirected to the mobile node's new 602 care-of address are encapsulated and sent to the new care-of address. 603 In fact, the previous router is temporarily acting as a home agent 604 for the mobile node's previous care-of address. In particular, 605 the previous router does not use any routing header to effect the 606 redirected delivery. Moreover, the previous router should issue 607 Neighbor Advertisement packets for the previous care-of address, so 608 that on-link neighbors will send packets destined to the mobile node 609 to the previous router for encapsulation and further delivery to the 610 new care-of address. 612 Once the mobile node receives the encapsulated packet, it can then 613 typically follow the routing header contained in the decapsulated 614 packet and deliver the final payload to internal protocol handling 615 using its IPv6 home address. The mobile node must ensure that a 616 binding update is sent to each source of such packets so that the 617 previous router is relieved of its duties at the earliest possible 618 moment. 620 8. Home Agent Considerations 622 When the home agent, or any other routing agent, receives a packet 623 destined to a mobile node for which it has a binding cached, 624 it encapsulates the packet for delivery to the mobile node's 625 care-of address. The agent cannot insert a routing header, or 626 modify the destination address of the mobile node, because of IPv6 627 authentication mechanisms [1]. Moreover, the home agent is expected 628 to be involved only rarely with the transmission of data to the 629 mobile node, because the mobile node will send binding updates as 630 soon as possible to its correspondent hosts. 632 It is useful to be able to send a packet to a mobile node's home 633 agent without explicitly knowing the home agent's address. For 634 example, a mobile node must communicate with its home agent to 635 send it a binding update; but since the mobile node was last at 636 home, it may have become necessary to replace the node serving as 637 its home agent due to the failure of the original node or due to 638 reconfiguration of the home network. It thus may not always be 639 possible or convenient for a mobile node to know the exact address of 640 its own home agent. 642 Mobile nodes can dynamically discover the address of a home agent 643 by sending a binding update to the anycast address on their home 644 network. Each router on the home network which receives this binding 645 update MUST reject the binding update and include its address in the 646 Binding Acknowledgement packet indicating the rejection. The mobile 647 node is assumed to know a proper anycast address on its home network 648 before making use of this method for determining a particular home 649 agent's address. 651 Other routers on the home network must be instructed to forward 652 packets to the current router which is serving as the mobile node's 653 home agent. This can be done using the same proxy mechanisms 654 already made available in Neighbor Discovery. The current home agent 655 multicasts the equivalent of a Proxy ARP onto the home network, and 656 subsequently the other routers on the home network will forward 657 packets destined to the mobile node to the particular router which is 658 serving as the home agent for that mobile node. 660 8.1. Renumbering the Home Network 662 Neighbor Discovery [9] specifies a mechanism by which all nodes on a 663 network can gracefully autoconfigure new addresses, say by combining 664 a new routing prefix with their existing MAC address. As currently 665 specified, this mechanism works when the nodes are on the same link 666 as the router issuing the necessary multicast packets to advertise 667 the new routing prefix(es) appropriate for the link. 669 However, for mobile nodes not currently attached to the same link 670 as their home agent, special care must be taken to allow the mobile 671 nodes to renumber gracefully. The most direct method of insuring 672 this is for the home agent to tunnel the multicast packets to the 673 care-of address of the mobile node as necessary. The rules for this 674 are as follows: 676 - A mobile node assumes that its routing prefix has not changes 677 unless it receives authenticated router advertisement messages 678 from its home agent that the prefix has changed. 680 - When the mobile node is at home, the home agent does not tunnel 681 router advertisements to it. 683 - When a home network prefix changes, the home agent tunnels router 684 advertisement packets to each mobile node which is currently 685 away from home and using a home address with the affected 686 routing prefix. Such tunneled router advertisements MUST be 687 authenticated [1]. 689 - When a mobile node receives a tunneled router advertisement 690 containing a new routing prefix, it must perform the standard 691 autoconfiguration operation to create its new address 693 - When a mobile node returns to its home network, it must again 694 perform Duplicate Address Detection at the earliest possible 695 moment after it has registered with its home agent. 697 - A mobile node may send a router solicitation to its home agent at 698 any time, within the constraints imposed by rate control in the 699 Neighbor Discovery specification [9] 701 Note that a mobile node is guaranteed that its home address is unique 702 and used by no other mobile node. However, in some circumstances it 703 may nevertheless be true that other nodes on its home network form 704 the same link-local address as the mobile node during the time when 705 the mobile node is away from its home network. Thus, there is the 706 requirement above that the mobile node perform Duplicate Address 707 Detection when it returns again to its home network. 709 9. Multicast Packet Routing 711 A mobile node that is connected to its home network functions just 712 like any other (stationary) host or router. Thus, when it is at 713 home, a mobile node functions identically to other multicast senders 714 and receivers. This section therefore describes the behavior of a 715 mobile node that is not on its home network. 717 In order receive multicasts, a mobile node must join the multicast 718 group. Mobile nodes MAY join multicast groups in order to receive 719 transmissions in one of two ways. First, they MAY join the group 720 via a (local) multicast router on the visited subnet. This option 721 assumes that there is a multicast router present on the visited 722 subnet. The mobile node SHOULD use its dynamically acquired care-of 723 address (if it has acquired one) as the source IP address of its 724 multicast group membership control message packets. Otherwise, it 725 MAY use its home address. 727 Alternatively, a mobile node which wishes to receive multicasts can 728 join groups via a bi-directional tunnel to its home agent, assuming 729 that its home agent is a multicast router. The mobile node tunnels 730 the appropriate multicast group membership control packets to its 731 home agent and the home agent forwards multicast packets down the 732 tunnel to the mobile node. The home agent must tunnel the packet 733 directly to the mobile node's dynamically acquired care-of address, 734 or, the packet must be tunneled first to the mobile node's home 735 address and then recursively tunneled to the mobile node's care-of 736 address. 738 A mobile node which wishes to send packets to a multicast group 739 also has two options: (1) send directly on the visited network; or 740 (2) send via a tunnel to its home agent. Because multicast routing 741 in general depends upon the IP source address, a mobile node which 742 sends multicast packets directly on the visited network MUST use 743 a dynamically acquired care-of address as the IP source address. 744 Similarly, a mobile node which tunnels a multicast packet to its home 745 agent MUST use its home address as the IP source address of both the 746 (inner) multicast packet and the (outer) encapsulating packet. This 747 second option assumes that the home agent is a multicast router. 749 10. Compatibility with ICMP 751 When sending a packet to a mobile node, it is important to correctly 752 return to the original sender any ICMP error messages generated by 753 this packet. Since in most cases such packets use a routing header 754 containing the care-of address, this is usually not a problem. 756 However, when a packet encapsulated at the home agent encounters such 757 an error condition, ICMP error messages are returned to the sender as 758 specified in [3]. ICMP for IP version 6 has been specified to return 759 as much of the original packet as will fit in the ICMP error message 760 without the ICMP packet exceeding 576 octets [4]. This size should 761 be sufficient for correctly returning ICMP error messages backwards 762 along the tunnel. 764 11. Protocol Requirements 766 This section summarizes the requirements introduced by the above 767 protocol operations for IPv6 nodes and for routers. 769 11.1. Requirements for IPv6 Nodes 771 Every IPv6 node must be able to interpret Binding Update packets. 772 Every IPv6 node must be able to maintain Security Associations for 773 use in IPv6 Authentication Headers [1] which are used to authenticate 774 Binding Updates and protect against replay attacks. Every IPv6 775 node must be able to associate care-of addresses with IPv6 target 776 addresses, and use routing headers to deliver packets to IPv6 target 777 addresses (e.g., mobile node addresses) using the care-of address as 778 an intermediate router address. 780 11.2. Requirements for IPv6 Mobile Nodes 782 Every IPv6 mobile node must be able to perform IPv6 decapsulation. 783 Every mobile node must be able to send Binding Updates as outlined 784 above, and receive Binding Acknowledgements from routers. Every IPv6 785 mobile node must keep track of which other IPv6 nodes may need to 786 receive Binding Updates as a result of recent movement by the mobile 787 node. In particular, every IPv6 mobile node must be able to send 788 Binding Updates when a packet is received that does not use a routing 789 header to specify its care-of address. 791 11.3. Requirements for IPv6 Routers 793 Every IPv6 router must perform the mobility-related functions listed 794 in the previous subsection (11.1) for IPv6 nodes, but not necessarily 795 the functions for mobile nodes. 797 Every IPv6 router must be able to issue Binding Acknowledgements in 798 response to Binding Updates received and accepted from a mobile node. 799 Every IPv6 router must be able to encapsulate packets in order to 800 tunnel them to a care-of address known for a mobile node from which 801 it has received a binding update. Every IPv6 router must be able to 802 maintain security associations for the mobile nodes from which it 803 will accept binding updates. 805 A. Constants 807 INITIAL_BINDACK_TIMEOUT == 1 second 809 MAX_BINDACK_TIMEOUT == 256 seconds 811 MAX_UPDATE_RATE == 1 per second 813 B. Open issues 815 B.1. Using Encapsulation Protocols 817 Should alternative encapsulation techniques be defined for use with 818 these protocols? Should a minimal encapsulation be defined and 819 specified as the default? 821 There is only one possible advantage afforded by the use of 822 encapsulation, compared to the use of the existing routing header 823 defined for IPv6, and it only occurs when a mobile node uses a 824 care-of address associated with a router attached to the same link as 825 the mobile node's point of attachment as in B.3. If a mobile node 826 has a link to a router over a low speed wireless link, and the router 827 receives encapsulated packets for the mobile node, the encapsulation 828 is stripped away before final delivery is made to the mobile node. 829 In that case, fewer bytes are transmitted over the low-speed link, 830 than would be the case for a normally processed routing header 831 specifying the care-of address. Perhaps this would be better taken 832 care of by defining something like TCP header compression over the 833 link from the router to the mobile node. Such a compression scheme 834 would eliminate the need to include the routing header information in 835 every packet delivered over a slow-speed connection between a router 836 and a mobile node. 838 Another alternative would be to provide another type of routing 839 header (routing type == 2, say) which would allow an intermediate 840 node to delete itself from the list instead of just rearranging the 841 list. This would completely eliminate the need for encapsulation for 842 normal datagrams from correspondent host to mobile node. However, 843 having routers remove addresses to shrink the packet size may be a 844 slow operation (relatively speaking). 846 B.2. Session keys with local routers 848 In the IPv4 route optimization proposal, a mechanism is outlined 849 whereby a session key can be established between foreign agents 850 and mobile clients, without requiring any pre-established security 851 relationship between them. A similar mechanism should be defined for 852 IPv6, to avoid the need for a possibly time-consuming negotiation 853 between routers and mobile nodes for the purpose of obtaining the 854 session key, which under many circumstances would only be used once. 855 This mechanism, if needed, can be specified completely outside the 856 mobile-IPv6 protocol and would amount to a way of creating a dynamic 857 SPI between two nodes which do not share a trust relationship, but 858 which need to agree on a key for some particular purpose (here, 859 allowing the future authentication of a binding update). Hopefully, 860 Photuris [8] will allow this function to be performed appropriately 861 for mobile nodes, say by a Diffie-Hellman key exchange. 863 B.3. Local Router Considerations 865 In previous versions of this specification, routers local to the 866 current point of attachment of the mobile node ("local routers") 867 were expected to offer services to mobile nodes. That is still 868 quite feasible, and requires only that the routers support the 869 decapsulation procedure required to extract the packet for final 870 delivery to the mobile node. If every router supports decapsulation 871 (in addition to the operations required from every IPv6 router and 872 IPv6 node), then addresses formed using any prefix advertised by 873 the router could be used as a care-of address except the router's 874 link-local address. Enabling this style of care-of address 875 acquisition will likely require some straightforward enhancements 876 to the IPv6 Neighbor Discovery packet formats. In particular, a 877 Router Advertisement should probably define another per-prefix bit 878 to specify whether the prefix is available to the mobile nodes for 879 constructing a care-of address. For stateful address configuration, 880 an option could be defined to allow the stateful server to notify a 881 mobile node of a legitimate care-of address appropriate for use at 882 the new point of attachment. 884 Many other operations, related to registration of the mobile node in 885 a new service area, are likely to become important as mobile nodes 886 become more prevalent. For instance, it may be required to: 888 - authenticate the identity of mobile clients 890 - charge for connection services 892 - produce or share a session key for use by new mobile clients 893 (say, for encryption) 895 - negotiate a compression algorithm 897 - manage the resources of router's communications devices 899 B.4. Source Address Filtering by Firewalls 901 The current specification does nothing to permit mobile nodes to 902 send their packets through firewalls which filter out packets with 903 the "wrong" source IPv6 addresses in the IPv6 packet header. The 904 mobile node's home address may be unlikely to fall within the ranges 905 required to satisfy the firewall's criteria for further delivery. 907 This subject needs serious discussion soon. As indicated by 908 recent discussion, such firewalls are unlikely to disappear. Any 909 standardized solution [11] to the firewall problem based on hiding 910 the non-local source address outside the source addres field 911 of the IPv6 header is likely to fail. Any vendor or facilities 912 administrator wanting to filter based on the address in the IPv6 913 source address field would also quickly begin filtering on hidden 914 source addresses. 916 C. Acknowledgments 918 Thanks to Thomas Narten for contributing valuable discussion and 919 reviewing this draft, as well as helping to shape some recent changes 920 relevant to the operation of Neighbor Discovery. 922 References 924 [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 926 [2] J. Bound. Dynamic Host Configuration Protocol for IPv6. 927 draft-ietf-dhc-dhcpv6-03.txt -- work in progress, November 1995. 929 [3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 930 draft-ietf-ipngwg-ipv6-tunnel-00.txt - work in progress, 931 November 1995. 933 [4] A. Conta and S. Deering. Internet Control Message Protocol 934 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 935 December 1995. 937 [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 938 Specification. RFC 1883, December 1995. 940 [6] IETF Mobile-IP Working Group. IPv4 Mobility Support. 941 ietf-draft-mobileip-protocol-12.txt - work in progress, 942 September 1995. 944 [7] David B. Johnson and Charles E. Perkins. Route Optimization 945 in Mobile-IP. draft-ietf-mobileip-optim-03.txt -- work in 946 progress, November 1995. 948 [8] P. Karn and B. Simpson. draft-ietf-ipsec-photuris-08.txt. 949 Internet Draft -- work in progress, November 1995. 951 [9] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor 952 Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in 953 progress, November 1995. 955 [10] J. Reynolds and J. Postel. Assigned Numbers. RFC 1700, October 956 1994. 958 [11] Fumio Teraoka. draft-teraoka-ipv6-mobility-sup-02.txt. 959 Internet Draft -- work in progress, January 1996. 961 [12] S. Thomson and T. Narten. IPv6 Stateless Address 962 Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt 963 - work in progress, November 1995. 965 Authors' Addresses 967 Charles Perkins 968 Room J1-A25 969 T. J. Watson Research Center 970 IBM Corporation 971 30 Saw Mill River Rd. 972 Hawthorne, NY 10532 974 Work: +1 914 789-7350 975 Fax: +1 914 784-7007 976 E-mail: perk@watson.ibm.com 978 David B. Johnson 979 Computer Science Department 980 Carnegie Mellon University 981 5000 Forbes Avenue 982 Pittsburgh, PA 15213-3891 984 Work: +1 412 268-7399 985 Fax: +1 412 268-5576 986 E-mail: dbj@cs.cmu.edu