idnits 2.17.1 draft-koodli-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.a on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 19) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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: ' 5. 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: ' 6. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([IPv6-ETHER], [2], [3], [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 127: '... MN MUST obtain its NCoA from the NA...' RFC 2119 keyword, line 185: '...In any case, NAR MUST forward the cont...' RFC 2119 keyword, line 220: '... FBAck message MUST include a NCoA e...' RFC 2119 keyword, line 221: '...essage. The NAR MUST also include the...' RFC 2119 keyword, line 279: '... expires. MUST NOT exceed 10 se...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 327 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 756 looks like a reference -- Missing reference section? '3' on line 760 looks like a reference -- Missing reference section? '1' on line 752 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Rajeev Koodli 2 INTERNET DRAFT Charles E. Perkins 3 15 October 2004 Nokia Research Center 5 Adapting Mobile IPv6 Fast Handovers for IPv4 6 draft-koodli-fmipv4-00.txt 8 This document is an Internet-Draft and is subject to all provisions 9 of section 3 of RFC 3667. By submitting this Internet-Draft, each 10 author represents that any applicable patent or other IPR claims of 11 which he or she is aware have been or will be disclosed, and any of 12 which he or she become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note 17 that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Mobile IPv6 fast handover document [2] specifies a protocol to 34 improve latency and packet loss resulting from Mobile IPv6 handover 35 operations. This document adapts the protocol for IPv4 networks 36 to improve performance over Mobile IPv4 operations, including 37 processing of Agent Advertisements, new Care of Address acquisition 38 and Registration Request and Reply. However, Foreign Agent operation 39 at a router is not necessary. Also, the protocol may be used 40 transparently on hosts which do not support Mobile IP, but with 41 limited movement across subnets. 43 Using the concepts outlined in [2], this document also addresses 44 movement detection, IP address configuration and location update 45 latencies. For reducing the IP address configuration, the draft 46 provides two alternatives. First, the new CoA is always made to be 47 the new access router's IP address. Second, a hash algorithm is used 48 to produce a new CoA, and any conflicts are resolved so as not to 49 cause traffic misdirection. 51 Contents 53 Abstract i 55 1. Introduction 2 57 2. Protocol Operation 2 58 2.1. Basic NCoA Support . . . . . . . . . . . . . . . . . . . 3 59 2.2. MN Formulating NCoA . . . . . . . . . . . . . . . . . . . 4 60 2.3. Assigned Addressing Support . . . . . . . . . . . . . . . 4 62 3. Message Formats 5 63 3.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 5 64 3.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 6 65 3.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 7 66 3.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . 9 67 3.5. Inter-Access Router Messages . . . . . . . . . . . . . . 11 68 3.5.1. Handover Initiate (HI) . . . . . . . . . . . . . 11 69 3.5.2. Handover Acknowledge (HAck) . . . . . . . . . . . 12 71 4. Option formats 14 72 4.1. Link-Layer Address Option Format . . . . . . . . . . . . 14 73 4.2. New IPv4 Address Option Format . . . . . . . . . . . . . 15 74 4.3. New Router Prefix Information Option . . . . . . . . . . 15 76 5. Security Considerations 16 78 6. IANA Considerations 17 80 Intellectual Property Statement 17 82 Disclaimer of Validity 18 84 Copyright Statement 18 86 Acknowledgment 18 88 A. Random choice of care-of address 18 89 1. Introduction 91 In this document, we adapt the fast handover specification [2] to 92 IPv4 networks. The fast handover protocol specified in this document 93 is particularly interesting for operation on commonly available 94 wireless links such as IEEE 802.11 WLAN links. Fast handovers are 95 not typically needed for wired media due to the relatively large 96 delays attributable to establishing new connections in today's 97 wired networks. This draft does not require a Foreign Agent (FA) 98 functionality. Mobile IPv4 registration messages are re-used (with 99 new type numbers) to enable quick implementation using existing 100 foreign agent code when present. This draft does not rely on 101 link-layer triggers for protocol operation, but performance will 102 typically be enhanced by using the appropriate triggers when they are 103 available. 105 The active agents that enable continued packet delivery to a mobile 106 node are the access routers on the networks that the mobile node 107 connects to. Handover means that the mobile node changes its network 108 connection, and we consider the scenario in which this change means 109 change in access routers. The mobile node utilizes the access 110 routers as default routers in the normal sense, but also as partners 111 in mobility management. Thus, when the mobile node moves to a 112 new network, it processes handover-related signaling in order to 113 identify and develop a relationship with a new access router. In 114 this document, we call the previous access router PAR and the new 115 access router NAR. 117 Address allocation and configuration may be supported using DHCP or 118 any other method. The mobile node's new care-of address (NCoA) can 119 be provided by NAR, as is conventionally done when NAR is functioning 120 as a foreign agent. Regardless of whether the NCoA is owned by the 121 foreign agent, or allocated for exclusive use of the mobile node, the 122 NCoA is a piece of configuration information that can be returned by 123 the NAR in the HAck message. 125 An access router can configure a NCoA for the mobile node, following 126 the ``assigned addressing'' model specified in [2]. That is, the 127 MN MUST obtain its NCoA from the NAR. After obtaining either such a 128 foreign-agent NCoA, or alternatively obtaining a co-located NCoA by 129 any means available, the mobile node subsequently performs Mobile 130 IP [3] operations. 132 2. Protocol Operation 134 After a MN obtains its IPv4 care-of address, it builds a neighborhood 135 access point and subnet map using the Router Solicitation for Proxy 136 Advertisement and Proxy Router Advertisement messages. The MN may 137 scan for access points (APs) based on the configuration policy in 138 operation for its wireless network interface. If a scan results in 139 a new AP discovery, the MN resolves the AP-ID to subnet information 140 using the messages defined below. 142 The coordination between the access routers is done by way of the 143 Handover Initiate (HI) and Handover Acknowledge (HAck) messages. 144 After these signals have been exchanged between the previous and new 145 access routers (PAR and NAR), data arriving at PAR will be tunneled 146 to NAR for delivery to the newly arrived mobile node. The purpose 147 of HI is to securely deliver the routing parameters for establishing 148 this tunnel. The tunnel is created by the access routers in response 149 to the delivery of the FBU from the mobile node. 151 We consider three scenarios. First, the access routers are not 152 involved in IP address management for the MN. The mobile nodes 153 acquire a new care-of address upon attaching to a new subnet link as 154 they normally do. Second, an access router acts as a foreign agent, 155 using the same IP address for use by a multiplicity of mobile nodes. 156 In this scenario, an access router provides its own IP address for 157 the MN to use upon connecting to the new link. Third, an access 158 router may allocate an IP address to a visiting mobile node by some 159 means not specified in this document. Just as a simple example, an 160 access router may maintain a pool of IPv4 addresses for temporary use 161 by visiting mobile nodes. 163 The protocol semantics are almost identical in all scenarios. The 164 packet formats presented in RFC 3344 are re-used to achieve maximum 165 compatibility with Mobile IP. 167 2.1. Basic NCoA Support 169 In response to a handover trigger or indication, the MN sends a 170 Fast Binding Update message to Previous Access Router (PAR) (see 171 Section 3.1). This message should be sent when the MN is still 172 connected to PAR. When sent in this ``predictive'' mode, the ``Home 173 Address'' field must be the PCoA. The Home Agent field, even though 174 redundant, must be set to PAR's IP address, and the Care-of Address 175 must be the NAR's IP address discovered via PrRtAdv message. The 176 destination IP address of the FBU message must be PAR's IP address. 178 When attachment to a new link is detected, FBU should be (re)sent. 179 When sent in this ``reactive'' mode, the destination address must 180 be NAR's IP address, and the source address must be PCoA from the 181 FBU message. The Home Agent field must be set to PAR's IP address. 182 When NAR receives FBU, it may already have processed the HI message 183 and created a host route entry for the PCoA. In that case, NAR can 184 immediately forward arriving and buffered packets including the FBAck 185 message. In any case, NAR MUST forward the contents of this message, 186 starting from the Type field, to PAR. 188 The Handover Initiate (HI) and Handover Acknowledge (HAck) messages 189 serve to establish a tunnel between the routers to support packet 190 forwarding for PCoA. The tunnel itself is established as a response 191 to the FBU message. Furthermore, when the MN obtains a NCoA from 192 NAR, the reverse tunnel to the PAR is not necessary; the MN would 193 reverse tunnel to the Home Agent directly using its NCoA. 195 The PAR sends HI message with Code = 0 when it receives FBU with 196 source IP address set to PCoA. The PAR sends HI with Code = 1 when 197 it receives FBU with source IP address not set to PCoA (i.e., when 198 received from NAR). This allows NAR to disambiguate processing when 199 HI needs to be sent as a response to predictive and reactive modes of 200 operation. 202 2.2. MN Formulating NCoA 204 A MN may formulate its own NCoA and use it in the Care-of-Address 205 field. See Appendix A for one such formulation. 207 2.3. Assigned Addressing Support 209 In this mode, the NAR provides NCoA, which is delivered to the MN in 210 the FBAck message either on the previous link or on the new link. 211 Since the MN is unaware of the address that NAR might assign, it 212 always binds its PCoA to NAR's address. This results in a tunnel 213 from PAR to NAR. However, with Mobile IP, a reverse tunnel to PAR is 214 not necessary since the MN can directly reverse tunnel to the Home 215 Agent. 217 The source IP address in FBU is PCoA regardless of the link it is 218 sent from. The destination address is either PAR's IP address or the 219 NAR's IP address depending on the link from which FBU is sent. The 220 FBAck message MUST include a NCoA extension. The NAR MUST provide 221 NCoA in the HAck message. The NAR MUST also include the extension 222 when responding to FBU sent from the new link. 224 The result of faster NCoA formulation is that a reverse tunnel from 225 NAR to PAR is not necessary, thus alleviating the need for a special 226 ingress filtering rule (corresponding to PCoA) for all outbound 227 packets from the NAR's link. 229 3. Message Formats 231 3.1. Fast Binding Update (FBU) 233 The FBU format is bitwise identical to the Registration Request 234 format in RFC 3344. The same destination port number, 434, is used, 235 but the FBU and FBAck messages in this specification have new message 236 type numbers. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type |x|x|D|M|G|r|T|x| reserved | Lifetime | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Home Address | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Home Agent | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Care-of Address | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 + Identification + 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Extensions ... 254 +-+-+-+-+-+-+-+- 256 Figure 1: Fast Binding Update (FBU) Message 258 IP fields: 260 Source address 261 The interface address from which the 262 message is sent. Either PCoA or NAR's IP 263 address. 265 Destination Address 266 The IP address of the Previous Access 267 Router or the New Access Router. 269 Source Port variable 271 Destination port 434 (TBA) 273 Type To be assigned by IANA 274 Flags See RFC 3344 276 reserved Sent as zero, ignored on input 278 Lifetime The number of seconds remaining before binding 279 expires. MUST NOT exceed 10 seconds. 281 Home Address MUST be PCoA or the MN's Home Address 283 Home Agent The Previous Access Router's global IP address 285 Care-of Address The New Access Router's global IP address 287 Identification See RFC 3344 289 Extensions MUST contain the MN - PAR Authentication 290 Extension 292 3.2. Fast Binding Acknowledgment (FBAck) 294 The FBAck format is bitwise identical to the Registration Reply 295 format in [3]. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Code | reserved | Lifetime | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Home Address | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Home Agent | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 + Identification + 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Extensions ... 311 +-+-+-+-+-+-+-+- 313 Figure 2: Fast Binding Acknowledgment (FBAck) Message 315 IP fields: 317 Source address 318 Typically copied from the destination 319 address of the FBU message 321 Destination Address 322 Copied from the Source IP address in FBU 323 message 325 Source Port variable 327 Destination port copied from thr source port in FBU message 329 Type To be assigned by IANA 331 Code Indicates the result of processing FBU 332 message. Code = 0 means Fast Binding Update 333 accepted. Code = 1 means Fast Binding Update 334 accepted but NCoA is supplied as an extension. 336 reserved Sent as zero, ignored on input 338 Lifetime The number of seconds remaining before binding 339 expires. MUST NOT exceed 10 seconds. 341 Home Address PCoA or MN's Home Address 343 Home Agent The Previous Access Router's global IP address 345 Identification a 64-bit number used for matching FBU. See RFC 346 3344. 348 Extensions The PAR - MN Authentication extension MUST be 349 present. In addition, a NCoA option MUST be 350 present when NAR supplies the NCoA. 352 If the FBAck message indicates that the new care-of address is a 353 Foreign Agent care-of address [3], then the mobile node MUST set the 354 'D' bit in its Registration Request message that it uses to register 355 the NCoA with its home agent. 357 3.3. Router Solicitation for Proxy Advertisement (RtSolPr) 359 Mobile Nodes send Router Solicitation for Proxy Advertisement in 360 order to prompt routers for Proxy Router Advertisements. All the 361 link-layer address options have the format defined in 4.1. The 362 message format and processing rules are identical to that defined 363 in [2]. We only provide the format here for convenience. 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type | Code | Checksum | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Subtype | Reserved | Identifier | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Options ... 373 +-+-+-+-+-+-+-+-+-+-+-+- 375 Figure 3: Router Solicitation for Proxy (RtSolPr) Message 377 IP Fields: 379 Source Address 380 An IP address assigned to the sending interface 382 Destination Address 383 The address of the Access Router or the all routers 384 multicast address. 386 Time-to-Live At least 1. See RFC 1256. 388 ICMP Fields: 390 Type To be assigned by IANA 392 Code 0 394 Checksum The ICMP checksum. See RFC 1256 396 Subtype To be assigned by IANA 398 Reserved MUST be set to zero by the sender and ignored by 399 the receiver. 401 Identifier MUST be set by the sender so that replies can be 402 matched to this Solicitation. 404 Valid Options: 406 New Access Point Link-layer Address 407 The link-layer address or identification of the 408 access point for which the MN requests routing 409 advertisement information. It MUST be included 410 in all RtSolPr messages. More than one such address 411 or identifier can be present. This field can also 412 be a wildcard address with all bits set to zero. 414 3.4. Proxy Router Advertisement (PrRtAdv) 416 Access routers send out Proxy Router Advertisement message 417 gratuitously if the handover is network-initiated or as a response 418 to RtSolPr message from a MN, providing the link-layer address, 419 IP address and subnet prefixes of neighboring routers. All the 420 link-layer address options have the format defined in 4.1. 422 The message format and processing rules are identical to that defined 423 in [2]. We only provide the format here for convenience. The ICMP 424 checksum is defined in [1]. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Code | Checksum | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Subtype | Reserved | Identifier | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Options ... 434 +-+-+-+-+-+-+-+-+-+-+-+- 436 Figure 4: Proxy Router Advertisement (PrRtAdv) Message 438 IP Fields: 440 Source Address 441 An IP address assigned to the sending interface 443 Destination Address 444 The Source Address of an invoking Router 445 Solicitation for Proxy Advertisement or the address 446 of the node the Access Router is instructing to 447 handover. 449 Time-to-Live At least 1. See RFC 1256. 451 ICMP Fields: 453 Type To be assigned by IANA 455 Code 0, 1, 2, 3 or 4. See below. 457 Checksum The ICMP checksum. See RFC 1256. 459 Subtype To be assigned by IANA. 461 Reserved MUST be set to zero by the sender and ignored by 462 the receiver. 464 Identifier Copied from Router Solicitation for Proxy 465 Advertisement or set to Zero if unsolicited. 467 Valid Options in the following order: 469 New Access Point Link-layer Address 470 The link-layer address or identification of the 471 access point is copied from RtSolPr 472 message. This option MUST be present. 474 New Router's Link-layer Address 475 The link-layer address of the Access Router for 476 which this message is proxied for. This option MUST be 477 included when Code is 0 or 1. 479 New Router's IP Address 480 The IP address of NAR. This option MUST be 481 included when Code is 0 or 1. 483 New Router Prefix Information Option 484 The number of leading bits that define the network 485 number of the corresponding Router's IP Address 486 option (see above). 487 New CoA Option 488 MAY be present when PrRtAdv is sent 489 unsolicited. PAR MAY compute new CoA using NAR's 490 prefix information and the MN's L2 address, or by 491 any other means. 493 3.5. Inter-Access Router Messages 495 3.5.1. Handover Initiate (HI) 497 The Handover Initiate (HI) is an ICMP message sent by an Access 498 Router (typically PAR) to another Access Router (typically NAR) to 499 initiate the process of a MN's handover. 501 The message format and processing rules are identical to that defined 502 in [2]. We only provide the format here for convenience. 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type | Code | Checksum | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Subtype |S|U| Reserved | Identifier | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Options ... 512 +-+-+-+-+-+-+-+-+-+-+-+- 514 Figure 5: Handover Initiate (HI) Message 516 IP Fields: 518 Source Address 519 The IP address of the PAR 521 Destination Address 522 The IP address of the NAR 524 Time-to-Live At least 1. See RFC 1256. 526 ICMP Fields: 528 Type To be assigned by IANA 530 Code 0 or 1. See below 532 Checksum The ICMP checksum. See RFC 1256 534 Subtype To be assigned by IANA 535 S Assigned address configuration flag. When set, this 536 message requests a new CoA to be returned by the 537 destination. May be set when Code = 0. MUST be 0 538 when Code = 1. 540 U Buffer flag. When set, the destination SHOULD buffer 541 any packets towards the node indicated in the options 542 of this message. Used when Code = 0, SHOULD be set 543 to 0 when Code = 1. 545 Reserved MUST be set to zero by the sender and ignored by 546 the receiver. 548 Identifier MUST be set by the sender so replies can be matched 549 to this message. 551 Valid Options: 553 Link-layer address of MN 554 The link-layer address of the MN that is 555 undergoing handover to the destination (i.e., NAR). 556 This option MUST be included so that the destination 557 can recognize the MN. 559 Previous Care of Address 560 The IP address used by the MN while 561 attached to the originating router. This option 562 SHOULD be included so that host route can be 563 established in case necessary. 565 New Care of Address 566 The IP address the MN wishes to use when 567 connected to the destination. When the `S' bit is 568 set, NAR MAY assign this address. 570 3.5.2. Handover Acknowledge (HAck) 572 The Handover Acknowledgment message is a new ICMP message that MUST 573 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 574 (HI) (see section 3.5.1) message. 576 The message format and processing rules are identical to that defined 577 in [2]. We only provide the format here for convenience. 579 IP Fields: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | Code | Checksum | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Subtype | Reserved | Identifier | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Options ... 589 +-+-+-+-+-+-+-+-+-+-+-+- 591 Figure 6: Handover Acknowledge (HAck) Message 593 Source Address 594 Copied from the destination address of the Handover 595 Initiate Message to which this message is a 596 response. 598 Destination Address 599 Copied from the source address of the Handover 600 Initiate Message to which this message is a 601 response. 603 Time-to-Live At least 1. See RFC 1256. 605 ICMP Fields: 607 Type To be assigned by IANA 609 Code 610 0: Handover Accepted, NCoA valid 611 1: Handover Accepted, NCoA not valid 612 2: Handover Accepted, NCoA in use 613 3: Handover Accepted, NCoA assigned 614 (used in Assigned addressing) 615 4: Handover Accepted, NCoA not assigned 616 (used in Assigned addressing) 617 128: Handover Not Accepted, reason unspecified 618 129: Administratively prohibited 619 130: Insufficient resources 621 Checksum The ICMP checksum. See RFC 1256. 623 Subtype To be assigned by IANA. 625 Reserved MUST be set to zero by the sender and ignored by 626 the receiver. 628 Identifier Copied from the corresponding field in the Handover 629 Initiate message this message is in response to. 631 Valid Options: 633 New Care of Address 634 If the S flag in the Handover Initiate message is set, 635 this option MUST be used to provide NCoA the MN should 636 use when connected to this router. This option MAY be 637 included even when `S' bit is not set, e.g., Code 2 638 above. 640 4. Option formats 642 The options in this section are specified as optional extensions 643 for the HI and HAck messages, as well as for the Router Proxy 644 Solicitation and Router Proxy Advertisement messages.. 646 4.1. Link-Layer Address Option Format 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Type | Length | Link-Layer Address ... 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 7: Link-Layer Address Option Format 656 Fields: 658 Type 659 1 Mobile Node Link-layer Address 660 2 New Access Point Link-layer Address 661 3 NAR Link-layer Address 663 Length The length of the option (including the type and 664 length fields) in units of octets. For example, 665 the length for IEEE 802 addresses is 1 [IPv6- 666 ETHER]. 668 Link-Layer Address 669 The variable length link-layer address. 670 The content and format of this field (including 671 byte and bit ordering) depends on the specific 672 link-layer in use. 674 4.2. New IPv4 Address Option Format 676 This option is used to provide the new router's IPv4 address in 677 PrRtAdv. When it is also used to provide NCoA, it MUST appear after 678 the new router's IPv4 address to distinguish the two addresses. 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | Reserved | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | New IPv4 Address | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 8: New IPv4 Address Option Format 690 Fields: 692 Type 693 To be assigned by IANA 695 Length The length of the option (including the type and 696 length fields) in units of octets. 698 Reserved Set to zero. 700 NCoA The New CoA assigned by NAR. 702 4.3. New Router Prefix Information Option 704 This option is the same as the ``Prefix-Lengths Extension'' in RFC 705 3344 (Section 2.1.2). 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Type | Length | Prefix-Length | Reserved | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Figure 9: New Router Prefix Information Option Format 715 Fields: 717 Type 718 To be assigned by IANA 720 Length 1 722 Prefix-Length 723 The number of leading bits that define the network 724 number of the corresponding Router's IP Address 725 option. 727 Reserved Set to zero. 729 5. Security Considerations 731 The FBU and FBack messages MUST be protected using a security 732 association shared between a MN and its access router. In 733 particular, the MN - PAR Authentication Extension MUST be present in 734 each of these messages. Failure to include this extension can lead 735 to a bogus node claiming a genuine MN's address and binding it to 736 an arbitrary address. When the NCoA is NAR's address, there is no 737 risk of a genuine MN misdirecting traffic, either inadvertantly or 738 intentionally, to an unsuspecting node on NAR's subnet. When NCoA is 739 other than NAR's address, NAR MUST ensure that the proposed NCoA in 740 HI is conflict-free, and MUST indicate the disposition in the HAck 741 message. If there is a conflict, PAR MUST NOT tunnel packets to 742 the address in question. Instead, PAR SHOULD tunnel packets to the 743 address specified in HAck, if any is provided. 745 6. IANA Considerations 747 All the messages and the option formats specified in this document 748 require Type assignment from IANA. 750 References 752 [1] S. Deering. ICMP Router Discovery Messages. Request for 753 Comments (Proposed Standard) 1256, Internet Engineering Task 754 Force, September 1991. 756 [2] R. Koodli (Editor). Fast Handovers for Mobile IPv6 (work in 757 progress). Internet Draft, Internet Engineering Task Force. 758 draft-ietf-mipshop-fast-mipv6-02.txt, October 2003. 760 [3] C. Perkins (Editor). IP Mobility Support for IPv4. Request for 761 Comments (Proposed Standard) 3344, Internet Engineering Task 762 Force, August 2002. 764 Questions about this memo can be directed to the authors: 766 Rajeev Koodli Charles E. Perkins 767 Communications Systems Lab Communications Systems Lab 768 Nokia Research Center Nokia Research Center 769 313 Fairchild Drive 313 Fairchild Drive 770 Mountain View, California 94043 Mountain View, California 94043 771 USA USA 772 Phone: +1-650 625-2359 Phone: +1-650 625-2986 773 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com 774 Fax: +1 650 625-2502 Fax: +1 650 625-2502 776 Intellectual Property Statement 778 The IETF takes no position regarding the validity or scope of any 779 Intellectual Property Rights or other rights that might be claimed to 780 pertain to the implementation or use of the technology described in 781 this document or the extent to which any license under such rights 782 might or might not be available; nor does it represent that it has 783 made any independent effort to identify any such rights. Information 784 on the procedures with respect to rights in RFC documents can be 785 found in BCP 78 and BCP 79. 787 Copies of IPR disclosures made to the IETF Secretariat and any 788 assurances of licenses to be made available, or the result of an 789 attempt made to obtain a general license or permission for the 790 use of such proprietary rights by implementers or users of this 791 specification can be obtained from the IETF on-line IPR repository at 792 http://www.ietf.org/ipr. 794 The IETF invites any interested party to bring to its attention any 795 copyrights, patents or patent applications, or other proprietary 796 rights that may cover technology that may be required to implement 797 this standard. Please address the information to the IETF at 798 ietf-ipr@ietf.org. 800 Disclaimer of Validity 802 This document and the information contained herein are provided 803 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 804 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 805 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 806 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 807 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 808 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 810 Copyright Statement 812 Copyright (C) The Internet Society (2004). This document is subject 813 to the rights, licenses and restrictions contained in BCP 78, and 814 except as set forth therein, the authors retain all their rights. 816 Acknowledgment 818 Funding for the RFC Editor function is currently provided by the 819 Internet Society. 821 A. Random choice of care-of address 823 To the knowledge of the authors, the material in this section of the 824 appendix is the only part of this specification which may be covered 825 by patent protection. 827 When a mobile node moves to a new subnet, it needs a prospective new 828 care-of address. In order to minimize the chances for collision, the 829 choice should be made at random within a restricted range defined by 830 the subnet prefix. Certain addresses are considered off limits -- 831 specifically the following: 833 - followed by all zeros 835 - followed by all ones 836 - The first 16 addresses within the subnet range, 838 - The last 16 addresses within the subnet range. 840 Within the range defined by the subnet prefix, define the following 841 values: 843 FirstAvailableAddr 845 LastAvailableAddr 847 AvailableRange := 848 LastAvailableAddr + 1 - FirstAvailableAddr 850 Retry, initially zero 852 First get a random number: 854 Random := HMAC_MD5 (NewSubnetPrefix || HomeAddress || Retry) 856 To get a random offset into the available range, calculate: 858 Offset := Random mod AvailableRange 860 Finally, calculate the prospective care-of address as: 862 CoA := FirstAvailableAddr + Offset 864 This calculation has the following characteristics: 866 - Two mobile nodes with different home addresses will obtain 867 different care-of addresses with maximum likelihood 869 - The calculation is computationally easy to carry out 871 - The HMAC_MD5 is already mandated by the base Mobile IPv4 872 specification 874 - The mobile node will get the same answer every time it renews its 875 attachment to the same subnet. 877 When the calculation yields a result that is not usable on the new 878 subnet, then in the future the mobile node SHOULD increment its 879 Retry variable for that subnet. This is only possible whenever the 880 mobile node has enough memory available to keep track of the recent 881 subnets it has visited. In that case, the Retry variable would be 882 incremented until a suitable care-of address could be calculated. 883 Due to the tight time requirements surrounding handovers, and the 884 nature of the fast handover signaling, it may well be that setting 885 the value for the Retry varialble make take several iterations which 886 span multiple handovers separated in time. Eventually, however, this 887 method makes it more likely that the mobile node will succeed to find 888 better prospective care-of addresses. 890 If the mobile node is unlikely to visit the same subnet multiple 891 times, or if no memory is available for storing current values of 892 the Retry variable, then the Retry variable should just be set to 893 a random value on every attempt to calculate a prospective care-of 894 address.