idnits 2.17.1 draft-deng-mip6-ha-loadbalance-02.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 493. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 509), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 6) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 29 has weird spacing: '... It is inapp...' == Line 347 has weird spacing: '...ibed in secti...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) -- Looks like a reference, but probably isn't: 'MinRtrAdvInterval' on line 224 -- Looks like a reference, but probably isn't: 'MaxRtrAdvInterval' on line 224 == Unused Reference: '4' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 398, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 402, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 405, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 412, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 417, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) -- No information found for draft-jfaizan-mip6-ha-reliability - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-02) exists of draft-jfaizan-mipv6-vhar-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2408 (ref. '10') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2463 (ref. '11') (Obsoleted by RFC 4443) Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Hui Deng 2 Hitachi (China) 3 Date: October 2004 Brian Haley 4 Hewlett-Packard Company 5 Xiaodong Duan 6 China Mobile 7 Rong Zhang 8 China Telecom 9 Kai Zhang 10 Tsinghua University 12 Load Balance for Distributed Home Agents in Mobile IPv6 13 draft-deng-mip6-ha-loadbalance-02.txt 15 Status of This Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document specifies a dynamic load balance mechanism among 45 multiple home agents by taking into account acceptable number of 46 mobile nodes for each home agent up to now, with the goal of 47 reducing and preventing traffic bottlenecks at the home agent. 48 This mechanism can be used when a home agent is overloaded, wants 49 to achieve better load-balancing with peer home agents, or is going 50 offline for service. 52 TABLE OF CONTENTS 54 Status of This Memo ............................................... i 55 1. Introduction............................................... 1 56 2. Terminology................................................ 1 57 3. Multiple Home Agents....................................... 2 58 4. Modified Home Agents List.................................. 3 59 5. New Load Balance Information Option Format................. 3 60 6. Home Agent Reassignment.................................... 4 61 6.1 Replace Home Agent Selection........................... 4 62 6.2 Home Agent Handoff message............................. 5 63 6.3 Sending Home Agent Handoff messages.................... 6 64 6.4 Receiving Home Agent Handoff messages.................. 6 65 7. IANA Considerations........................................ 6 66 8. Security Considerations.................................... 7 67 References................................................. 8 68 Authors' Addresses......................................... 9 69 A. Changes from Previous Version of the Draft................. 9 70 Intellectual Property and Copyright Statements..............10 72 1. Introduction 74 In Mobile IPv6 [1], home agents are reponsible for the registration 75 of mobile nodes in the home network, intercepting packets destined 76 for them, and tunneling these packets to their care-of address. 77 When the home agent is supporting a large number of mobile nodes and 78 actively tunneling traffic to them, it could become overloaded, 79 leading to dropped packets and connections. Dynamic Home Agent 80 Address Discovery (DHAAD) can be used to find another home agent, 81 but the mobile node has no way of knowing that it should attempt 82 this method until it has problems contacting its current home agent. 84 There are many reasons a home agent might want to reduce the number 85 of mobile nodes it is currently supporting. For example, it might 86 be overloaded, it wants to achieve better load-balancing between a 87 peer home agent, or it is going offline for service. 89 This protocol defines a load balance mechanism among multiple home 90 agents which can effectively release and prevent the formation of 91 traffic bottleneck at the home agent. 93 2 Terminology 95 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [1]. 99 Following terms are not re-defined. They are included for the 100 convenience of the readers. 102 IP 103 Internet Protocol Version 6 (IPv6).[2] 105 Mobile IPv6 106 Mobile IP for IPv6 [3] 108 Home Agent (HA) 109 A router on a MN's home link with which the MN has registered 110 its current Care-of address. While the MN is away from home, 111 the HA intercepts packets on the home link destined to the 112 MN's home address, encapsulates them, and tunnels them to the 113 MN's registered Care-of address. 115 Mobile Node (MN) 117 A node that can change its point of attachment from one link to 118 another, while still being reachable via its home address. 120 Correspondent Node (CN) 122 A peer node with which a mobile node is communicating. The 123 correspondent node may be either mobile or stationary. 125 Security Association (SA) 127 An IPsec security association is a cooperative relationship formed 128 by the sharing of cryptographic keying material and associated 129 context. Security associations are simplex. That is, two 130 security associations are needed to protect bidirectional traffic 131 between two nodes, one for each direction. 133 Dynamic Home Agent Address Discovery (DHAAD) 135 A protocol which describes how a home agent can help mobile nodes to 136 discover the addresses of the home agents [3]. The home agent keeps 137 track of the other home agents on the same link, and responds to 138 queries sent by the mobile node. 140 Home Agents List 142 Home agents need to know which other home agents are on the same 143 link. This information is stored in the Home Agents List, as 144 described in more detail in Section 4. The list is used for 145 informing mobile nodes during dynamic home agent address discovery. 147 Home Agent Handoff (HAH) message 149 This HAH message is used by the home agent to signal the mobile node 150 it should use another Home Agent for subsequent Binding Updates. 152 3. Multiple Home Agents 154 The following Figure gives the topology layout to deploy this 155 protocol for distributed home agents 157 |------------------------------| |---------- 158 | | | | 159 |---| |---| |---| |---| 160 |HA | |HA | |HA | |FA | 161 |---| |---| |---| |---| 162 \ 163 /\ \ /\ 164 /MN\ ------------------- /MN\ 165 /----\ / /----\ 166 / 168 In this protocol, the home network is composed of multiple Mobile 169 IPv6 home agents and multiple mobile nodes. Each home agent in the 170 home network is attached with an access router. When the mobile 171 nodes reside in the home network, the home agents do not execute any 172 home agent tasks. 174 The home agent assignment of the mobile nodes in the home network 175 can be either evenly assigned among the multiple HAs or unevenly 176 assigned. Whether the home agent assignment is even or not would 177 neither arbitrarily affect the original traffic burden problem nor 178 affect the performance of this protocol. 180 4. Modified Home Agents List 182 Each home agent maintains a separate Home Agents List for each link 183 on which it is serving as a home agent. An entry is created in 184 response to receipt of a valid Router Advertisement in which the 185 Home Agent (H) bit is set as specified in [1]. 187 We extend the Home Agents List to support load balance information 188 so it can share registration information among the home agents in 189 the home netowrk to make decisions for home agent reassignment. 191 5 New Load Balance Information Option Format 193 Load Balance among multiple home agents defines a new Load Balance 194 Information option, used in Router Advertisements sent by a home 195 agent to advertise information specific to this router's 196 functionality as a home agent. The format of the Load Balance 197 Information option is as follows: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Available Mobile Node Number | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Type 8 208 Length 210 8-bit unsigned integer. The length of the option (including the 211 type and length fields) in units of 8 octets. The value of this 212 field MUST be 1. 213 Reserved 215 This field is unused. It MUST be initialized to zero by the 216 sender and MUST be ignored by the receiver. 217 Available Mobile Node Number (4 byte): 219 Available Mobile Node number. This field should be a coarse 220 parameter for the number of mobile node home bindings this 221 home agent is able to accept. 223 Unsolicited Router Advertisement messages should be sent at time 224 uniformly distributed within [MinRtrAdvInterval, MaxRtrAdvInterval] 225 according to [8]. 227 To make the information exchange more effective, the Unisolicited 228 Router Advertisement message with the Registered Mobile Node 229 Information MAY can be sent at time uniformly distributed with in 230 [MinRtrAdvInterval, MinRtrAdvInterval + IntervalRMMNExtension]. 232 IntervalRMMNExtension = 2 * MinRtrAdvInterval 234 The home agent keeps the Home Agents List sorted in ascending order 235 since that should place the least-loaded first. 237 Home agents MAY include this option in their Router Advertisements. 238 This option MUST be silently ignored for other Neighbor Discovery 239 messages. 240 6. Home Agent Reassignments 242 6.1 Replace Home Agent Selection 244 There are many reasons a a home agent might want to reduce the number 245 of mobile nodes it is currently supporting. For example, it might be 246 overloaded, it wants to achieve better load-balancing between a peer 247 home agent, or it is going offline for service. 249 If another home agent offering services is known, its address can be 250 communicated to the mobile node. Selection of this replacement home 251 agent should follow these steps: 253 o it MUST be in the current Home Agents List known by this home 254 agent 256 o it SHOULD be offering services for same set of home prefixes as 257 the current home agent 259 o it SHOULD be the most lightly loaded home agent as determined from 260 information supplied in a recent Load Balance Information Option 262 The frequency of selecting a new home agent for the mobile node is a 263 tradeoff between the home agent handoff frequency and the load 264 balance performance. A home agent should not frequently select a 265 new home agent for registered mobile nodes because the handoff 266 induces extra control traffic and could cause a disruption of 267 service. Therefore, only a highly loaded home agent should do 268 a home agent handoff. 270 6.2 Home Agent Handoff message 272 The Home Agent Handoff (HAH) message is used by the home agent to 273 signal the mobile node it should use another Home Agent for 274 subsequent Binding Updates. The Home Agent Handoff message uses the 275 MH Type value 8 (TBD). When this value is indicated in the MH Type 276 field, the format of the Message Data field in the Mobility Header 277 is as follows: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Reserved | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 + + 286 | | 287 + Home Agent Address + 288 | | 289 + + 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Reserved 295 16-bit field reserved for future use. The value MUST be 296 initialized to zero by the sender, and MUST be ignored by the 297 receiver. 299 Home Agent Address 301 The address of the preferred Home Agent. If set to the unspecified 302 address, the mobile node should do DHAAD to find another Home Agent. 304 If no actual options are present in this message, no padding is 305 necessary and the Header Len field will be set to 2. 307 6.3 Sending Home Agent Handoff messages 309 If another home agent is known and meets the criteria specific 310 in 6.1, its address should be copied into the Home Agent Address 311 field of the message. This address MUST be a unicast routable 312 address. Otherwise it should be set to the unspecified address. 314 In order to send a Home Agent Handoff message to the mobile node, 315 the home agent MUST use the IPsec ESP tunnel already established 316 for protecting Return Routability traffic as specified in [3]. 317 This way the mobile node will avoid being subjected to a denial 318 of service attack. 320 6.4 Receiving Home Agent Handoff messages 322 After verifying the packet passes the authentication requirements, 323 it should be processed as follows: 325 o if the Home Agent Address field is set to the unspecified address, 326 the mobile node should perform DHAAD to find a replacement home 327 agent 329 o if the Home Agent address is not a unicast routable address, the 330 packet MUST be silently discarded 332 o otherwise, the address should be stored for future binding updates 334 When the mobile node determines it must renew its binding, it SHOULD 335 NOT use the current home agent's address, but instead SHOULD use one 336 it learned from the handoff message, DHAAD, or some other mechanism 337 outside the scope of this draft. 339 7. IANA Considerations 341 This document defines one new Neighbor Discovery [8] options, 342 which must be assigned Option Type values within the option numbering 343 space for Neighbor Discovery messages: 345 o The Load Balance information option 347 o New Mobile Header message, described in section 6.2 349 8. Security Considerations 351 Here we give a example to solve the SA problem based on our proposal. 353 Visited Network | Home Network 354 | +-------+ 355 | +--------| HA1 | 356 | | +-------+ 357 | | 358 | | 359 +------+ | +-------+ | +-------+ 360 | MN |<--------|-------> | sAAA |---+--------| HA2 | 361 +------+ | +-------+ | +-------+ 362 | | ... 363 | | 364 | | +-------+ 365 | +--------| HAn | 366 | +-------+ 368 This figure shows the network architecture of our proposed solution 369 with part function of AAA. sAAA(part function of AAA) will handle 370 SA between mobile node and multiple home agents. sAAA will assign 371 a home agent, home address and security credential with all home 372 agents for mobile node. All home agents will be informed of 373 correspondence security credential for all mobile nodes. When mobile 374 node handover to a new home agent, the SA between them already 375 established. 377 If a home agent is being taken off-line, care should be taken to 378 ensure that either other home agents can accept new mobile node 379 home bindings, or there is a standby home agent in place, so 380 there is no loss of service for the current mobile nodes. This 381 should be done before attempting any handovers. 383 References 385 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 386 Levels", BCP 14, RFC 2119, March 1997. 388 [2] R. Hinden and S. Deering, "IP Version 6 Addressing 389 Architecture", RFC 2373, July 1998. 391 [3] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in 392 IPv6," draft-ietf-mobileip-ipv6-24 (work in progress), 393 June 2003. 394 [4] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: 395 Home Agent Reliability", draft-jfaizan-mip6-ha-reliability-01 396 (work in progress), February 2004. 398 [5] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent 399 Reliability Protocol", draft-jfaizan-mipv6-vhar-01 (work in 400 progress), February 2004. 402 [6] R. Hinden, "Virtual Router Redundancy Protocol", 403 draft-ietf-vrrp-spec-v2-10 (work in progress), February 2004. 405 [7] R. Wakikawa, V. Devarapalli, and P. Thubert, "Inter Home Agents 406 Protocol", draft-wakikawa-mip6-nemo-haha-01 (work in progress), 407 February 2004. 409 [8] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 410 for IP Version 6 (IPv6)", RFC 2461, December 1998. 412 [9] J. Arkko, V. Devarapalli, and F. Dupont, "Using IPsec to Protect 413 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 414 draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), 415 June 2003. 417 [10] D. Maughan, M. Schertler, M. Schneider, and J. Turner, 418 "Internet Security Association and Key Management Protocol 419 (ISAKMP)", RFC 2408, November 1998. 420 [11] A. Conta and S. Deering, "Internet Control Message Protocol 421 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 422 Specification", RFC 2463, December 1998. 424 Authors' Addresses 426 Hui Deng 427 Research & Development Center 428 Hitachi (China), Investment Ltd. 429 Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu 430 Chao Yang District, Beijing 100004, China 431 E-mail: hdeng@hitachi.cn 433 Brian Haley 434 Hewlett-Packard Company 435 110 Spitbrook Road 436 Nashua, NH 03062, USA 437 Email: Brian.Haley@hp.com 439 Xiaodong Duan 440 Research & Development Center 441 China Mobile 442 Beijing 100053, China 443 Email: duanxiaodong@chinamobile.com 445 Rong Zhang 446 Network Technology Research Division 447 Guangzhou Research and Development Center 448 China Telecom 449 Guangzhou, 510630, China 450 Email: zhangr@gsta.com 452 Kai Zhang 453 Network Theory Laboratory. 454 Department of Electronic Engineering 455 Tsinghua University 456 Beijing 100084, China 457 Email: zhangkai98@mails.tsinghua.edu.cn 459 Appendix A. Changes from Previous Version of the Draft 461 This appendix briefly lists some of the major changes in this draft 462 relative to the previous version of this same draft, 463 draft-deng-mip6-ha-loadbalance-01.txt: 465 o queue size has been deleted for deciding change of the home agent. 467 o A new home agnet handover message has been defined to make 468 home agent proactively notify the mobile node about changing 469 of the serving home agent. 471 Intellectual Property Statement 473 The IETF takes no position regarding the validity or scope of any 474 Intellectual Property Rights or other rights that might be claimed to 475 pertain to the implementation or use of the technology described in 476 this document or the extent to which any license under such rights 477 might or might not be available; nor does it represent that it has 478 made any independent effort to identify any such rights. Information 479 on the procedures with respect to rights in RFC documents can be 480 found in BCP 78 and BCP 79. 482 Copies of IPR disclosures made to the IETF Secretariat and any 483 assurances of licenses to be made available, or the result of an 484 attempt made to obtain a general license or permission for the use of 485 such proprietary rights by implementers or users of this 486 specification can be obtained from the IETF on-line IPR repository at 487 http://www.ietf.org/ipr. 489 The IETF invites any interested party to bring to its attention any 490 copyrights, patents or patent applications, or other proprietary 491 rights that may cover technology that may be required to implement 492 this standard. Please address the information to the IETF at 493 ietf-ipr@ietf.org. 495 Disclaimer of Validity 497 This document and the information contained herein are provided on an 498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 499 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 500 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 501 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 502 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 505 Copyright Statement 507 Copyright (C) The Internet Society (2004). This document is subject 508 to the rights, licenses and restrictions contained in BCP 78, and 509 except as set forth therein, the authors retain all their rights.