idnits 2.17.1 draft-ietf-mip4-dynamic-assignment-01.txt: -(929): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.5 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1000. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 987), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 894. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 59 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 37 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 87: '... node MUST use Network Access I...' RFC 2119 keyword, line 232: '...A assignment, MN MUST use NAI and obta...' RFC 2119 keyword, line 279: '... It MUST be included in Registr...' RFC 2119 keyword, line 290: '...icast IP address MUST be used as HA ad...' RFC 2119 keyword, line 294: '...nce of an FA, FA MUST forward RRQ to t...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 26 has weird spacing: '... The list ...' == Line 108 has weird spacing: '... using any ...' == Line 111 has weird spacing: '...cluding but ...' == Line 117 has weird spacing: '...address of 2...' == Line 128 has weird spacing: '... If regis...' == (54 more instances...) -- 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) == Unused Reference: '6' is defined on line 925, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3012 (ref. '5') (Obsoleted by RFC 4721) -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Milind Kulkarni 3 INTERNET-DRAFT Alpesh Patel 4 Category: Standards Track Kent Leung 5 Date : 28 April 2004 Cisco Systems Inc. 7 Mobile IPv4 Dynamic Home Agent Assignment 8 draft-ietf-mip4-dynamic-assignment-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Mobile IP (RFC 3344) uses the Home Agent (HA) to anchor 35 sessions of a roaming Mobile Node (MN). This draft proposes a 36 messaging mechanism for dynamic home agent assignment and HA 37 redirection. The goal is to provide a mechanism to assign an 38 optimal HA for a Mobile IP session while allowing any suitable 39 method for HA selection. 41 Table of Contents 43 1. Introduction.....................................................2 44 2. Terminology.......................................................3 45 3. Problem Statement.................................................4 46 3.1 Scope............................................................5 47 3.2 Dynamic Home Agent Discovery in RFC 3344.........................5 48 3.3 NAI usage and dynamic HA assignment..............................5 49 3.4 Dynamic HA extension.............................................5 50 3.4.1 Redirected HA extension........................................6 51 3.4.2 Requested HA extension.........................................6 52 4. Messaging mechanism for dynamic HA assignment/redirection.........7 53 4.1 Messaging for dynamic HA assignment..............................7 54 4.1.1 Example with Message Flow Diagram..............................7 55 4.2 Messaging for HA redirection.....................................9 56 4.2.1 Example with Message Flow Diagram.............................10 57 5. Mobility Agent Considerations for dynamic HA assignment..........11 58 5.1 Mobile Node Considerations......................................11 59 5.1.1 MN using FA CoA...............................................12 60 5.1.2 MN using Collocated CoA.......................................12 61 5.1.3 Refreshing Assigned HA Address on Mobile Node.................13 62 5.2 Foreign Agent Considerations....................................13 63 5.3 Home Agent Considerations.......................................13 64 5.3.1 Assigned Home Agent Considerations............................14 65 6. Requested Home Agent Selection...................................16 66 7. Error Values.....................................................17 67 8. IANA Considerations..............................................17 68 9. Security Considerations..........................................17 69 9.1 Message Authentication Codes....................................17 70 9.2 Areas of Security Concern in this Protocol......................18 71 10. Backward Compatibility Considerations...........................18 72 11. Change Log from previous version................................19 73 12. Intellectual Property Rights....................................19 74 13. Acknowledgements................................................19 75 14. References......................................................19 76 Authors' Addresses..................................................20 77 Full Copyright Statement............................................20 78 Intellectual Property...............................................21 79 Acknowledgement.....................................................21 81 1. Introduction 83 This document adds to the Mobile IP protocol [1], by proposing 84 a messaging mechanism for dynamic home agent assignment and 85 home agent redirection during initial registration. The goal is 86 to assign an optimal HA for a Mobile IP session. The mobile 87 node MUST use Network Access Identifier (NAI) extension for 88 home address assignment. 90 MN requests the network to dynamically assign an HA by setting 91 HA field to ALL-ZERO-ONE-ADDR (defined in next section) in 92 initial Registration Request. If the request is accepted, the 93 HA field in successful Registration Reply contains the HA 94 address. The requested HA can suggest an alternate HA and if 95 so, the Registration Reply is rejected with a new error code 96 (REDIRECT-HA-REQ) and the alternate HA address is specified in 97 a new extension (Redirected HA extension). 99 If the RRQ is rejected with Redirected HA extension or if the 100 MN wishes to register at a specific HA, MN can put the HA 101 address in the Requested HA extension in Registration Request. 102 The HA address in Requested HA extension is a hint to the 103 network where the MN may be anchored. The HA field is set to 104 ALL-ZERO-ONE-ADDRESS for dynamic HA assignment. 106 The messaging mechanism proposed here is generic and can be 107 used as a common foundation to facilitate dynamic HA assignment 108 using any suitable method. No specific method is either 109 mandated or suggested. The HA receiving Registration Request 110 may suggest an alternate HA (HA redirection) for a number of 111 reasons; including but not limited to HA load-balancing, 112 geographical proximity, administrative policy etc. 114 2. Terminology 116 ALL-ZERO-ONE-ADDR: IP address 0.0.0.0 or 255.255.255.255. An 117 address of 255.255.255.255 would indicate 118 assigning HA in home domain. An address of 119 0.0.0.0 would mean MN just needs a dynamic 120 HA, it does not care whether in home or 121 visited domain. 123 Requested HA: Destination IP address of Home Agent that the 124 first Registration Request is sent to. Must 125 be a unicast IP address. This address can be 126 obtained as described in section 5.4. 128 Assigned HA: If registration is successful, this Home 129 Agent address field is obtained from 130 successful Registration Reply. 132 Redirected HA: If the registration is rejected with error 133 code (REDIRECT-HA-REQ), the HA being referred 134 to is specified in a new extension 135 (Redirected HA extension). 137 AAA server: Authentication, Authorization and Accounting 138 Server. 140 DNS: Domain Name Service. 142 DHCP: Dynamic Host Configuration Protocol. 144 MN: Mobile Node as defined in RFC 3344. 146 HA: Home Agent as defined in RFC 3344. 148 FA: Foreign Agent as defined in RFC 3344. 150 CoA: Care of Address. 152 CCoA: Collocated Care of Address. 154 MN HoA: Mobile Node's Home Address. 156 NAI: Network Access Identifier [2]. 158 Src IP: Source IP address of the packet. 160 Dest IP: Destination IP address of the packet. 162 3. Problem Statement 164 Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept 165 of identifying a MN by the NAI and enabling dynamic home 166 address assignment. When the home address is dynamically 167 assigned, it is desirable to discover the Home Agent 168 dynamically or inform the MN about an optimal HA to use for a 169 multitude of reasons, such as: 171 - If the distance between the visited network and the home 172 network of the mobile node is large, the signaling delay for 173 these registrations may be long. In such a case the MN will be 174 anchored to its distant home agent, resulting in tunneled 175 traffic traveling a long distance between home agent and the 176 mobile node. When a Mobile IP session initiates, if the mobile 177 node can be assigned a home agent, which is close to the mobile 178 node, it can drastically reduce the latency between the home 179 agent and mobile node. 181 - Also, in a large scale Mobile IP deployment, it is cumbersome 182 to provision MNs with multiple HA addresses. 184 - It is desirable to achieve some form of load balancing 185 between multiple HAs in the network. Dynamic HA assignment 186 and/or HA redirection lets the network select the optimal HA 187 from among a set of HAs and thus achieve load balancing among a 188 group of HAs. 190 - Local administrative policies is yet another reason for 191 dynamic HA assignment/HA redirection during the start of a 192 Mobile IP session. 194 - The problem of discovering a Mobile node�s HA address is 195 acknowledged in the MIPv6 working group as part of [8]. 197 3.1 Scope 199 This specification assumes that the Mobile Node and Assigned 200 Home Agent are in the same administrative domain. The scenario 201 where the Mobile Node and its anchoring Assigned Home Agent are 202 in different administrative domain is beyond the scope of this 203 specification. 205 The draft introduces the terms Requested/Assigned/Redirected HA 206 (section 5.4). These terms are merely HA addresses and used 207 depending upon the direction of the registration request or 208 reply. The discovery of Requested/Assigned/Redirected HA can be 209 done by various means, which are network and/or deployment 210 specific and hence this discovery/assignment of 211 Requested/Assigned/Redirected HA is kept outside the scope of 212 this specification. 214 3.2 Dynamic Home Agent Discovery in RFC 3344 216 Mobile IP RFC 3344 specifies the mechanism for discovering the 217 mobile node's home agent using subnet-directed broadcast IP 218 address in the home agent field of the Registration Request. 219 This mechanism was designed for mobile nodes with a static home 220 address and subnet prefix, anchored on fixed home network. But 221 using subnet-directed broadcast as the destination IP address 222 of the Registration Request, it is unlikely that the 223 Registration Request will reach the home subnet because routers 224 will drop these packets by default. See CERT Advisory CA-1998- 225 01 Smurf IP Denial-of-Service Attacks [3]. 227 3.3 NAI usage and dynamic HA assignment 229 Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept 230 of identifying a MN by the NAI and enabling dynamic home 231 address assignment. This document mandates that while using 232 dynamic HA assignment, MN MUST use NAI and obtain a home 233 address. MN can still suggest a static home address in 234 Registration Request, but must take the address in Registration 235 Reply as the home address for the session. This reference to 236 obtaining home address using NAI is as per [2]. 238 3.4 Dynamic HA extension 239 The Dynamic HA extension, shown in figure 1, contains the 240 address of the HA. This is a generic extension and can be used 241 in Registration Request and Reply messages. It is a skippable 242 extension. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Sub-Type | Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | HA-Address... 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 1: The Dynamic HA address Extension 254 Type DYNAMIC-HA-ADDRESS (skippable) [1] (to be 255 assigned by IANA) is the type, which specifies the 256 dynamic HA address. 258 Sub-Type is a unique number given to each member in the 259 aggregated type. 261 Length Indicates the length of the extension not including 262 the type, sub-type and length fields. 264 HA-Address The address of HA 266 3.4.1 Redirected HA extension 268 The format of the Redirected HA extension is as defined in 269 section 3.4. This extension uses the subtype value of 1. This 270 extension has the length field set to 4. 272 The Redirected HA extension, contains the address of the HA 273 where the MN should attempt the next registration. The HA 274 receiving a Registration Request can suggest an alternate HA 275 and if so, the Registration Reply is rejected with a new error 276 code (REDIRECT-HA-REQ) and the alternate HA address is 277 specified in this extension. 279 It MUST be included in Registration Reply when the reply code 280 is REDIRECT-HA-REQ. 282 3.4.2 Requested HA extension 283 The format of the Requested HA address extension is as defined 284 in section 3.4. This extension uses the subtype value of 2. 285 This extension has the length field set to 4. 287 MN may include the Requested HA extension in the registration 288 request as a hint to the network where it wishes to be 289 anchored. This extension contains the address of the HA. A 290 valid unicast IP address MUST be used as HA address in this 291 extension. 293 In absence of an FA, the RRQ is forwarded to this HA. In 294 presence of an FA, FA MUST forward RRQ to the HA address in 295 this extension. 297 4. Messaging mechanism for dynamic HA assignment/redirection 299 4.1 Messaging for dynamic HA assignment 301 1. MN sets the Home Agent address field in the Registration 302 Request to ALL-ZERO-ONE-ADDR. 304 If the MN is aware of an HA address, it can add that 305 address in the Requested HA extension in Registration 306 Request. 307 2. The MN (if using collocated CoA) or FA (if using FA CoA) 308 sends the Registration Request to the "Requested HA". 310 If the Requested HA extension is present, Requested HA is 311 the HA address in this extension. 312 3. "Requested HA" is the home agent, which processes the 313 Registration Request in accordance with RFC 3344 and as 314 per the specification in this document. It creates 315 mobility binding for successful Registration Request. It 316 also sends Registration Reply to the MN. 317 4. The MN obtains an "Assigned HA" address from the HA field 318 in the successful Registration Reply and uses it for the 319 remainder of the session. 320 5. Subsequent Registration Request messages for renewal are 321 sent to the Assigned HA. 323 Section 5.3.1 describes the Assigned HA in detail. Some ideas 324 on how to select the Requested HA are briefly covered in 325 section 6. 327 4.1.1 Example with Message Flow Diagram 329 Detailed explanation of this specification is best described 330 with the help of a railroad diagram and description. 332 Figure 2 shows one specific example of a Mobile Node using FA 333 Care of Address. 335 Other scenarios such as mobile node using collocated care of 336 address are not described below, but the behavior is similar. 338 MN FA Requested/Assigned HA 339 | 1 | | 340 |------------>| 2 | 341 | |--------------->| 342 | | | 343 | | | 344 | | 3 | 345 | 4 |<---------------| 346 |<------------| | 347 | | | 348 | | 5 | 349 |----------------------------->| 350 | | | 352 Figure 2: Example of Message flows for the specification 354 1. MN sets the Home Agent address field in the Registration 355 Request to ALL-ZERO-ONE-ADDR. Since MN is using FA CoA in this 356 example, it sends the Registration Request to the FA. The 357 Registration Request looks as follows: 359 +-----------------------------------------------------------+ 360 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 361 | MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA | 362 +-----------------------------------------------------------+ 364 If the MN is aware of an HA address, it can add that address in 365 the Requested HA extension in Registration Request. That 366 extension is not shown above. 368 2. The FA sends the Registration Request to the Requested HA. 369 The Registration Request looks as follows: 371 +-----------------------------------------------------------+ 372 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 373 | FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA | 374 +-----------------------------------------------------------+ 376 If MN had included the Requested HA extension, the Registration 377 Request is sent to the HA address in that extension. 379 3. HA processes the Registration Request in accordance with RFC 380 3344 and the messaging defined in this document. HA creates 381 mobility binding for successful request. HA then sends 382 Registration Reply to the FA, which looks as follows. The 383 Assigned HA address corresponds to the HA receiving and 384 processing the request (and is same as Requested HA, only the 385 name is changed for registration reply). 387 +-----------------------------------------------------------+ 388 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 389 |Assigned|CoA or NATed| | Assigned HA |FA CoA/| 390 | HA | Src IP | | | | 391 +-----------------------------------------------------------+ 393 4. The FA relays the Registration Reply to the MN, as follows. 395 +-----------------------------------------------------------+ 396 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 397 | FA | MN | | Assigned HA |FA CoA/| 398 +-----------------------------------------------------------+ 400 5. The MN obtains Assigned HA address from the HA field in the 401 successful Registration Reply and uses it for the remainder of 402 the session. MN sends subsequent Re-Registration or De- 403 Registration Requests for the remaining session directly to the 404 Assigned HA. 406 4.2 Messaging for HA redirection 408 1. MN sets the Home Agent address field in the Registration 409 Request to ALL-ZERO-ONE-ADDR. 410 2. The MN (if using collocated CoA) or FA (if using FA CoA) 411 sends the Registration Request to the "Requested HA". If 412 the MN is aware of an HA address, it can add that address 413 in the Requested HA extension in Registration Request. 415 3. When HA receives the Registration Request, if the HA field 416 is set to ALL-ZERO-ONE-ADDR, HA may reject the request 417 with Reply code REDIRECT-HA-REQ and suggest an alternate 418 HA. 420 HA may reject the Request for a number of reasons, which 421 are outside the scope of this specification. If the HA 422 rejects the Request, the HA field in the Reply is set to 423 this HAs address. The HA that is being referred to is 424 specified in Redirected HA extension. The presence of this 425 extension is mandatory when the reply code is set to 426 REDIRECT-HA-REQ. HA sends the Reply to the FA/MN 427 4. FA sends the Reply to the MN. 429 5. If the error code is set to REDIRECT-HA-REQ, MN obtains 430 the HA address from Redirected HA extension and sends a 431 Registration Request to this HA. 433 4.2.1 Example with Message Flow Diagram 435 Figure 3 shows one specific example of a Mobile Node using FA 436 Care of Address. 438 MN FA Requested HA Redirected HA 439 | 1 | | | 440 |------------>| 2 | | 441 | |--------------->| | 442 | | | | 443 | | | | 444 | | 3 | | 445 | 4 |<---------------| | 446 |<------------| | | 447 | | | | 448 | | 5 | | 449 |-------------------------------------------------> | 450 | | | | 452 Figure 3: Example of Message flows for the specification 454 1. MN sets the Home Agent address field in the Registration 455 Request to ALL-ZERO-ONE-ADDR address. Since MN is using FA CoA 456 in this example, it sends the Registration Request to the FA. 457 The Registration Request looks as follows: 459 +-----------------------------------------------------------+ 460 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 461 | MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA | 462 +-----------------------------------------------------------+ 464 If the MN is aware of an HA address, it can add that address in 465 the Requested HA extension in Registration Request. That 466 extension is not shown above. 468 2. The FA sends the Registration Request to the Requested HA. 469 If Requested HA extension is present, Requested HA is the HA 470 address in this extension. The Registration Request looks as 471 follows: 473 +-----------------------------------------------------------+ 474 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 475 | FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA | 476 +-----------------------------------------------------------+ 478 3. HA processes the Registration Request in accordance with RFC 479 3344 and the messaging defined in this document. If the 480 registration is successful, but local configuration/ 481 administrative policy etc. directs HA to refer the MN to 482 another HA, HA rejects the Request with error code REDIRECT-HA- 483 REQ. HA fills in the address of the directed HA in the 484 Redirected HA extension. HA then sends Registration Reply 485 reject to the FA, which looks as follows: 487 +-----------------------------------------------------------+ 488 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 489 | |CoA or NATed| | HA |FA CoA | 490 | HA | Src IP | | | | 491 +-----------------------------------------------------------+ 492 | Redirected HA extension ... 493 +-----------------------------------------------------------+ 495 4. The FA relays the Registration Reply to the MN, as follows. 497 +-----------------------------------------------------------+ 498 | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | 499 | FA | MN | | HA |FA CoA/| 500 +-----------------------------------------------------------+ 501 | Redirected HA extension ... 502 +-----------------------------------------------------------+ 504 5. If MN can authenticate the Reply, MN extracts the HA address 505 from Redirected HA extension and sends Registration Request to 506 this HA. 508 5. Mobility Agent Considerations for dynamic HA assignment 510 Following sections describe the behavior of each mobility agent 511 in detail. 513 5.1 Mobile Node Considerations 515 The mobile node MUST use NAI extension for home address 516 assignment when using the messaging mechanism in this document. 517 While dynamic HA assignment is in progress and MN has not 518 successfully anchored at a Home Agent, mobile node MUST set the 519 Home Agent field in the Registration Request to an ALL-ZERO- 520 ONE-ADDR, which is either 255.255.255.255 or 0.0.0.0. 522 The Registration Request MUST be protected by a valid 523 authenticator as specified in [1] or [5]. Configuring security 524 associations is deployment specific and hence outside the scope 525 of this specification. The security associations between a MN 526 and an individual HA may also be dynamically derived during the 527 dynamic HA assignment, based on a shared secret between MN and 528 AAA infrastructure. 530 The mobile node must maintain the remaining Mobile IP session 531 with the Assigned HA. Following sections describe MN behavior 532 in FA CoA mode and collocated CoA mode. 534 5.1.1 MN using FA CoA 536 When a mobile node initiates Mobile IP session requesting 537 dynamic HA assignment, it MUST set the home agent address field 538 in the Registration Request to ALL-ZERO-ONE-ADDR. The 539 destination IP address of Registration Request is the FA. The 540 FA will determine the Requested HA and forward the Registration 541 Request to the Requested HA. Registration Request processing 542 takes place on the Requested HA as per the specification in 543 this draft. 545 The Registration Request MUST be appropriately authenticated 546 for the HA to validate the Request. 548 If successful Registration Reply is received, MN obtains 549 Assigned HA from the HA field of Reply. 551 If Registration Reply is received with code REDIRECT-HA-REQ, MN 552 MUST authenticate the Reply based on HA address in HA field of 553 Reply and attempt Registration with the HA address specified in 554 the Redirected HA extension. In some cases, MN may want to hint 555 to the network to be anchored at a specific HA. In both these 556 cases, MN MUST put the HA address in the Requested HA extension 557 in Registration Request. 559 5.1.2 MN using Collocated CoA 561 Mobile Node in collocated CoA mode requesting dynamic HA 562 assignment MUST set the home agent address field in the 563 Registration Request to ALL-ZERO-ONE-ADDR. The destination IP 564 address of the Registration Request is the Requested HA. Some 565 ideas to select a Requested HA are briefly covered in section 566 6. 568 If successful Reply is received, the MN obtains Assigned HA 569 address from successful Registration Reply. The MN MUST cache 570 the Assigned HA address for the length of the Mobile IP 571 session. The mobile node then MUST use this previously cached 572 Assigned HA address as the home agent address in subsequent re- 573 registration and de-registration request(s). This will make 574 sure that the mobile node will always be anchored to the 575 assigned home agent with which it was initially registered. 577 If Registration Reply is received with code REDIRECT-HA-REQ, MN 578 MUST authenticate the Reply based on HA address in HA field of 579 Reply and attempt Registration with the HA address specified in 580 the Redirected HA extension. In some cases, MN may want to hint 581 to the network to be anchored at a specific HA. In both these 582 cases, MN MUST put the HA address in the Requested HA extension 583 in Registration Request. 585 While requesting dynamic HA assignment in collocated CoA mode, 586 Requested HA extension must always be included. 588 5.1.3 Refreshing Assigned HA Address on Mobile Node 590 When the Mobile IP session terminates, the mobile node MAY 591 clear the Assigned HA address cached as the home agent address. 592 It MAY request a new HA address for the new Mobile IP session 593 by not including the Requested HA extension. The advantage of 594 this approach is that the mobile node will be always anchored 595 to an optimal home agent from where it initiated Mobile IP 596 session. 598 Alternately, MN may save the Assigned HA address and use it in 599 the Requested HA extension along with ALL-ZERO-ONE HA address 600 in Registration Request. 602 5.2 Foreign Agent Considerations 604 When the mobile node is using foreign agent CoA, it sends the 605 Registration Request to the foreign agent. When the FA receives 606 a Registration Request with HA address field set to ALL-ZERO- 607 ONE-ADDR, it obtains the Requested HA address to forward the 608 Registration Request. Some ideas to select a Requested HA are 609 briefly covered in section 6. 611 If the FA cannot obtain the Requested HA to forward a 612 Registration Request from MN, it MUST reject request with error 613 code NONZERO-HA-REQD. 615 If the MN has included the Requested HA extension, FA MUST 616 forward Registration Request to the address in this extension. 617 If the HA address in this extension is not a routable unicast 618 address, FA MUST reject request with error code NONZERO-HA- 619 REQD. 621 Backward compatibility issues related to the mobility agents 622 are addressed in section 9. 624 5.3 Home Agent Considerations 625 Home Agent can process an incoming Registration Request in one 626 of the following three ways: 628 MN or FA sends the Registration Request to the Requested HA. 629 The term Requested HA has meaning in context of the 630 Registration Request message. When the Requested HA 631 successfully processes Registration Request and creates a 632 binding and sends a Reply with its address, it becomes the 633 Assigned HA. The term Assigned HA is meaningful in context of a 634 Registration Reply message. 636 Home Agent receiving the request with HA field set to ALL-ZERO- 637 ONE-ADDR MAY reject the request even if successfully 638 authenticated for a multitude of reasons and suggest an 639 alternate HA address in Reply. In such a case, the HA puts its 640 own address in HA field of Reply and sets the Reply code to 641 REDIRECT-HA-REQ and adds the Redirected HA extension. 643 If the Registration Request contains the Requested HA 644 extension, the HA address in that extension must match the 645 destination IP of the Request. 647 5.3.1 Assigned Home Agent Considerations 649 The HA that processes the incoming Registration Request fully 650 in accordance with RFC 3344 and this specification becomes the 651 Assigned HA. The Registration Request terminates at the 652 Assigned HA. 654 The Assigned HA creates mobility bindings and sends 655 Registration Reply to the MN by copying its address in the home 656 agent field and as the source IP address of the Reply. 658 There are two IP addresses to consider, destination IP address 659 and Home Agent address field in the Registration Request. When 660 destination IP address is unicast, only one HA receives the 661 Registration Request. This HA should unambiguously accept or 662 deny the registration, regardless of the value in the Home 663 Agent field. When the Home Agent field is non-unicast, the HA 664 should set the value to its own IP address in the Registration 665 Reply. 667 The following table summarizes the behavior of Assigned HA. 669 No. Dest IP Addr HA field Processing at Assigned HA 670 -- ------------ ------------ ------------------------------- 671 1 Unicast non-unicast RFC 3344: HA denies the 672 registration with error code 673 136 and sets HA field to its 674 own IP address in the reply as 675 per section 3.8.3.2. 677 ALL-ZERO- New Behavior: Accept the RRQ as 678 ONE-ADDR per this specification. 679 Authenticate the RRQ and create 680 mobility binding if the HA is 681 acting as Assigned HA. Set HA 682 field to its own IP address in 683 the Registration Reply. 685 OR 687 New Behavior: Dest IP 688 corresponds to the HA receiving 689 RRQ, if authentication is 690 successful, reject RRQ with a 691 new error code (REDIRECT-HA- 692 REQ). HA puts its address in HA 693 address field of Reject. HA 694 suggests an alternate HA to use 695 in the new Redirected HA 696 extension 698 Table 1: Registration Request handling at Assigned HA 700 This specification also proposes a subtle difference in 701 behavior for case #1 above from RFC 3344. As per the messaging 702 proposed here, the mobile node (or the foreign agent) sends the 703 Registration Request to the Requested HA address, which is a 704 unicast address. Because HA does not receive Registration 705 Request that is sent to the subnet-directed broadcast address, 706 RFC 3344 section 3.8.2.1 doesn't apply. Although the Home 707 Agent field in the Registration Request is not a unicast 708 address, the destination IP address is a unicast address. This 709 avoids the problem associated with subnet-directed broadcast 710 destination IP address that may result in multiple HAs 711 responding. Thus, there is no need to deny the registration as 712 stated in RFC 3344 section 3.8.3.2. 714 When the destination IP address is a unicast address and Home 715 Agent field is ALL-ZERO-ONE-ADDR, the HA accepts/denies 716 registration and sets HA field to its own IP address in the 717 reply (i.e. registration is not rejected with error code 136). 718 HA can reject the request with the error code REDIRECT-HA-REQ 719 and suggest an alternate HA. This redirection can be used for 720 load-balancing, geographical proximity based on care-of-address 721 or a multitude of reasons. HA puts its own address in HA field 722 on Registration Reply message and put the address of the 723 redirected HA in the Redirected HA extension. If HA accepts the 724 Request, HA field in Reply is set to this HA address. 726 The Assigned HA performs standard validity checks on the 727 Registration Request. If there is any error, the Registration 728 Request is rejected with error codes specified in RFC 3344. 730 6. Requested Home Agent Selection 732 The destination IP address of the Registration Request when 733 dynamic HA assignment is requested, is the Requested HA. This 734 address MUST be a unicast IP address. If the MN has included a 735 Requested HA extension in Registration Request, the HA address 736 in this extension is the Requested HA. 738 Some ideas on how to select the Requested HA are briefly 739 covered in this section, however this draft neither suggests 740 nor mandates any specific mechanism. There can be more methods 741 for selecting the HA to the MN. Here is a high level overview 742 of some possibilities: 744 DHCP: 746 MN performs DHCP to obtain an IP address on the visited 747 network. The Requested HA is learned from the DHCP Mobile IP 748 Home Agent Option 68 [4]. MN sends Registration Request 749 directly to this HA and receives the Assigned HA to be used for 750 the remainder of the Mobile IP session. 752 AAA: 754 MN performs challenge/response [5] with the FA. The FA 755 retrieves the Requested HA from the AAA server and forwards the 756 Registration Request directly to this HA. The Assigned HA 757 sends Registration Reply to the FA, which relays it to the MN. 758 MN uses the Assigned HA for the remainder of the Mobile IP 759 session. 761 DNS: 763 In this case hostname of HA is configured on MN or obtained by 764 some other means � e.g. using a service location protocol. MN 765 performs DNS lookup on the HA hostname. The DNS infrastructure 766 provides resource record with information to identify the 767 nearest HA to the MN. The MN sends Registration Request 768 directly to the HA and receives the Assigned HA to be used for 769 remainder of the Mobile IP session. 771 Static configuration: 773 HA address is statically configured on MN. The MN uses the 774 configured address to send the Registration Request. 776 7. Error Values 778 Each entry in the following table contains the name and value 779 for the error code to be returned in a Registration Reply. It 780 also includes the section in which the error code is first 781 mentioned in this document. 783 Error Name Value Section Description 784 ---------- ----- ------- ----------------------------- 785 NONZERO-HA-REQD XX 5.2 Non-zero HA address required 786 in Registration Request. 787 REDIRECT-HA-REQ YY 5.3.1 Reregister with redirected HA. 789 8. IANA Considerations 791 The code value NONZERO-HA-REQD defined in Section 7, correspond 792 to error values conventionally associated with the rejection by 793 the foreign agent (i.e. value in the range 64-127). The code 794 value REDIRECT-HA-REQ defined in Section 7, correspond to error 795 values conventionally associated with the rejection by the home 796 agent (i.e. value in the range 128-192). 798 The Dynamic HA extension defined in section 3.4 corresponds to 799 a skippable extension. 801 IANA should record the values as defined in Section 7 and 3.4. 803 9. Security Considerations 805 This specification assumes that the Mobile Node and Assigned 806 Home Agent are in the same administrative domain. This 807 specification does not change or degrade the security model 808 established in RFC-3344. Most of the time Mobile Nodes will be 809 connected to the network via wireless link. Such links are 810 vulnerable to passive eavesdropping, replay attacks or many 811 other types of attacks. They are considered below. 813 9.1 Message Authentication Codes 815 The Registration Request and Registration Reply messages are 816 protected by a valid authenticator as specified in RFC 3344. 817 Configuring security associations is a deployment specific 818 issue and is covered by other specifications in Mobile IP WG. 820 There can be many ways of configuring security associations, 821 but this specification does not mandate any specific way. 823 An example is where the security association between a MN and 824 an individual HA (Dynamic or Assigned) is dynamically derived 825 during the dynamic HA assignment, based on a shared secret 826 between MN and AAA infrastructure, as defined in [7]. The 827 Registration Request is protected with MN-AAA authentication 828 extension and Registration Reply is protected with MHAE. Since 829 the security association is shared between MN and AAA, any 830 dynamically assigned HA in the local domain can proxy 831 authenticate the MN using AAA as per [7]. 833 The Assigned Home Agent authenticates Registration Request from 834 the mobile node as specified in RFC-3344 and RFC-3012. The MN 835 also authenticates the Registration Reply from the Assigned HA, 836 thus the existing trust model in RFC 3344 is maintained. 838 9.2 Areas of Security Concern in this Protocol 840 As per the messaging in this draft, the Assigned Home Agent 841 will process the incoming Registration Request as per RFC-3344. 842 Hence the Assigned Home Agent will have same security concerns 843 as that of the Home Agent in RFC-3344. They are addressed in 844 Section 5 �Security Considerations� of RFC-3344. 846 10. Backward Compatibility Considerations 848 Legacy Home Agent: 850 Legacy home agents may reject the Registration Request with 851 error code 136 because the Home Agent field is not a unicast 852 address. However, some legacy HA implementations may 853 coincidentally process the Registration Request in accordance 854 with this draft, when the HA field in RRQ is set to ALL-ZERO- 855 ONE-ADDR. 857 Legacy Foreign Agent: 859 Legacy foreign agents may forward Registration Request with 860 home agent field set to ALL-ZERO-ONE-ADDR by setting the 861 destination IP address to ALL-ZERO-ONE-ADDR. This will result 862 packet being dropped or incidentally handled by a next hop HA, 863 adjacent to the FA. 865 Legacy Mobile Node: 867 MN that does not set HA field to ALL-ZERO-ONE-ADDR will 868 continue to achieve its registrations through statically 869 configured HA. In collocated mode, the endpoint of the MN's 870 tunnel is the Assigned HA. 872 11. Change Log from previous version 874 1. Added subtype field in Redirected HA Address Extension. 875 2. Aligned the HA address at 4-byte world boundary. 876 3. The case of handling unicast HA field is removed in section 877 5.3.1. 879 12. Intellectual Property Rights 881 The IETF takes no position regarding the validity or scope of 882 any intellectual property or other rights that might be claimed 883 to pertain to the implementation or use of the technology 884 described in this document or the extent to which any license 885 under such rights might or might not be available; neither does 886 it represent that it has made any effort to identify any such 887 rights. Information on the IETF's procedures with respect to 888 rights in standards-track and standards-related documentation 889 can be found in BCP-11. Copies of claims of rights made 890 available for publication and any assurances of licenses to be 891 made available, or the result of an attempt made to obtain a 892 general license or permission for the use of such proprietary 893 rights by implementers or users of this specification can be 894 obtained from the IETF Secretariat. 896 The IETF invites any interested party to bring to its attention 897 any copyrights, patents or patent applications, or other 898 proprietary rights, which may cover technology that may be 899 required to practice this standard. Please address the 900 information to the IETF Executive Director. 902 13. Acknowledgements 904 The authors would like to thank Pete McCann for suggestions on 905 security considerations and definition of ALL-ZERO-ONE-ADDR. 906 Thanks to Kuntal Chowdhury for extensive review and comments on 907 this draft. Also thanks to Henrik Levkowetz for detailed 908 reviews and suggestions. 910 The authors would like to thank Mike Andrews, Madhavi Chandra 911 and Yoshi Tsuda for their review and suggestions. 913 14. References 915 [1] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August 916 2002. 917 [2] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier 918 Extension for IPv4", RFC 2794, March 2000. 919 [3] D. Senie, "Changing the Default for Directed Broadcasts in 920 Routers", RFC 2644, August 1999. 921 [4] S. Alexander and R. Droms, "DHCP Options and BOOTP Vendor 922 Extensions", RFC 2132, March 1997. 923 [5] C. Perkins and P. Calhoun, "Mobile IPv4 Challenge/Response 924 Extensions", RFC 3012, November 2000. 925 [6] H. Levkowetz and S. Vaarala, "Mobile IP Traversal of Network 926 Address Translation (NAT) Devices", RFC 3519, April 2003. 927 [7] C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile 928 IP", draft-ietf-mobileip-aaa-key-13.txt, 22 June 2003. 929 [8] Jari Arkko, et. al., �Thoughts on bootstrapping mobility 930 securely� as presented at 57th IETF in Vienna, Austria, 16th 931 July, 2003 933 Authors' Addresses 935 Milind Kulkarni 936 Cisco Systems Inc. 937 170 W. Tasman Drive, 938 San Jose, CA 95134 939 USA 941 Email: mkulkarn@cisco.com 942 Phone:+1 408-527-8382 944 Alpesh Patel 945 Cisco Systems Inc. 946 170 W. Tasman Drive, 947 San Jose, CA 95134 948 USA 950 Email: alpesh@cisco.com 951 Phone:+1 408-853-9580 953 Kent Leung 954 Cisco Systems Inc. 955 170 W. Tasman Drive, 956 San Jose, CA 95134 957 USA 959 Email: kleung@cisco.com 960 Phone: +1 408-526-5030 962 Full Copyright Statement 963 Copyright (C) The Internet Society (2004). This document is 964 subject to the rights, licenses and restrictions contained in 965 BCP 78 and except as set forth therein, the authors retain all 966 their rights. 968 This document and the information contained herein are provided 969 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 970 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 971 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 972 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 973 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 974 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 975 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 977 Intellectual Property 979 The IETF takes no position regarding the validity or scope of 980 any Intellectual Property Rights or other rights that might be 981 claimed to pertain to the implementation or use of the 982 technology described in this document or the extent to which 983 any license under such rights might or might not be available; 984 nor does it represent that it has made any independent effort 985 to identify any such rights. Information on the procedures 986 with respect to rights in RFC documents can be found in BCP 78 987 and BCP 79. 989 Copies of IPR disclosures made to the IETF Secretariat and any 990 assurances of licenses to be made available, or the result of 991 an attempt made to obtain a general license or permission 992 for the use of such proprietary rights by implementers or 993 users of this specification can be obtained from the IETF 994 on-line IPR repository at http://www.ietf.org/ipr. 996 The IETF invites any interested party to bring to its attention 997 any copyrights, patents or patent applications, or other 998 proprietary rights that may cover technology that may be 999 required to implement this standard. Please address the 1000 information to the IETF at ietf-ipr@ietf.org. 1002 Acknowledgement 1004 Funding for the RFC Editor function is currently provided by 1005 the Internet Society.