idnits 2.17.1 draft-koodli-mip4-fmipv4-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 11. -- Found old boilerplate from RFC 3978, Section 5.5 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 791. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([IPv6-ETHER], [2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 174: '...In any case, NAR MUST forward the cont...' RFC 2119 keyword, line 204: '... FBAck message MUST include a NCoA e...' RFC 2119 keyword, line 205: '...essage. The NAR MUST also include the...' RFC 2119 keyword, line 269: '... expires. MUST NOT exceed 10 se...' RFC 2119 keyword, line 271: '...e Address MUST be PCoA or the M...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 316 has weird spacing: '...on port cop...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 745 looks like a reference -- Missing reference section? '3' on line 749 looks like a reference -- Missing reference section? '4' on line 753 looks like a reference -- Missing reference section? '1' on line 741 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IPv4 Working Group Rajeev Koodli 2 INTERNET DRAFT Charles E. Perkins 3 17 October 2005 Nokia Research Center 5 Mobile IPv4 Fast Handovers 6 draft-koodli-mip4-fmipv4-00.txt 8 By submitting this Internet-Draft, each author represents that any 9 applicable patent or other IPR claims of which he or she is aware 10 have been or will be disclosed, and any of which he or she becomes 11 aware will be disclosed, in accordance with Section 6 of BCP 79. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note 15 that other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This document is a submission of the IETF MIP6 WG. Comments should be 30 directed to the MIP6 WG mailing list, mip6@ietf.org. 32 Abstract 34 The Mobile IPv6 fast handover document [2] specifies a protocol to 35 improve latency and packet loss resulting from Mobile IPv6 handover 36 operations. This document adapts the protocol for IPv4 networks 37 to improve performance over Mobile IPv4 operations, including 38 processing of Agent Advertisements, new Care of Address acquisition 39 and Registration Request and Reply. However, operation without 40 Foreign Agent function at a router is also feasible. In addition, 41 the protocol may be used transparently on hosts which do not support 42 Mobile IP, but with limited movement across subnets. Using the 43 concepts outlined in [2], this document also addresses movement 44 detection, IP address configuration and location update latencies 45 during a handover. For reducing the IP address configuration, the 46 document currently proposes that the new CoA is always made to be the 47 new access router's IP address. Additional mechanisms may be defined 48 in the future versions of this document. 50 Contents 52 Abstract i 54 1. Introduction 2 56 2. Protocol Operation 2 57 2.1. Basic NCoA Support . . . . . . . . . . . . . . . . . . . 3 58 2.2. Assigned Addressing Support . . . . . . . . . . . . . . . 4 60 3. Use of Previous FA Notification Extension 4 62 4. Message Formats 4 63 4.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 4 64 4.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 6 65 4.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 7 66 4.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . 9 67 4.5. Inter-Access Router Messages . . . . . . . . . . . . . . 11 68 4.5.1. Handover Initiate (HI) . . . . . . . . . . . . . 11 69 4.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . 12 71 5. Option formats 14 72 5.1. Link-Layer Address Option Format . . . . . . . . . . . . 14 73 5.2. New IPv4 Address Option Format . . . . . . . . . . . . . 15 74 5.3. New Router Prefix Information Option . . . . . . . . . . 15 76 6. Security Considerations 16 78 7. IANA Considerations 17 80 Intellectual Property Statement 17 82 Disclaimer of Validity 18 84 Copyright Statement 18 86 Acknowledgment 18 87 1. Introduction 89 In this document, we adapt the fast handover specification [2] to 90 IPv4 networks. The fast handover protocol specified in this document 91 is particularly interesting for operation on commonly available 92 wireless links such as IEEE 802.11 WLAN links. Fast handovers are 93 not typically needed for wired media due to the relatively large 94 delays attributable to establishing new connections in today's wired 95 networks. Mobile IPv4 registration messages are re-used (with new 96 type numbers) to enable quick implementation using existing foreign 97 agent software. This draft does not rely on link-layer triggers for 98 protocol operation, but performance will typically be enhanced by 99 using the appropriate triggers when they are available. 101 The active agents that enable continued packet delivery to a mobile 102 node are the access routers on the networks that the mobile node 103 connects to. Handover means that the mobile node changes its network 104 connection, and we consider the scenario in which this change means 105 change in access routers. The mobile node utilizes the access 106 routers as default routers in the normal sense, but also as partners 107 in mobility management. Thus, when the mobile node moves to a new 108 network, it processes handover-related signaling in order to identify 109 and develop a relationship with a new access router. In this 110 document, we call the previous access router PAR and the new access 111 router NAR. Unless otherwise mentioned, a PAR is also a Previous FA 112 (PFA) and a NAR is also a New FA (NFA). 114 On a particular network, the MN may obtain its IP address via DHCP 115 (i.e., CCoA) or use the Foreign Agent CoA. During a handover, the new 116 CoA is always made to be that of NAR. This allows a MN to receive and 117 send packets using its previous CoA, so that delays resulting from IP 118 configuration (such as DHCP address acquisition delay) subsequent to 119 attaching to the new link are disengaged from affecting the existing 120 sessions. 122 2. Protocol Operation 124 After a MN obtains its IPv4 care-of address, it builds a neighborhood 125 access point and subnet map using the Router Solicitation for Proxy 126 Advertisement and Proxy Router Advertisement messages. The MN may 127 scan for access points (APs) based on the configuration policy in 128 operation for its wireless network interface. If a scan results in 129 a new AP discovery, the MN resolves the AP-ID to subnet information 130 using the messages defined below. 132 The coordination between the access routers is done by way of the 133 Handover Initiate (HI) and Handover Acknowledge (HAck) messages. 134 After these signals have been exchanged between the previous and new 135 access routers (PAR and NAR), data arriving at PAR will be tunneled 136 to NAR for delivery to the newly arrived mobile node. The purpose 137 of HI is to securely deliver the routing parameters for establishing 138 this tunnel. The tunnel is created by the access routers in response 139 to the delivery of the FBU from the mobile node. 141 We consider three scenarios. First, the access routers are not 142 involved in IP address assignment for the MN not any more than, 143 e.g., being a DHCP Relay when DHCP is being used. Second, an access 144 router acts as a foreign agent, using the same IP address for use by 145 a multiplicity of mobile nodes. In this scenario, an access router 146 provides its own IP address for the MN to use upon connecting to the 147 new link. Third, an access router may allocate an IP address to a 148 visiting mobile node by some means not specified in this document. 149 Just as a simple example, an access router may maintain a pool of 150 IPv4 addresses for temporary use by visiting mobile nodes. 152 The protocol semantics are almost identical in all scenarios. The 153 packet formats presented in RFC 3344 are re-used to achieve maximum 154 compatibility with Mobile IP. 156 2.1. Basic NCoA Support 158 In response to a handover trigger or indication, the MN sends a 159 Fast Binding Update message to Previous Access Router (PAR) (see 160 Section 4.1). This message should be sent when the MN is still 161 connected to PAR. When sent in this ``predictive'' mode, the ``Home 162 Address'' field must be the PCoA. The Home Agent field, even though 163 redundant, must be set to PAR's IP address, and the Care-of Address 164 must be the NAR's IP address discovered via PrRtAdv message. The 165 destination IP address of the FBU message must be PAR's IP address. 167 When attachment to a new link is detected, FBU should be (re)sent. 168 When sent in this ``reactive'' mode, the destination address must 169 be NAR's IP address, and the source address must be PCoA from the 170 FBU message. The Home Agent field must be set to PAR's IP address. 171 When NAR receives FBU, it may already have processed the HI message 172 and created a host route entry for the PCoA. In that case, NAR can 173 immediately forward arriving and buffered packets including the FBAck 174 message. In any case, NAR MUST forward the contents of this message, 175 starting from the Type field, to PAR. 177 The Handover Initiate (HI) and Handover Acknowledge (HAck) messages 178 serve to establish a tunnel between the routers to support packet 179 forwarding for PCoA. The tunnel itself is established as a response 180 to the FBU message. Furthermore, when the MN obtains a NCoA from 181 NAR, the reverse tunnel to the PAR is not necessary; the MN would 182 reverse tunnel to the Home Agent directly using its NCoA. 184 The PAR sends HI message with Code = 0 when it receives FBU with 185 source IP address set to PCoA. The PAR sends HI with Code = 1 when 186 it receives FBU with source IP address not set to PCoA (i.e., when 187 received from NAR). This allows NAR to disambiguate processing when 188 HI needs to be sent as a response to predictive and reactive modes of 189 operation. 191 2.2. Assigned Addressing Support 193 In this mode, the NAR provides NCoA, which is delivered to the MN in 194 the FBAck message either on the previous link or on the new link. 195 Since the MN is unaware of the address that NAR might assign, it 196 always binds its PCoA to NAR's address. This results in a tunnel 197 from PAR to NAR. However, with Mobile IP, a reverse tunnel to PAR is 198 not necessary since the MN can directly reverse tunnel to the Home 199 Agent. 201 The source IP address in FBU is PCoA regardless of the link it is 202 sent from. The destination address is either PAR's IP address or the 203 NAR's IP address depending on the link from which FBU is sent. The 204 FBAck message MUST include a NCoA extension. The NAR MUST provide 205 NCoA in the HAck message. The NAR MUST also include the extension 206 when responding to FBU sent from the new link. 208 3. Use of Previous FA Notification Extension 210 Sending FBU from the new link (i.e., reactive mode) is similar to 211 using the extension defined in [3]. However, with the neighborhood 212 information gathered using the proxy router messages (see 213 Section 4.3, Section 4.4), movement detection and router discovery 214 delays are avoided even in the reactive case. The FBU and FBAck 215 messages defined in this document can be naturally used even when no 216 neighborhood information is available. 218 4. Message Formats 220 4.1. Fast Binding Update (FBU) 222 The FBU format is bitwise identical to the Registration Request 223 format in RFC 3344. The same destination port number, 434, is used, 224 but the FBU and FBAck messages in this specification have new message 225 type numbers. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type |x|x|D|M|G|r|T|x| reserved | Lifetime | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Home Address | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Home Agent | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Care-of Address | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 + Identification + 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Extensions ... 243 +-+-+-+-+-+-+-+- 245 Figure 1: Fast Binding Update (FBU) Message 247 IP fields: 249 Source address 250 The interface address from which the 251 message is sent. Either PCoA or NAR's IP 252 address. 254 Destination Address 255 The IP address of the Previous Access 256 Router or the New Access Router. 258 Source Port variable 260 Destination port 434 (TBA) 262 Type To be assigned by IANA 264 Flags See RFC 3344 266 reserved Sent as zero, ignored on input 268 Lifetime The number of seconds remaining before binding 269 expires. MUST NOT exceed 10 seconds. 271 Home Address MUST be PCoA or the MN's Home Address 272 Home Agent The Previous Access Router's global IP address 274 Care-of Address The New Access Router's global IP address 276 Identification See RFC 3344 278 Extensions MUST contain the MN - PAR Authentication 279 Extension 281 4.2. Fast Binding Acknowledgment (FBAck) 283 The FBAck format is bitwise identical to the Registration Reply 284 format in [4]. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Code | reserved | Lifetime | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Home Address | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Home Agent | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 + Identification + 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Extensions ... 300 +-+-+-+-+-+-+-+- 302 Figure 2: Fast Binding Acknowledgment (FBAck) Message 304 IP fields: 306 Source address 307 Typically copied from the destination 308 address of the FBU message 310 Destination Address 311 Copied from the Source IP address in FBU 312 message 314 Source Port variable 316 Destination port copied from thr source port in FBU message 318 Type To be assigned by IANA 320 Code Indicates the result of processing FBU 321 message. Code = 0 means Fast Binding Update 322 accepted. Code = 1 means Fast Binding Update 323 accepted but NCoA is supplied as an extension. 325 reserved Sent as zero, ignored on input 327 Lifetime The number of seconds remaining before binding 328 expires. MUST NOT exceed 10 seconds. 330 Home Address PCoA or MN's Home Address 332 Home Agent The Previous Access Router's global IP address 334 Identification a 64-bit number used for matching FBU. See RFC 335 3344. 337 Extensions The PAR - MN Authentication extension MUST be 338 present. In addition, a NCoA option MUST be 339 present when NAR supplies the NCoA. 341 If the FBAck message indicates that the new care-of address is a 342 Foreign Agent care-of address [4], then the mobile node MUST set the 343 'D' bit in its Registration Request message that it uses to register 344 the NCoA with its home agent. 346 4.3. Router Solicitation for Proxy Advertisement (RtSolPr) 348 Mobile Nodes send Router Solicitation for Proxy Advertisement in 349 order to prompt routers for Proxy Router Advertisements. All the 350 link-layer address options have the format defined in 5.1. The 351 message format and processing rules are identical to that defined 352 in [2]. We only provide the format here for convenience. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type | Code | Checksum | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Subtype | Reserved | Identifier | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Options ... 362 +-+-+-+-+-+-+-+-+-+-+-+- 364 Figure 3: Router Solicitation for Proxy (RtSolPr) Message 366 IP Fields: 368 Source Address 369 An IP address assigned to the sending interface 371 Destination Address 372 The address of the Access Router or the all routers 373 multicast address. 375 Time-to-Live At least 1. See RFC 1256. 377 ICMP Fields: 379 Type To be assigned by IANA 381 Code 0 383 Checksum The ICMP checksum. See RFC 1256 385 Subtype To be assigned by IANA 387 Reserved MUST be set to zero by the sender and ignored by 388 the receiver. 390 Identifier MUST be set by the sender so that replies can be 391 matched to this Solicitation. 393 Valid Options: 395 New Access Point Link-layer Address 396 The link-layer address or identification of the 397 access point for which the MN requests routing 398 advertisement information. It MUST be included 399 in all RtSolPr messages. More than one such address 400 or identifier can be present. This field can also 401 be a wildcard address with all bits set to zero. 403 4.4. Proxy Router Advertisement (PrRtAdv) 405 Access routers send out Proxy Router Advertisement message 406 gratuitously if the handover is network-initiated or as a response 407 to RtSolPr message from a MN, providing the link-layer address, 408 IP address and subnet prefixes of neighboring routers. All the 409 link-layer address options have the format defined in 5.1. 411 The message format and processing rules are identical to that defined 412 in [2]. We only provide the format here for convenience. The ICMP 413 checksum is defined in [1]. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Code | Checksum | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Subtype | Reserved | Identifier | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Options ... 423 +-+-+-+-+-+-+-+-+-+-+-+- 425 Figure 4: Proxy Router Advertisement (PrRtAdv) Message 427 IP Fields: 429 Source Address 430 An IP address assigned to the sending interface 432 Destination Address 433 The Source Address of an invoking Router 434 Solicitation for Proxy Advertisement or the address 435 of the node the Access Router is instructing to 436 handover. 438 Time-to-Live At least 1. See RFC 1256. 440 ICMP Fields: 442 Type To be assigned by IANA 444 Code 0, 1, 2, 3 or 4. See below. 446 Checksum The ICMP checksum. See RFC 1256. 448 Subtype To be assigned by IANA. 450 Reserved MUST be set to zero by the sender and ignored by 451 the receiver. 453 Identifier Copied from Router Solicitation for Proxy 454 Advertisement or set to Zero if unsolicited. 456 Valid Options in the following order: 458 New Access Point Link-layer Address 459 The link-layer address or identification of the 460 access point is copied from RtSolPr 461 message. This option MUST be present. 463 New Router's Link-layer Address 464 The link-layer address of the Access Router for 465 which this message is proxied for. This option MUST be 466 included when Code is 0 or 1. 468 New Router's IP Address 469 The IP address of NAR. This option MUST be 470 included when Code is 0 or 1. 472 New Router Prefix Information Option 473 The number of leading bits that define the network 474 number of the corresponding Router's IP Address 475 option (see above). 476 New CoA Option 477 MAY be present when PrRtAdv is sent 478 unsolicited. PAR MAY compute new CoA using NAR's 479 prefix information and the MN's L2 address, or by 480 any other means. 482 4.5. Inter-Access Router Messages 484 4.5.1. Handover Initiate (HI) 486 The Handover Initiate (HI) is an ICMP message sent by an Access 487 Router (typically PAR) to another Access Router (typically NAR) to 488 initiate the process of a MN's handover. 490 The message format and processing rules are identical to that defined 491 in [2]. We only provide the format here for convenience. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Code | Checksum | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Subtype |S|U| Reserved | Identifier | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Options ... 501 +-+-+-+-+-+-+-+-+-+-+-+- 503 Figure 5: Handover Initiate (HI) Message 505 IP Fields: 507 Source Address 508 The IP address of the PAR 510 Destination Address 511 The IP address of the NAR 513 Time-to-Live At least 1. See RFC 1256. 515 ICMP Fields: 517 Type To be assigned by IANA 519 Code 0 or 1. See below 521 Checksum The ICMP checksum. See RFC 1256 523 Subtype To be assigned by IANA 524 S Assigned address configuration flag. When set, this 525 message requests a new CoA to be returned by the 526 destination. May be set when Code = 0. MUST be 0 527 when Code = 1. 529 U Buffer flag. When set, the destination SHOULD buffer 530 any packets towards the node indicated in the options 531 of this message. Used when Code = 0, SHOULD be set 532 to 0 when Code = 1. 534 Reserved MUST be set to zero by the sender and ignored by 535 the receiver. 537 Identifier MUST be set by the sender so replies can be matched 538 to this message. 540 Valid Options: 542 Link-layer address of MN 543 The link-layer address of the MN that is 544 undergoing handover to the destination (i.e., NAR). 545 This option MUST be included so that the destination 546 can recognize the MN. 548 Previous Care of Address 549 The IP address used by the MN while 550 attached to the originating router. This option 551 SHOULD be included so that host route can be 552 established in case necessary. 554 New Care of Address 555 The IP address the MN wishes to use when 556 connected to the destination. When the `S' bit is 557 set, NAR MAY assign this address. 559 4.5.2. Handover Acknowledge (HAck) 561 The Handover Acknowledgment message is a new ICMP message that MUST 562 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 563 (HI) (see section 4.5.1) message. 565 The message format and processing rules are identical to that defined 566 in [2]. We only provide the format here for convenience. 568 IP Fields: 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type | Code | Checksum | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Subtype | Reserved | Identifier | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Options ... 578 +-+-+-+-+-+-+-+-+-+-+-+- 580 Figure 6: Handover Acknowledge (HAck) Message 582 Source Address 583 Copied from the destination address of the Handover 584 Initiate Message to which this message is a 585 response. 587 Destination Address 588 Copied from the source address of the Handover 589 Initiate Message to which this message is a 590 response. 592 Time-to-Live At least 1. See RFC 1256. 594 ICMP Fields: 596 Type To be assigned by IANA 598 Code 599 0: Handover Accepted, NCoA valid 600 1: Handover Accepted, NCoA not valid 601 2: Handover Accepted, NCoA in use 602 3: Handover Accepted, NCoA assigned 603 (used in Assigned addressing) 604 4: Handover Accepted, NCoA not assigned 605 (used in Assigned addressing) 606 128: Handover Not Accepted, reason unspecified 607 129: Administratively prohibited 608 130: Insufficient resources 610 Checksum The ICMP checksum. See RFC 1256. 612 Subtype To be assigned by IANA. 614 Reserved MUST be set to zero by the sender and ignored by 615 the receiver. 617 Identifier Copied from the corresponding field in the Handover 618 Initiate message this message is in response to. 620 Valid Options: 622 New Care of Address 623 If the S flag in the Handover Initiate message is set, 624 this option MUST be used to provide NCoA the MN should 625 use when connected to this router. This option MAY be 626 included even when `S' bit is not set, e.g., Code 2 627 above. 629 5. Option formats 631 The options in this section are specified as optional extensions 632 for the HI and HAck messages, as well as for the Router Proxy 633 Solicitation and Router Proxy Advertisement messages.. 635 5.1. Link-Layer Address Option Format 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Type | Length | Link-Layer Address ... 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 7: Link-Layer Address Option Format 645 Fields: 647 Type 648 1 Mobile Node Link-layer Address 649 2 New Access Point Link-layer Address 650 3 NAR Link-layer Address 652 Length The length of the option (including the type and 653 length fields) in units of octets. For example, 654 the length for IEEE 802 addresses is 1 [IPv6- 655 ETHER]. 657 Link-Layer Address 658 The variable length link-layer address. 659 The content and format of this field (including 660 byte and bit ordering) depends on the specific 661 link-layer in use. 663 5.2. New IPv4 Address Option Format 665 This option is used to provide the new router's IPv4 address in 666 PrRtAdv. When it is also used to provide NCoA, it MUST appear after 667 the new router's IPv4 address to distinguish the two addresses. 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Type | Length | Reserved | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | New IPv4 Address | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 8: New IPv4 Address Option Format 679 Fields: 681 Type 682 To be assigned by IANA 684 Length The length of the option (including the type and 685 length fields) in units of octets. 687 Reserved Set to zero. 689 NCoA The New CoA assigned by NAR. 691 5.3. New Router Prefix Information Option 693 This option is the same as the ``Prefix-Lengths Extension'' in RFC 694 3344 (Section 2.1.2). 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Type | Length | Prefix-Length | Reserved | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Figure 9: New Router Prefix Information Option Format 704 Fields: 706 Type 707 To be assigned by IANA 709 Length 1 711 Prefix-Length 712 The number of leading bits that define the network 713 number of the corresponding Router's IP Address 714 option. 716 Reserved Set to zero. 718 6. Security Considerations 720 The FBU and FBack messages MUST be protected using a security 721 association shared between a MN and its access router. In 722 particular, the MN - PAR Authentication Extension MUST be present in 723 each of these messages. Failure to include this extension can lead 724 to a bogus node claiming a genuine MN's address and binding it to 725 an arbitrary address. When the NCoA is NAR's address, there is no 726 risk of a genuine MN misdirecting traffic, either inadvertantly or 727 intentionally, to an unsuspecting node on NAR's subnet. When NCoA is 728 other than NAR's address, NAR MUST ensure that the proposed NCoA in 729 HI is conflict-free, and MUST indicate the disposition in the HAck 730 message. If there is a conflict, PAR MUST NOT tunnel packets to 731 the address in question. Instead, PAR SHOULD tunnel packets to the 732 address specified in HAck, if any is provided. 734 7. IANA Considerations 736 All the messages and the option formats specified in this document 737 require Type assignment from IANA. 739 References 741 [1] S. Deering. ICMP Router Discovery Messages. Request for 742 Comments (Proposed Standard) 1256, Internet Engineering Task 743 Force, September 1991. 745 [2] R. Koodli (Editor). Fast Handovers for Mobile IPv6 (work in 746 progress). Internet Draft, Internet Engineering Task Force. 747 draft-ietf-mipshop-fast-mipv6-03.txt, October 2005. 749 [3] C. Perkins and D. Johnson. Route Optimization in Mobile IP (work 750 in progress). Internet Draft, Internet Engineering Task Force. 751 draft-ietf-mobileip-optim-09.txt, February 2000. 753 [4] C. Perkins (Editor). IP Mobility Support for IPv4. Request for 754 Comments (Proposed Standard) 3344, Internet Engineering Task 755 Force, August 2002. 757 Questions about this memo can be directed to the authors: 759 Rajeev Koodli Charles E. Perkins 760 Communications Systems Lab Communications Systems Lab 761 Nokia Research Center Nokia Research Center 762 313 Fairchild Drive 313 Fairchild Drive 763 Mountain View, California 94043 Mountain View, California 94043 764 USA USA 765 Phone: +1-650 625-2359 Phone: +1-650 625-2986 766 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com 767 Fax: +1 650 625-2502 Fax: +1 650 625-2502 769 Intellectual Property Statement 771 The IETF takes no position regarding the validity or scope of any 772 Intellectual Property Rights or other rights that might be claimed to 773 pertain to the implementation or use of the technology described in 774 this document or the extent to which any license under such rights 775 might or might not be available; nor does it represent that it has 776 made any independent effort to identify any such rights. Information 777 on the procedures with respect to rights in RFC documents can be 778 found in BCP 78 and BCP 79. 780 Copies of IPR disclosures made to the IETF Secretariat and any 781 assurances of licenses to be made available, or the result of an 782 attempt made to obtain a general license or permission for the 783 use of such proprietary rights by implementers or users of this 784 specification can be obtained from the IETF on-line IPR repository at 785 http://www.ietf.org/ipr. 787 The IETF invites any interested party to bring to its attention any 788 copyrights, patents or patent applications, or other proprietary 789 rights that may cover technology that may be required to implement 790 this standard. Please address the information to the IETF at 791 ietf-ipr@ietf.org. 793 Disclaimer of Validity 795 This document and the information contained herein are provided 796 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 797 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 798 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 799 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 800 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 801 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 803 Copyright Statement 805 Copyright (C) The Internet Society (2005). This document is subject 806 to the rights, licenses and restrictions contained in BCP 78, and 807 except as set forth therein, the authors retain all their rights. 809 Acknowledgment 811 Funding for the RFC Editor function is currently provided by the 812 Internet Society.