idnits 2.17.1 draft-devarapalli-mip6-nemo-local-haha-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 5, 2006) is 6620 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) == Outdated reference: A later version (-01) exists of draft-wakikawa-mip6-nemo-haha-spec-00 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-02) exists of draft-thubert-nemo-global-haha-01 == Outdated reference: A later version (-08) exists of draft-ietf-vrrp-ipv6-spec-07 -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '8') (Obsoleted by RFC 4861) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6/NEMO Working Group V. Devarapalli 3 Internet-Draft Nokia 4 Expires: September 6, 2006 R. Wakikawa 5 WIDE 6 P. Thubert 7 Cisco 8 March 5, 2006 10 Local HA to HA protocol 11 draft-devarapalli-mip6-nemo-local-haha-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 6, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes the use of an Inter Home Agents protocol 45 (HAHA) to achieve Home Agent reliability and load balancing. The 46 protocol allows Home Agents serving the same home link to share the 47 binding cache contents, and switch a mobile node from one home agent 48 to another. It also allows a mobile node to utilize multiple Home 49 Agents simultaneously. A mobile node picks one Home Agent as its 50 primary Home Agent and registers with it. The primary Home Agent 51 synchronizes the binding cache information with other Home Agents. 52 Any of Home Agents can intercept a packet meant for the mobile node 53 and tunnel the packet directly to its current Care-of address. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Home Agent List Management . . . . . . . . . . . . . . . . 4 61 3.2. Home Agent Failure Detection . . . . . . . . . . . . . . . 5 62 3.3. Binding Synchronization . . . . . . . . . . . . . . . . . 5 63 3.4. Home Agent Switching . . . . . . . . . . . . . . . . . . . 6 64 4. Interworking with VRRP for IPv6 . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 1. Introduction 75 Mobile nodes [3] and mobile routers [5] may use a bi-directional 76 tunnel with their Home Agents for all traffic with the correspondent 77 nodes. Note that in this document, the term mobile node refers to 78 both a mobile node and a mobile router. A Home Agent on the home 79 link maintains a binding cache entry for each mobile node and uses 80 the binding cache entry to route any traffic meant for the mobile 81 node or the mobile network. If the mobile node does not have a 82 binding cache entry at the Home Agent, it is neither reachable at its 83 home address nor able to setup new sessions with its home address. 84 If a Home Agent loses the binding cache state, due to failure or some 85 other reason, it results in loss of service for the mobile nodes. 87 It would be very beneficial to provide high availability and 88 redundancy for a Home Agent so that the mobile nodes can avail of 89 uninterrupted service even when one Home Agent crashes or loses 90 state. 92 Mobile IPv6 defines a rudimentary load balancing mechanism based on 93 the Dynamic Home Agent Address discovery mechanism (DHAAD). Each 94 Home Agent advertises a preference value on the home link. The home 95 agents are ordered based on the preference values in a DHAAD reply. 96 A mobile node typically picks the Home Agent that appears first on 97 the list of Home Agents in the DHAAD reply. A Home Agent can 98 dynamically alter its position on the list by changing its preference 99 value. 101 But the DHAAD mechanism is useful only when the mobile node tries to 102 discover a Home Agent when it does not have one configured. It 103 cannot be used dynamically to switch a mobile node to another Home 104 Agent. Moreover, DHAAD is only initiated by the mobile node. Also 105 the mechanism is too slow for the mobile node to recover when its 106 Home Agent fails. In this document we present a mechanism, based on 107 the HAHA protocol, for switching a mobile node to another Home Agent 108 at any time and thus achieve load balancing. The switch to another 109 Home Agent can be initiated by the mobile node or a Home Agent on the 110 home link. 112 We also discuss how the local HAHA protocol can be used with VRRPv6 113 [7] to achieve redundancy. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [1]. 121 For the HAHA protocol related terminology, please see [4] 123 3. Protocol Operation 125 The following sections describe the local HAHA protocol. 127 3.1. Home Agent List Management 129 RFC 3775 defines a mechanism for maintaining a home agent list when 130 there are multiple home agents present on a link. It is based on 131 each Home Agent sending a router advertisement periodically on the 132 home link with a Home Address Information option [3]. However, this 133 mechanism is governed by how a router sends a router advertisement as 134 defined in [8]. There are restrictions on how often a router 135 advertisement can be sent and on how they are processed by routers 136 that receive them. Moreover, the router advertisements are not sent 137 frequently enough to rely on the absence of the router advertisement 138 to detect a Home Agent failure. We show in Section 3.2, how the 139 Hello messages can be used to detect Home Agent failure. 141 In this document, we present another mechanism based on the Home 142 Agent Hello message defined in [4]. The Hello message includes the 143 home agent preference, lifetime and the prefix the Home Agent serves. 144 Each Home Agent MUST periodically send a Home Agent Hello message. 145 The Home Agent SHOULD also send a Home Agent Hello message when its 146 local information such as preference, lifetime, and registration 147 status, etc. changes. The interval between two Hello messages is 148 configurable on the Home Agents. The Hello messages should be sent a 149 new link-local scope multicast address (to be assigned by the IANA). 150 All the Home Agents on the home link should join this multicast 151 address. 153 When a Home Agent receives and processes a Hello message, it adds the 154 Home Agent to its list of known Home Agents on the home link. The 155 Home Agents list is ordered based on the home agent preference value. 156 If the home agent lifetime field in the Hello message is set to 0, 157 the Home Agent removes the Home Agent that sent the Hello message 158 from the Home Agents list. 160 This mechanism should be used only when all the Home Agents on a 161 particular link support sending and receiving these Hello messages. 162 When the Hello messages are used for maintaining the Home Agents 163 list, the Home Agent MUST NOT use the Home Agent Information option 164 in the router advertisements to manage the Home Agents list. 166 3.2. Home Agent Failure Detection 168 Failure detection is based on Hello messages [4]. Each Home Agent is 169 expected to send the Hello message periodically. This interval is 170 indicated by the Hello interval field in the Hello message. If a 171 Hello message is not received from a Home Agent within a multiple of 172 the interval value, then the Home Agent is considered to have failed. 173 A Home Agent that is designated as a backup for the failed Home Agent 174 takes over and sends a Home Agent Switch Request (Section 3.4) 175 message to all the mobile nodes that were being served by the failed 176 Home Agent to switch to it. 178 VRRP for IPv6 can also be used for detecting a Home Agent failure. 179 The operation of local HAHA with VRRP is explained in Section 4. 181 3.3. Binding Synchronization 183 Binding cache entries are synchronized between all the Home Agents on 184 the home link. The Home Agent that had actually processed the 185 Binding Update from the mobile node is considered the primary Home 186 Agent for a particular mobile node. Each Home Agent sends a Binding 187 Information Update message, gratuitously, whenever it creates or 188 updates a binding cache entry for a mobile node. The Binding 189 Information Update message is sent unicast to all the Home Agents in 190 the home agents list. A Home Agent can send information on multiple 191 binding cache entries in a Binding Information Update message by 192 including multiple Binding Cache Entry Information options. The 193 Binding Cache Entry Information option is defined in [4]. If the 194 Binding Cache entry is for a mobile router, the mobile network prefix 195 information is also sent in the option. 197 When a Home Agent receives a Binding Information Update message, it 198 stores the binding cache entry information locally and marks the 199 entries as having received from a particular Home Agent. If the 200 Binding Information Update message was unicast to the Home Agent, it 201 sends a unicast Binding Information Acknowledgement message in 202 response to the Home Agent that sent the Binding Information Update 203 message. 205 A Home Agent can also query another Home Agent for the binding cache 206 information for a particular mobile node by sending a Binding 207 Information Request Message [4]. If a Home Agents wants the Binding 208 Cache Information for a particular mobile node it includes a Home 209 Address mobility option, defined in [4], to carry the home address of 210 the mobile node. If a Home Agent wants to know the forwarding state 211 setting up for a particular Mobile Network Prefix, it includes the 212 Mobile Network Prefix Option, defined in [2]. When a Home Agent 213 receives a Binding Information Request message, it responds with a 214 Binding Information Update message for the corresponding binding 215 cache entry. 217 3.4. Home Agent Switching 219 If a Home Agent is no longer able to provide service to a particular 220 mobile node, due to excessive load or due to an administrative 221 reason, it can tell the mobile node to use another Home Agent on the 222 home link by sending a Home Agent Switch Request message. This 223 message is defined in [4]. The Home Agent MAY include the IP address 224 of another Home Agent in the Home Agent Switch Request message. The 225 request message MUST only be sent to mobile nodes that are not on the 226 home link. 228 When the mobile node receives a Home Agent Switch Request message, 229 and if the request message contains the IP address of another Home 230 Agent, it picks the Home Agent in the request message as the primary 231 Home Agent and sends a Binding Update message to it. If the Home 232 Agent Switch Request message does not contain another Home Agent 233 address, the mobile node should perform DHAAD and obtain the current 234 list of Home Agents. If the mobile node already has a list of Home 235 Agents from performing DHAAD earlier, it MAY pick a Home Agent from 236 the list and send a Binding Update message to it. 238 If a Home Agent fails, another Home Agent on the home link can act as 239 a backup for the failed Home Agent. The backup Home Agent sends a 240 Home Agent Switch Request message to all the mobile nodes that were 241 being served by the failed Home Agent. The backup Home Agent should 242 include its IP address in the request message. 244 The primary Home Agent switching is completed when the mobile node 245 sends a Binding Update and creates a binding at the new Home Agent. 246 The Home Agent that the mobile node was previously using, deletes the 247 binding cache entry, when it receives a Binding Information Update 248 message that contains the binding cache information for the mobile 249 node, from the new Home Agent 251 4. Interworking with VRRP for IPv6 253 VRRP specifies an election protocol that dynamically assigns 254 responsibility for a virtual router to one of the VRRP routers on a 255 LAN. The VRRP router controlling the IP address(es) associated with 256 a virtual router is called the Master, and forwards packets sent to 257 these IP addresses. The election process provides dynamic fail over 258 in the forwarding responsibility should the Master become 259 unavailable. 261 VRRP, however, cannot be used for binding cache synchronization. It 262 can replace the failure detection mechanism described in Section 3.2. 263 Therefore, when VRRP is available, the Home Agent Hello messages 264 should not be used. The Home Agents should still perform binding 265 cache synchronization as described in Section 3.3 and support the 266 Home Agent switch mechanism as described in Section 3.4. 268 A protocol similar to VRRP was developed for HA reliability. It is 269 described in [9]. But this protocol cannot be used if the Home 270 Agents are distributed geographically [6]. 272 5. Security Considerations 274 When the Home Agents exchange binding cache information, they MUST 275 use IPsec ESP to encrypt the messages. Other nodes on the home link 276 MUST NOT be able to observe the contents of the Binding Information 277 Update messages. The Home Agents can be connected through a 278 dedicated subnet, separate from the home link, for exchanging 279 information. In this case, Home Agents MAY skip confidentiality 280 protection for the binding synchronization messages. However, no 281 other host should be allowed to connect to this dedicated subnet. 283 The Home Agent switching mechanism described in Section 3.4 can 284 result in disrupting the service for the mobile node for a brief 285 while. Therefore, the Home Agent Switch Request message MUST be 286 protected by IPsec ESP in transport mode. If there is no existing 287 security association, the Home Agent must negotiate an IPsec SA, as 288 defined in [5], to protect the request message. 290 The Home Agent Hello messages cannot be protected since they are sent 291 to a multicast address. The Hello messages do not contain any 292 information that requires confidentiality protection. A malicious 293 user on the home link could send fake Hello messages and populate the 294 Home Agents list on the Home Agents. But this mechanism is no worse 295 than the current router advertisements based Home Agents list 296 maintenance. The authors believe that the home link will have 297 restricted access, which will prevent such malicious users from 298 connecting to the home link. 300 6. IANA Considerations 302 The Home Agent Hello messages are sent to an IPv6 link-local scope 303 multicast address. This needs to be assigned by the IANA. The 304 address should be of the following form: 306 FF02:0:0:0:0:0:XXXX:XXXX 308 7. References 310 7.1. Normative References 312 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 313 Levels", BCP 14, RFC 2119, March 1997. 315 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 316 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 317 January 2005. 319 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 320 IPv6", RFC 3775, June 2004. 322 [4] Wakikawa, R., "Inter Home Agents Protocol Specification", 323 draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress), 324 October 2004. 326 7.2. Informative References 328 [5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 329 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 330 Agents", RFC 3776, June 2004. 332 [6] Thubert, P., "Global HA to HA protocol", 333 draft-thubert-nemo-global-haha-01 (work in progress), 334 October 2005. 336 [7] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", 337 draft-ietf-vrrp-ipv6-spec-07 (work in progress), October 2004. 339 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 340 for IP Version 6 (IPv6)", RFC 2461, December 1998. 342 [9] El-Rewini, H., Khalil, M., and J. Faizan, "Virtual Home Agent 343 Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-02 (work 344 in progress), April 2004. 346 Authors' Addresses 348 Vijay Devarapalli 349 Nokia Research Center 350 313 Fairchild Drive 351 Mountain View, CA 94043 352 USA 354 Email: dvijay@gmail.com 356 Ryuji Wakikawa 357 Keio University and WIDE 358 5322 Endo Fujisawa Kanagawa 359 252-8520 360 Japan 362 Email: ryuji@sfc.wide.ad.jp 364 Pascal Thubert 365 Cisco Systems 366 Village d'Entreprises Green Side 367 400, Avenue de Roumanille 368 Batiment T3, Biot - Sophia Antipolis 06410 369 France 371 Email: pthubert@cisco.com 373 Intellectual Property Statement 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the procedures with respect to rights in RFC documents can be 382 found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at 395 ietf-ipr@ietf.org. 397 Disclaimer of Validity 399 This document and the information contained herein are provided on an 400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 402 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 403 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 404 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 407 Copyright Statement 409 Copyright (C) The Internet Society (2006). This document is subject 410 to the rights, licenses and restrictions contained in BCP 78, and 411 except as set forth therein, the authors retain all their rights. 413 Acknowledgment 415 Funding for the RFC Editor function is currently provided by the 416 Internet Society.