idnits 2.17.1 draft-ietf-mip4-fmipv4-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1219. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 17, 2007) is 6179 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'AP-ID' is mentioned on line 630, but not defined == Missing Reference: 'AR-Info' is mentioned on line 630, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group Rajeev. Koodli 3 Internet-Draft Charles. Perkins 4 Intended status: Experimental Nokia Research Center 5 Expires: November 18, 2007 May 17, 2007 7 Mobile IPv4 Fast Handovers 8 draft-ietf-mip4-fmipv4-07.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 17, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document adapts the Mobile IPv6 Fast Handovers to improve delay 42 and packet loss resulting from Mobile IPv4 handover operations. 43 Specifically, this document addresses movement detection, IP address 44 configuration and location update latencies during a handover. For 45 reducing the IP address configuration latency, the document proposes 46 that the new Care-of Address is always made to be the new access 47 router's IP address. Additional mechanisms may be defined in the 48 future versions of this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Factors Affecting Handover . . . . . . . . . . . . . . . . . . 4 55 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Using Previous FA Notification Extension . . . . . . . . . . . 9 59 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 60 6.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . . 9 61 6.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . . 11 62 6.3. Router Solicitation for Proxy Advertisement (RtSolPr) . . 12 63 6.4. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . . . 14 64 6.5. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 16 65 6.6. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 18 66 7. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 20 67 7.1. Link-Layer Address Option Format . . . . . . . . . . . . . 20 68 7.2. New IPv4 Address Option Format . . . . . . . . . . . . . . 21 69 7.3. New Router Prefix Information Option . . . . . . . . . . . 22 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 72 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 78 Intellectual Property and Copyright Statements . . . . . . . . . . 28 80 1. Introduction 82 This document adapts the fast handover specification [rfc4068] to 83 IPv4 networks. The fast handover protocol specified in this document 84 is particularly interesting for operation over links such as IEEE 802 85 wireless links. Fast handovers are not typically needed for wired 86 media due to the relatively large delays attributable to establishing 87 new connections in today's wired networks. Mobile IPv4 [rfc3344] 88 registration messages are re-used (with new type numbers) in this 89 document to enable faster implementation using existing Mobile IPv4 90 software. This draft does not rely on link-layer triggers for 91 protocol operation, but performance will typically be enhanced by 92 using the appropriate triggers when they are available. This 93 document assumes that the reader is familiar with the basic operation 94 and terminology of Mobile IPv4 [rfc3344] and Fast Handovers for 95 Mobile IPv6 [rfc4068]. 97 The active agents that enable continued packet delivery to a mobile 98 node (MN) are the access routers on the networks that the mobile node 99 connects to. Handover means that the mobile node changes its network 100 connection, and we consider the scenario in which this change means 101 change in access routers. The mobile node utilizes the access 102 routers as default routers in the normal sense, but also as partners 103 in mobility management. Thus, when the mobile node moves to a new 104 network, it processes handover-related signaling in order to identify 105 and develop a relationship with a new access router. In this 106 document, we call the previous access router PAR and the new access 107 router NAR, consistent with the terminology in [rfc4068]. Unless 108 otherwise mentioned, a PAR is also a Previous Foreign Agent (PFA) and 109 a NAR is also a New Foreign Agent (NFA). 111 On a particular network, a mobile node may obtain its IP address via 112 DHCP [rfc2131] (i.e., Co-located Care-of Address) or use the Foreign 113 Agent CoA. During a handover, the new CoA (NCoA) is always made to 114 be that of NAR. This allows a mobile node to receive and send 115 packets using its previous CoA (PCoA), so that delays resulting from 116 IP configuration (such as DHCP address acquisition delay) subsequent 117 to attaching to the new link are disengaged from affecting the 118 existing sessions. 120 Unlike in Mobile IPv6, a Mobile IPv4 host may rely on its Foreign 121 Agent to provide a care-of address. In fast handovers, the binding 122 at the PAR is always established between the on-link address the 123 mobile node is using and a new CoA which it can use on the NAR's 124 link. When FA-CoA is used, the on-link address is the MN's home 125 address, not the FA-CoA itself, which needs to be bound to the NCoA. 126 So, when we say "a binding is established between PCoA and NCoA," it 127 is actually the home address of the mobile node which is bound to the 128 NCoA in the FA-CoA mode. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Terminology 136 The terminology used in this document in based on [rfc4068] and 137 [rfc3344]. We provide some definitions below for convenience. 139 Mobile Node (MN): A Mobile IPv4 host. 141 Access Point (AP): A Layer 2 device connected to an IP subnet that 142 offers wireless connectivity to an MN. An Access Point Identifier 143 (AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is also 144 referred to as a Base Station Subsystem ID (BSSID). 146 Access Router (AR): The MN's default router. 148 Previous Access Router (PAR): The MN's default router prior to its 149 handover. 151 New Access Router (NAR): The MN's default router subsequent to its 152 handover. 154 Previous CoA (PCoA): The MN's Care of Address valid on PAR's 155 subnet. 157 New CoA (NCoA): The MN's Care of Address valid on NAR's subnet. 159 Handover: A process of terminating existing connectivity and 160 obtaining new IP connectivity. 162 (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP 163 addresses, and the prefix valid on the interface to which the 164 Access Point (identified by AP-ID) is attached. The triplet 165 [Router's L2 address, Router's IP address, Prefix] is called "AR- 166 Info". 168 3. Factors Affecting Handover 170 Both the link-layer operations and IP layer procedures affect the 171 perceived handover performance. However, the overall performance is 172 also (always) a function of specific implementation of the technology 173 as well as the system configuration. This document only specifies IP 174 layer protocol operations. The purpose of this section is to provide 175 an illustration of events that affect handover performance, but it is 176 purely informative. 178 The IP layer handover delay and packet loss are influenced by 179 latencies due to movement detection, IP address configuration and 180 Mobile IP registration procedure. Movement detection latency comes 181 from the need to reliably detect movement to a new subnet. This is a 182 function of frequency of router advertisements as well as default 183 agent reachability. IP address configuration latency depends on the 184 particular IP CoA being used. If co-located mode with DHCP is used, 185 the latency is quite likely going to be higher and unacceptable for 186 real-time applications such as Voice over IP. Finally, the Mobile IP 187 registration procedure needs a round-trip of delay between the Mobile 188 Node and its Home Agent over the Internet. This delay is incurred 189 after the mobile node performs movement detection and IP 190 configuration. 192 Underlying the IP operations are link-layer procedures. These are 193 clearly technology-specific. For instance in IEEE 802.11, the 194 handover operation typically involves scanning access points over all 195 available channels, selecting a suitable access point, and 196 associating with it. It may also involve performing access control 197 operations such as those specified in IEEE 802.1X [ieee-802.1x]. 198 These delays contribute to the handover performance. Optimizations 199 are being proposed for standardization in IEEE, for instance see 200 [ieee-802.11r] and [ieee-802.21]. Together with appropriate 201 implementation techniques, these optimizations can provide the 202 required level of delay support at the link-layer for real-time 203 applications. 205 4. Protocol 207 4.1. Overview 209 The design of the protocol is the same as for Mobile IPv6 [rfc4068]. 210 Readers should consult [rfc4068] for details, and here we provide a 211 summary. 213 The protocol avoids the delay due to movement detection and IP 214 configuration and disengages Mobile IP registration delay from the 215 time-critical path. The protocol provides the surrounding network 216 neighborhood information so that a mobile node can determine whether 217 it is moving to a new subnet even before the handover. The 218 information provided and the signaling exchanged between the local 219 mobility agents allows the mobile node to send and receive packets 220 immediately after handover. In order to disengage the Mobile IP 221 registration latency, the protocol provides routing support for the 222 continued use of a mobile node's previous CoA. 224 After a mobile node obtains its IPv4 care-of address, it builds a 225 neighborhood access point and subnet map using the Router 226 Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router 227 Advertisement (PrRtAdv) messages. The mobile node may scan for 228 access points (APs) based on the configuration policy in operation 229 for its wireless network interface. If a scan results in a new AP 230 discovery, the mobile node resolves the corresponding AP Identifier 231 to subnet information using the RtSolPr and PrRtAdv messages 232 mentioned above. 234 At some point, the mobile node decides to undergo handover. It sends 235 an FBU message to PAR from the previous link or from the new link. 236 FBU message enables creation of a binding between the mobile node's 237 previous CoA and the new CoA. 239 The coordination between the access routers is done by way of the 240 Handover Initiate (HI) and Handover Acknowledge (HAck) messages 241 defined in [rfc4068]. After these signals have been exchanged 242 between the previous and new access routers (PAR and NAR), data 243 arriving at PAR will be tunneled to NAR for delivery to the newly 244 arrived mobile node. The purpose of HI is to securely deliver the 245 routing parameters for establishing this tunnel. The tunnel is 246 created by the access routers in response to the delivery of the FBU 247 from the mobile node. 249 4.2. Operation 251 In response to a handover trigger or indication, the mobile node 252 sends a Fast Binding Update message to Previous Access Router (PAR) 253 (see Section 6.1). Depending on the Mobile IP mode of operation, the 254 PCoA is either the Home Address (in FA CoA mode) or co-located CoA 255 (in CCoA mode). The FBU message SHOULD be sent when the mobile node 256 is still connected to PAR. When sent in this "predictive" mode, the 257 fields in the FBU are used as follows: 259 "Home Address" field must be the PCoA (which can be either the 260 Home Address or the co-located CoA) 262 Home Agent field must be set to PAR's IP address 264 Care-of Address field must be the NAR's IP address discovered via 265 PrRtAdv message 266 Destination IP address must be PAR's IP address 268 Source IP address must be the PCoA (which can be either the Home 269 Address or the co-located CoA) 271 As a result of processing the FBU, PAR creates a binding between PCoA 272 and NAR's IP address in its routing table. The PAR sends an FBack 273 message (see Section 6.2) as a response to the mobile node. 275 The timeline for the predictive mode of operation (adapted from 276 [rfc4068]) is shown in Figure 1. 278 MN PAR NAR 279 | | | 280 |------RtSolPr------->| | 281 |<-----PrRtAdv--------| | 282 | | | 283 |------FBU----------->|--------HI--------->| 284 | |<------HAck---------| 285 | <--FBack---|--FBack---> | 286 | | | 287 disconnect forward | 288 | packets===============>| 289 | | | 290 | | | 291 connect | | 292 | | | 293 |--------- FBU --------------------------->| 294 |<=================================== deliver packets 295 | | (including FBack) 296 | |<-----FBU-----------| 298 Figure 1: Predictive Fast Handover 300 The mobile node sends the FBU regardless of its previous transmission 301 when attachment to a new link is detected. This minimally allows NAR 302 to detect mobile node's attachment, but also the retransmission of 303 FBU when an FBack has not been received yet. When sent in this 304 "reactive" mode, the Destination IP address must be NAR's IP address; 305 the rest of the fields in the FBU are the same as in the "predictive" 306 scenario. 308 When NAR receives FBU, it may already have processed the HI message 309 and created a host route entry for the PCoA. In that case, NAR 310 should immediately forward arriving and buffered packets including 311 the FBAck message. In any case, NAR MUST forward the contents of 312 this message, starting from the Type field, to PAR, which means the 313 Source and Destination IP addresses in the new packet now contain the 314 IP addresses of NAR and PAR respectively. 316 The reactive mode of operation (adapted from [rfc4068]) is 317 illustrated in Figure 2. Even though the Figure does not show the HI 318 and HAck messages illustrated in Figure 1, these messages could 319 already have been exchanged (in the case when the PAR has already 320 processed the FBU sent from the previous link); if not, the PAR sends 321 a HI message to the NAR. The FBack packet is forwarded by the NAR to 322 the MN along with the data packets. 324 MN PAR NAR 325 | | | 326 |------RtSolPr------->| | 327 |<-----PrRtAdv--------| | 328 | | | 329 disconnect | | 330 | | | 331 | | | 332 connect | | 333 |-----------FBU-------|------------------->| 334 | |<-----FBU-----------| 335 | |------FBack-------->| 336 | forward | 337 | packets===============>| 338 | | | 339 |<=================================== deliver packets 340 | (including FBack) 341 | | 343 Figure 2: Reactive Fast Handover 345 The Handover Initiate (HI) and Handover Acknowledge (HAck) messages 346 serve to establish a bidirectional tunnel between the routers to 347 support packet forwarding for PCoA. The tunnel itself is established 348 as a response to the FBU message. The PAR sends HI message with Code 349 = 0 when it receives FBU with source IP address set to PCoA. The PAR 350 sends HI with Code = 1 when it receives FBU with source IP address 351 not set to PCoA (i.e., when received from NAR). This allows NAR to 352 disambiguate HI message processing sent as a response to predictive 353 and reactive modes of operation. If NAR receives a HI message with 354 Code = 1, and it has already set up a host route entry and a reverse 355 tunnel for PCoA, it SHOULD still respond with a HAck message, using 356 an appropriate Code value defined in Section 6.6. 358 The protocol provides an option for NAR to return NCoA for use by the 359 mobile node. When NAR can provide an NCoA for exclusive use of the 360 mobile node, the address is supplied in the HAck message. The PAR 361 includes this NCoA in FBack. Exactly how NAR manages the address 362 pool from which it supplies NCoA is not specified in this document. 363 Nevertheless, the MN should be prepared to use this address instead 364 of performing DHCP or similar operations to obtain an IPv4 address. 366 Even though the mobile node can obtain this NCoA from the NAR, it is 367 unaware of the address at the time it sends an FBU. Hence, it binds 368 PCoA to NAR's IP address as before. 370 5. Using Previous FA Notification Extension 372 Sending FBU from the new link (i.e., reactive mode) is similar to 373 using the extension defined in [draft-mip4-ro]. However, with the 374 neighborhood information gathered using the proxy router messages 375 (see Section 6.3, Section 6.4), movement detection and router 376 discovery delays are avoided even in the reactive case. The FBU and 377 FBAck messages defined in this document can be naturally used even 378 when no neighborhood information is available. 380 6. Message Formats 382 This section specifies the formats for messages used in this 383 protocol. The Code values below are the same as those in [rfc4068], 384 and do not require any assignment from IANA. 386 6.1. Fast Binding Update (FBU) 388 The FBU format is bitwise identical to the Registration Request 389 format in [rfc3344]. The same destination port number, 434, is used, 390 but the FBU and FBAck messages in this specification have new message 391 type numbers. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type |x|x|D|M|G|r|T|x| reserved | Lifetime | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Home Address | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Home Agent | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Care-of Address | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | | 405 + Identification + 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Extensions ... 409 +-+-+-+-+-+-+-+- 411 Figure 3: Fast Binding Update (FBU) Message 413 Source address: The interface address from which the message is 414 sent. Either PCoA (co-located or Home Address), or NAR's IP 415 address (when forwarded from NAR to PAR). 417 Destination Address: The IP address of the Previous Access Router 418 or the New Access Router. 420 Source Port: variable 422 Destination port: 434 424 Type: To be assigned by IANA 426 Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are 427 sent as zero, and ignored on reception. 429 reserved: Sent as zero, ignored on input 431 Lifetime: The number of seconds remaining before binding 432 expires. MUST NOT exceed 10 seconds. 434 Home Address: MUST be PCoA, which can either be the co-located 435 CoA or the Home Address 436 Home Agent: The Previous Access Router's global IP address 438 Care-of Address: The New Access Router's global IP address. 439 Even when a New CoA is provided to the MN (see Section 6.4), 440 NAR's IP address MUST be used for this field. 442 Identification: a 64-bit number used for matching an FBU with 443 FBack. Identical to usage in [rfc3344] 445 Extensions: MUST contain the MN - PAR Authentication Extension 447 The MN - PAR Authentication Extension is the Generalized Mobile IP 448 Authentication Extension in [rfc4721] with a new Subtype for MN - PAR 449 Authentication. The Authenticator field in the Generalized Mobile IP 450 Authentication Extension is calculated using a shared key between the 451 MN and the PAR. However, the key distribution itself is beyond the 452 scope of this document, and is assumed to be performed by other means 453 (for example, using [rfc3957]). 455 6.2. Fast Binding Acknowledgment (FBAck) 457 The FBAck format is bitwise identical to the Registration Reply 458 format in [rfc3344]. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Code | reserved | Lifetime | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Home Address | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Home Agent | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 + Identification + 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Extensions ... 474 +-+-+-+-+-+-+-+- 476 Figure 4: Fast Binding Acknowledgement (FBAck) Message 478 Source address: Typically copied from the destination address of 479 the FBU message 481 Destination Address: Copied from the Source IP address in FBU 482 message 484 Source Port: variable 486 Destination port: copied from the source port in FBU message 488 Type: To be assigned by IANA 490 Code: Indicates the result of processing FBU message. 492 0: FBU Accepted 493 1: FBU Accepted, NCoA supplied 494 128: FBU Not Accepted, reason unspecified 495 129: Administratively prohibited 496 130: Insufficient resources 498 reserved: Sent as zero, ignored on input 500 Lifetime: The granted number of seconds remaining before 501 binding expires. 503 Home Address: PCoA (i.e., either co-located CoA or Home 504 Address) 506 Home Agent: The Previous Access Router's global IP address 508 Identification: a 64-bit number used for matching FBU. Copied 509 from the field in FBU for which this FBack is a reply. 511 Extensions: The MN - PAR Authentication extension MUST be 512 present. In addition, an NCoA option MUST be present when NAR 513 supplies the NCoA. 515 6.3. Router Solicitation for Proxy Advertisement (RtSolPr) 517 Mobile Nodes send Router Solicitation for Proxy Advertisement in 518 order to prompt routers for Proxy Router Advertisements. All the 519 link-layer address options have the format defined in Section 7.1. 520 The message format and processing rules are identical to those 521 defined in [rfc4068]. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type | Code | Checksum | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Subtype | Reserved | Identifier | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Options ... 531 +-+-+-+-+-+-+-+-+-+-+-+- 533 Figure 5: Router Solicitation for Proxy Advertisement (RtSolPr) 534 Message 536 IP Fields: 538 Source Address: An IP address assigned to the sending interface 540 Destination Address: The address of the Access Router or the 541 all routers multicast address. 543 Time-to-Live: At least 1. See [rfc1256]. 545 ICMP Fields: 547 Type: 41. See Section 3 in [rfc4065]. 549 Code: 0 551 Checksum: The 16-bit one's complement of the one's complement 552 sum of the ICMP message, starting with the ICMP Type. For 553 computing the checksum, the Checksum and the Reserved fields 554 are set to 0. See [rfc1256]. 556 Subtype: To be assigned by IANA 558 Reserved: MUST be set to zero by the sender and ignored by the 559 receiver. 561 Identifier: MUST be set by the sender so that replies can be 562 matched to this Solicitation. 564 Valid Options: 566 New Access Point Link-layer Address: The link-layer address or 567 identification of the access point for which the MN requests 568 routing advertisement information. It MUST be included in all 569 RtSolPr messages. More than one such address or identifier can 570 be present. This field can also be a wildcard address (see 571 Section 7.1). 573 6.4. Proxy Router Advertisement (PrRtAdv) 575 Access routers send out Proxy Router Advertisement message 576 gratuitously if the handover is network-initiated or as a response to 577 RtSolPr message from a mobile node, providing the link-layer address, 578 IP address and subnet prefixes of neighboring routers. All the link- 579 layer address options have the format defined in Section 7.1. 581 The message format and processing rules are identical to those 582 defined in [rfc4068]. 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type | Code | Checksum | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Subtype | Reserved | Identifier | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Options ... 592 +-+-+-+-+-+-+-+-+-+-+-+- 594 Figure 6: Proxy Router Advertisement (PrRtAdv) Message 596 IP Fields: 598 Source Address: An IP address assigned to the sending interface 600 Destination Address: The Source Address of an invoking Router 601 Solicitation for Proxy Advertisement or the address of the node 602 the Access Router is instructing to handover. 604 Time-to-Live: At least 1. See [rfc1256]. 606 ICMP Fields: 608 Type: 41. See Section 3 in [rfc4065]. 610 Code 0, 1, 2, 3 or 4. See below. 612 Checksum: The 16-bit one's complement of the one's complement 613 sum of the ICMP message, starting with the ICMP Type. For 614 computing the checksum, the Checksum and the Reserved fields 615 are set to 0. See [rfc1256]. 617 Subtype: To be assigned by IANA. 619 Reserved: MUST be set to zero by the sender and ignored by the 620 receiver. 622 Identifier: Copied from Router Solicitation for Proxy 623 Advertisement or set to Zero if unsolicited. 625 Valid Options in the following order: 627 New Access Point Link-layer Address: The link-layer address or 628 identification of the access point. When there is no wildcard 629 in RtSolPr, this is copied from the LLA (for which the router 630 is supplying the [AP-ID, AR-Info] tuple) present in RtSolPr. 631 When a wildcard is present in RtSolPr, PAR uses its 632 neighborhood information to populate this field. This option 633 MUST be present. 635 New Router's Link-layer Address: The link-layer address of the 636 Access Router for which this message is proxied for. This 637 option MUST be included when Code is 0 or 1. 639 New Router's IP Address: The IP address of NAR. This option 640 MUST be included when Code is 0 or 1. 642 New Router Prefix Information Option: The number of leading 643 bits that define the network number of the corresponding 644 Router's IP Address option (see above). 646 New CoA Option: MAY be present, typically when PrRtAdv is sent 647 unsolicited. PAR MAY compute new CoA by communicating with the 648 NAR or by means not specified in this document. In any case, 649 the MN should be prepared to use this address instead of 650 performing DHCP or similar operations to obtain an IPv4 651 address. Even when it uses the New CoA provided, the MN MUST 652 bind its current on-link address (PCoA) to that of NAR in the 653 FBU message. 655 A PrRtAdv with Code 0 means that the MN should use the [AP-ID, AR- 656 Info] tuple present in the options above. In this case, the Option- 657 Code field (see Section 7.1) in the New AP LLA option is 1, 658 reflecting the LLA of the access point for which the rest of the 659 options are related, and the Option-Code for the New Router's LLA 660 option is 3. Multiple tuples may be present. 662 A PrRtAdv with Code 1 means that the message is sent unsolicited. If 663 a New IPv4 option (see Figure 10) is present following the New Router 664 Prefix Information option (see Section 7.3), the MN SHOULD use the 665 supplied NCoA and send the FBU immediately or else stand to lose 666 service. This message acts as a network-initiated handover trigger. 667 The Option-Code field (see Section 7.1) in the New AP LLA option in 668 this case is 1 reflecting the LLA of the access point for which the 669 rest of the options are related. 671 A Proxy Router Advertisement with Code 2 means that no new router 672 information is present. The LLA option contains an Option-Code value 673 that indicates a specific reason (see Section 7.1). 675 A Proxy Router Advertisement with Code 3 means that new router 676 information is only present for a subset of access points requested. 677 The Option-Code values in the LLA option distinguish different 678 outcomes (see Section 7.1). 680 A Proxy Router Advertisement with Code 4 means that the subnet 681 information regarding neighboring access points is sent unsolicited, 682 but the message is not a handover trigger, unlike when the message is 683 sent with Code 1. Multiple tuples may be present. 685 When a wildcard AP identifier is supplied in the RtSolPr message, the 686 PrRtAdv message should include any 'n' [Access Point Identifier, 687 Link-Layer Address option, Prefix Information Option] tuples 688 corresponding to the PAR's neighborhood. 690 The New CoA option may also be used when the PrRtAdv is sent as a 691 response to a RtSolPr message. However, the solicited RtSolPr and 692 PrRtAdv exchange for neighborhood discovery is logically decoupled 693 from the actual handover phase involving the FBU and FBack messages 694 (above) as well as HI and HAck messages (see below). This means the 695 access routers have to carefully manage the supplied address due to 696 the relative scarcity of addresses in IPv4. For this reason, the use 697 of New CoA option in solicited PrRtAdv is not specified in this 698 document. 700 6.5. Handover Initiate (HI) 702 The Handover Initiate (HI) is an ICMP message sent by an Access 703 Router (typically PAR) to another Access Router (typically NAR) to 704 initiate the process of a mobile node's handover. 706 The message format and processing rules are identical to those 707 defined in [rfc4068]. 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type | Code | Checksum | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Subtype |S|U| Reserved | Identifier | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Options ... 717 +-+-+-+-+-+-+-+-+-+-+-+- 719 Figure 7: Handover Initiate (HI) Message 721 IP Fields: 723 Source Address: The IP address of the PAR 725 Destination Address: The IP address of the NAR 727 Time-to-Live: At least 1. See [rfc1256]. 729 ICMP Fields: 731 Type: 41. See Section 3 in [rfc4065]. 733 Code: 0 or 1. See below 735 Checksum: The 16-bit one's complement of the one's complement 736 sum of the ICMP message, starting with the ICMP Type. For 737 computing the checksum, the Checksum and the Reserved fields 738 are set to 0. See [rfc1256]. 740 Subtype: To be assigned by IANA 742 S: Assigned address configuration flag. When set, this message 743 requests a new CoA to be returned by the destination. May be 744 set when Code = 0. MUST be 0 when Code = 1. 746 U: Buffer flag. When set, the destination SHOULD buffer any 747 packets towards the node indicated in the options of this 748 message. Used when Code = 0, SHOULD be set to 0 when Code = 1. 750 Reserved: MUST be set to zero by the sender and ignored by the 751 receiver. 753 Identifier: MUST be set by the sender so replies can be matched 754 to this message. 756 Valid Options: 758 Link-layer address of MN: The link-layer address of the MN that 759 is undergoing handover to the destination (i.e., NAR). This 760 option MUST be included so that the destination can recognize 761 the MN. 763 Previous Care of Address: The IP address used by the MN while 764 attached to the originating router. This option MUST be 765 included so that a host route can be established on the NAR. 767 New Care of Address: This option MAY be present when the MN 768 wishes to use a new IP address when connected to the 769 destination. When the 'S' bit is set, NAR MAY provide this 770 address in HAck, in which case the MN should be prepared to use 771 this address instead of performing DHCP or similar operations 772 to obtain an IPv4 address. 774 PAR uses Code = 0 when it processes the FBU received with PCoA as 775 source IP address. PAR uses Code = 1 when the FBU is received with 776 NAR's IP address as the source IP address. 778 6.6. Handover Acknowledge (HAck) 780 The Handover Acknowledgment message is a new ICMP message that MUST 781 be sent (typically by NAR to PAR) as a reply to the Handover Initiate 782 (HI) (see Section 6.5) message. 784 The message format and processing rules are identical to those 785 defined in [rfc4068]. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type | Code | Checksum | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Subtype | Reserved | Identifier | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Options ... 795 +-+-+-+-+-+-+-+-+-+-+-+- 796 Figure 8: Handover Acknowledge (HAck) Message 798 IP Fields: 800 Source Address: Copied from the destination address of the 801 Handover Initiate Message to which this message is a response. 803 Destination Address: Copied from the source address of the 804 Handover Initiate Message to which this message is a response. 806 Time-to-Live: At least 1. See [rfc1256]. 808 ICMP Fields: 810 Type: 41. See Section 3 in [rfc4065]. 812 Code: 814 0: Handover Accepted 815 1: Handover Accepted, NCoA not valid 816 2: Handover Accepted, NCoA in use 817 3: Handover Accepted, NCoA assigned (used in Assigned 818 addressing) 819 4: Handover Accepted, NCoA not assigned 820 128: Handover Not Accepted, reason unspecified 821 129: Administratively prohibited 822 130: Insufficient resources 824 Checksum: The 16-bit one's complement of the one's complement 825 sum of the ICMP message, start- ing with the ICMP Type. For 826 computing the checksum, the Checksum and the Reserved fields 827 are set to 0. See [rfc1256]. 829 Subtype: To be assigned by IANA. 831 Reserved: MUST be set to zero by the sender and ignored by the 832 receiver. 834 Identifier: Copied from the corresponding field in the Handover 835 Initiate message this message is in response to. 837 Valid Options: 839 New Care of Address: If the 'S' flag in the HI message is set, 840 this option MUST be used to provide NCoA the MN should use when 841 connected to this router. This option MAY be included even 842 when 'S' bit is not set, e.g., Code 2 above. The MN should be 843 prepared to use this address instead of performing DHCP or 844 similar operations to obtain an IPv4 address. 846 The Code 0 is the expected average case of a handover being accepted 847 and the routing support provided for the use of PCoA. The rest of 848 the Code values pertain to the use of NCoA (which is common in 849 [rfc4068]). Code values 1 and 2 are for cases when the MN proposes 850 an NCoA and the NAR provides a response. Code 3 is when the NAR 851 provides NCoA (which could be the same as that proposed by the MN). 852 Code 4 is when the NAR does not provide NCoA, but instead provides 853 routing support for PCoA. 855 7. Option Formats 857 The options in this section are specified as extensions for the HI 858 and HAck messages, as well as for the PrRtSol and PrRtAdv messages. 859 The Option-Code values below are the same as those in [rfc4068], and 860 do not require any assignment from IANA. 862 7.1. Link-Layer Address Option Format 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Type | Length | Option-Code | LLA ... 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 Figure 9: Link Layer Address Option Format 872 Fields: 874 Type: To be assigned by IANA 876 Option-Code: 878 0: wildcard requesting resolution for all nearby access 879 points 880 1: Link-Layer Address of the New Access Point 881 2: Link-Layer Address of the MN 882 3: Link-Layer Address of the NAR 883 4: Link-Layer Address of the source of the RtSolPr or 884 PrRtAdv message 885 5: The access point identified by the LLA belongs to the 886 current interface of the router 887 6: No prefix information available for the access point 888 identified by the LLA 889 7: No fast handovers support available for the access point 890 identified by the LLA 892 Length: The length of the option (including the Type, Length 893 and Option-Code fields) in units of 8 octets. 895 Link-Layer Address: The variable length link-layer address. 896 The content and format of this field (including byte and bit 897 ordering) depends on the specific link-layer in use. 899 There is no length field for the LLA itself. Implementations must 900 determine the length of the LLA based on the specific link technology 901 where the protocol is run. The total size of the LLA option itself 902 must be a multiple of 8 octets. Hence, padding may be necessary 903 depending on the size of the LLA used. In such a case, the padN 904 option [rfc2460] MUST be used. As an example, when the LLA is 6 905 bytes (meaning 7 bytes of padding is necessary to bring the LLA 906 option length to 2), the padN option will have a length field of 5 907 and 5 bytes of zero-valued octets (see [rfc2460]). 909 7.2. New IPv4 Address Option Format 911 This option is used to provide the new router's IPv4 address or the 912 NCoA in PrRtAdv, as well as PCoA and NCoA in HI and HAck messages. 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Type | Length | Option-Code | Reserved | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | New IPv4 Address | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Figure 10: New IPv4 Address Option Format 924 Fields: 926 Type: To be assigned by IANA 928 Length: The length of the option (including the Type, Length 929 and Option-Code fields) in units of 8 octets. 931 Option-Code: 933 1: Previous CoA 934 2: New CoA 935 3: NAR's IP Address 937 Reserved: Set to zero. 939 New IPv4 Address: NAR's IPv4 address or the NCoA assigned by 940 NAR. 942 7.3. New Router Prefix Information Option 944 This option is used in the PrRtAdv message. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Type | Length | Option-Code | Prefix-Length | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Reserved | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Figure 11: New Router Prefix Information Option Format 956 Fields: 958 Type: To be assigned by IANA 960 Length: The length of the option (including the Type, Length 961 and Option-Code fields) in units of 8 octets. 963 Option-Code: 0 965 Prefix-Length The number of leading bits that define the 966 network number of the corresponding Router's IP Address option. 968 Reserved: Set to zero. 970 8. Security Considerations 972 As outlined in [rfc4068], the following vulnerabilities are 973 identified and the solutions mentioned. 975 Insecure FBU: 977 Failure to protect the FBU message could result in packets meant for 978 an address being stolen or redirected to some unsuspecting node. 979 This concern is similar to that in Mobile Node and Home Agent 980 relationship. 982 Hence, the FBU and FBack messages MUST be protected using a security 983 association shared between a mobile node and its access router. In 984 particular, the MN - PAR Authentication Extension MUST be present in 985 each of these messages. This document does not specify how the 986 security association is established between a MN and the AR/FA. 988 Secure FBU, malicious or inadvertent redirection: 990 Even if the MN - PAR authentication extension is present in an FBU, a 991 MN may inadvertently or maliciously attempt to bind its PCoA to an 992 unintended address on NAR's link, and cause traffic flooding to an 993 unsuspecting node. 995 This vulnerability is avoided by always binding the PCoA to the NAR's 996 IP address, even when the NAR supplies an NCoA to use for the MN. It 997 is still possible to jam NAR's buffer with redirected traffic. 998 However, the handover state corresponding to the MN's PCoA has a 999 finite lifetime, and can be configured to be a few multiples of the 1000 anticipated handover latency. Hence, the extent of this 1001 vulnerability is small. 1003 Communication between the access routers: 1005 The access routers communicate using HI and HAck messages in order to 1006 establish a temporary routing path for the MN undergoing handover. 1007 This message exchange needs to be secured to ensure routing updates 1008 take place as intended. 1010 The HI and HAck messages need to be secured using a pre-existing 1011 security association between the access routers to ensure at least 1012 message integrity and authentication, and should also include 1013 encryption. 1015 9. IANA Considerations 1017 The IANA assignments necessary for messages, extensions and options 1018 specified in this document are described in the following paragraphs. 1020 This document defines two new messages that use the Mobile IPv4 1021 control message format [rfc3344]. These message details are as 1022 follows: 1024 +------+-------------+-------------+ 1025 | Type | Description | Reference | 1026 +------+-------------+-------------+ 1027 | TBA | FBU | Section 6.1 | 1028 | TBA | FBAck | Section 6.2 | 1029 +------+-------------+-------------+ 1031 This document defines four new experimental ICMP messages that use 1032 the ICMP Type 41 for IPv4. See Section 3 in [rfc4065]. The new 1033 messages specified in this document need Subtype assignment from the 1034 registry in [rfc4065]: 1036 +---------+-------------+-------------+ 1037 | Subtype | Description | Reference | 1038 +---------+-------------+-------------+ 1039 | TBA | RtSolPr | Section 6.3 | 1040 | TBA | PrRtAdv | Section 6.4 | 1041 | TBA | HI | Section 6.5 | 1042 | TBA | HAck | Section 6.6 | 1043 +---------+-------------+-------------+ 1045 This document defines three new options that need Type assignment 1046 from the Mobile IP Extensions for ICMP Router Discovery messages 1047 [rfc3344]. These options are as follows: 1049 +------+------------------+-------------+ 1050 | Type | Description | Reference | 1051 +------+------------------+-------------+ 1052 | TBA | LLA | Section 7.1 | 1053 | TBA | New IPv4 Address | Section 7.2 | 1054 | TBA | NAR Prefix Info | Section 7.3 | 1055 +------+------------------+-------------+ 1057 The MN-PAR Authentication Extension described in Section 6.1 and 1058 Section 6.2 is a Generalized Mobile IP Authentication Extension 1059 defined in Section 5 of [rfc4721]. The MN - PAR Authentication needs 1060 a Subtype assignment from the registry specified in [rfc4721]. The 1061 Extension details are as follows: 1063 +---------+-----------------------+--------------------------+ 1064 | Subtype | Description | Reference | 1065 +---------+-----------------------+--------------------------+ 1066 | TBA | MN-PAR Auth Extension | Section 6.1, Section 6.1 | 1067 +---------+-----------------------+--------------------------+ 1069 10. Acknowledgement 1071 Thanks to all those who expressed interest in having a Fast Handovers 1072 for Mobile IPv4 protocol along the lines of [rfc4068]. Thanks to 1073 Vijay Devarapalli, Kent Leung and Domagoj Premec for their review and 1074 input. Kumar Viswanath and Uday Mohan implemented an early version 1075 of this protocol. Many thanks to Alex Petrescu for his thorough 1076 review that improved this document. Thanks to Pete McCann for the 1077 proofreading, and to Jari Arkko for the review which have helped 1078 improve this document. 1080 11. References 1082 11.1. Normative References 1084 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1085 Requirement Levels", BCP 14, RFC 2119, March 1997. 1087 [rfc1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1088 September 1991. 1090 [rfc2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1091 (IPv6) Specification", RFC 2460, December 1998. 1093 [rfc3344] Perkins (Editor), C., "IP Mobility Support for IPv4", 1094 RFC 3344, August 2002. 1096 [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental 1097 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 1099 [rfc4068] Koodli (Editor), R., "Fast Handovers for Mobile IPv6", 1100 RFC 4068, July 2005. 1102 [rfc4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 1103 Challenge/Response Extensions (Revised)", RFC 4721, 1104 January 2007. 1106 11.2. Informative References 1108 [draft-mip4-ro] 1109 Perkins, C. and D. Johnson, "Route Optimization in Mobile 1110 IP (work in progress). Internet Draft, Internet 1111 Engineering Task Force", February 2000. 1113 [ieee-802.11r] 1114 "IEEE Standard for Local and Metropolitan Area Networks: 1115 Fast Roaming/Fast BSS Transition, the IEEE Task Group TGr. 1116 Technical report, IEEE.". 1118 [ieee-802.1x] 1119 "IEEE Standard for Local and Metropolitan Area Networks: 1120 Port-Based Network Access Control. Technical report, 1121 IEEE.". 1123 [ieee-802.21] 1124 "The IEEE 802.21 group. http://www.ieee802.org/21.". 1126 [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", 1127 RFC 2131, March 1997. 1129 [rfc3957] Perkins, C. and P. Calhoun, "Authentication, 1130 Authorization, and Accounting (AAA) Registration Keys for 1131 Mobile IPv4", RFC 3957, March 2005. 1133 Appendix A. Change Log 1135 Addressed the following Last Call and subsequent reviews: 1137 Addressed AD review 1139 Addressed Shepherd review input 1141 Provided all the Code values in PrRtAdv message to cover various 1142 cases involving neighborhood discovery. Harmonized the option 1143 formats with [rfc4068]. 1145 Added the Terminology Section 1147 Added text regarding FBU message flags 'S' and 'B' 1149 Revised text in Security Considerations 1150 Clarified text in different places based on ML comments (including 1151 "forwarding", MN's use of assigned addresses in lieu of DHCP, and 1152 so on.) 1154 Clarified using ICMPv4 checksum for RtSolPr, PrRtAdv, HI and HAck 1156 Added Figures illustrating predictive and reactive handovers 1158 Added references to IEEE 802.21 and IEEE 802.11r 1160 All id nits (attempt to move from LaTex to xml turned out to be 1161 quite a task, sigh..) 1163 Authors' Addresses 1165 Rajeev Koodli 1166 Nokia Research Center 1167 975 Page Mill Road, 200 1168 Palo Alto, CA 94304 1169 USA 1171 Email: rajeev.koodli@nokia.com 1173 Charles Perkins 1174 Nokia Research Center 1175 975 Page Mill Road, 200 1176 Palo Alto, CA 94304 1177 USA 1179 Email: charles.perkins@nokia.com 1181 Full Copyright Statement 1183 Copyright (C) The IETF Trust (2007). 1185 This document is subject to the rights, licenses and restrictions 1186 contained in BCP 78, and except as set forth therein, the authors 1187 retain all their rights. 1189 This document and the information contained herein are provided on an 1190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1192 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1193 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1194 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1197 Intellectual Property 1199 The IETF takes no position regarding the validity or scope of any 1200 Intellectual Property Rights or other rights that might be claimed to 1201 pertain to the implementation or use of the technology described in 1202 this document or the extent to which any license under such rights 1203 might or might not be available; nor does it represent that it has 1204 made any independent effort to identify any such rights. Information 1205 on the procedures with respect to rights in RFC documents can be 1206 found in BCP 78 and BCP 79. 1208 Copies of IPR disclosures made to the IETF Secretariat and any 1209 assurances of licenses to be made available, or the result of an 1210 attempt made to obtain a general license or permission for the use of 1211 such proprietary rights by implementers or users of this 1212 specification can be obtained from the IETF on-line IPR repository at 1213 http://www.ietf.org/ipr. 1215 The IETF invites any interested party to bring to its attention any 1216 copyrights, patents or patent applications, or other proprietary 1217 rights that may cover technology that may be required to implement 1218 this standard. Please address the information to the IETF at 1219 ietf-ipr@ietf.org. 1221 Acknowledgment 1223 Funding for the RFC Editor function is provided by the IETF 1224 Administrative Support Activity (IASA).