idnits 2.17.1 draft-ietf-vrrp-ipv4-timers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 86, but not defined == Unused Reference: 'RFC3768' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC2338' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'VRRP-IPv6' is defined on line 406, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798) -- Obsolete informational reference (is this intentional?): RFC 2338 (Obsoleted by RFC 3768) == Outdated reference: A later version (-08) exists of draft-ietf-vrrp-ipv6-spec-07 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hott 2 February 11, 2005 NSWC-DD 4 Timer Enhancements to Reduce Failover Times for the 5 Virtual Router Redundancy Protocol for IPv4 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This internet draft expires on August 11, 2005. 37 Abstract 39 This memo identifies a new requirement for the Virtual Router 40 Redundancy Protocol (VRRP) for IPv4 and proposes candidate 41 implementation approaches to address this requirement. VRRP 42 specifies an election protocol that dynamically assigns 43 responsibility for a virtual router to one of the VRRP routers 44 on a LAN. The VRRP router controlling the IP address(es) 45 associated with a virtual router is called the Master, and 46 forwards packets sent to these IP addresses. The election process 47 provides dynamic fail over in the forwarding responsibility should 48 the Master become unavailable. The new requirement is for VRRP 49 for IPv4 to support sub-second fail over from the Master. 51 Table of Contents 53 1. Introduction...............................................4 54 2. Required Capability........................................5 55 3. VRRP Fail Over Overview....................................5 56 4. Candidate Implementation Approaches........................7 57 4.1 Advertisement Interval.................................7 58 4.2 Timer Adjustments......................................9 59 5. Operational Issues........................................10 60 6. Security Considerations...................................10 61 7. Intellectual Property.....................................10 62 8. Acknowledgments...........................................11 63 9. IANA Considerations.......................................11 64 10. Normative References......................................11 65 11. Informative References....................................11 66 12. Authors' Address..........................................11 67 13. Disclaimer of Validity....................................12 68 14. Copyright Statement.......................................12 70 1. Introduction 72 VRRP specifies an election protocol that dynamically assigns 73 responsibility for a virtual router to one of the VRRP routers 74 on a LAN. The VRRP router controlling the IP address(es) 75 associated with a virtual router is called the Master, and 76 forwards packets sent to these IP addresses. The election process 77 provides dynamic fail over in the forwarding responsibility should 78 the Master become unavailable. 80 The new requirement is for VRRP for IPv4 to support sub-second fail 81 over from the Master. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC 2119]. 87 1.1 Scope 89 The remainder of this document provides a description of the 90 sub-second fail over requirement, a discussion of the factors that 91 impact the fail over time period, and candidate implementation 92 approaches for VRRP for IPv4. 94 1.2 Definitions 96 VRRP Router A router running the Virtual Router Redundancy 97 Protocol. It may participate in one or more 98 virtual routers. 100 Virtual Router An abstract object managed by VRRP that acts 101 as a default router for hosts on a shared LAN. 102 It consists of a Virtual Router Identifier and 103 an a set of associated IP address(es) across a 104 common LAN. A VRRP Router may backup one or 105 more virtual routers. 107 IP Address Owner The VRRP router that has the virtual router's 108 IP address(es) as real interface address(es). 109 This is the router that, when up, will respond 110 to packets addressed to one of these IP 111 addresses for ICMP pings, TCP connections, 112 etc. 114 Primary IP Address An IP address selected from the set of real 115 interface addresses. One possible selection 116 algorithm is to always select the first 117 address. VRRP advertisements are always sent 118 using the primary IP address as the source of 119 the IP packet. 121 Virtual Router Master The VRRP router that is assuming the 122 responsibility of forwarding packets sent to 123 the IP address(es) associated with the virtual 124 router, and answering ARP requests for these 125 IP addresses. Note that if the IP address 126 owner is available, then it will always 127 become the Master. 129 Virtual Router Backup The set of VRRP routers available to assume 130 forwarding responsibility for a virtual router 131 should the current Master fail. 133 2. Required Capability 135 This section outlines the new feature that is required for VRRP for 136 IPv4 implementations. That feature is the support for sub-second 137 fail over from the Master. 139 Within the U.S. Navy, and other commercial sectors, there exists 140 special purpose computing environments with survivability 141 requirements which cannot tolerate prolonged service outages. These 142 environments are controlled local area networks interconnecting 143 mission critical computing resources. VRRP for IPv4 is a standards 144 based protocol that could help to address the survivability aspect 145 of the default router. At present, proprietary alternatives to VRRP 146 are used in these environments that require sub-second fail over. 148 The current work in progress for VRRP for IPv6 is addressing the 149 need for sub-second fail over. This capability is also needed for 150 IPv4. 152 3. VRRP Fail Over Overview 154 Within the current standard for VRRP for IPv4, RFC 3768, there are 155 two user configurable variables that can affect fail over time from 156 the Virtual Router Master. 158 The first variable is the Advertisement Interval. Its value has a 159 direct impact on fail over time. The Advertisement Interval is the 160 time interval between ADVERTISEMENTS. This variable is an eight 161 bit field in the VRRP for IPv4 packet and its value is specified 162 in seconds. The default value for this variable is one second. 164 The second variable is the Priority. It specifies the sending VRRP 165 router's priority for the virtual router. This variable is an 166 eight bit unsigned integer field in the VRRP for IPv4 packet. The 167 higher the value the higher the priority. Its impact on the fail 168 over time is in the calculation of a Skew_Time, discussed below. 170 Within the VRRP for IPv4 protocol state machine, for each Virtual 171 Router, in addition to Advertisement Interval and Priority, the 172 following parameters impact the fail over time: 174 Skew_Time Time to skew Master_Down_Interval in 175 seconds. Calculated as: 177 ( (256 - Priority) / 256 ) 179 Master_Down_Interval Time interval for Backup to declare Master 180 down (seconds). Calculated as: 182 (3 * Advertisement_Interval) + Skew_time 184 There are two timers used by the state machines and they are based 185 upon the variables and parameters above. The timers are: 187 Master_Down_Timer Timer that fires when ADVERTISEMENT has not 188 been heard for Master_Down_Interval. 190 Adver_Timer Timer that fires to trigger sending of 191 ADVERTISEMENT based on 192 Advertisement_Interval. 194 Based upon the configurable variables for VRRP for IPv4, the minimum 195 fail over time for VRRP, as specified in RFC 3768, is approximately 196 three seconds. This assumes that the Advertisement Interval is set 197 to one second and the Priority set to 254. The use of ADVERTISEMENTs 198 from the Virtual Router Master and the algorithm for calculating the 199 Master_Down_Timer results in a Virtual Router Backup taking over as 200 the Virtual Router Master when three ADVERTISEMENTs are missed. 202 4. Candidate Implementation Approaches 204 To achieve sub-second fail over from the Virtual Router Master two 205 areas of the VRRP for IPv4 must be addressed. They are (1) the 206 specification and granularity of the Advertisement Interval and 207 (2) the calculation of the timers used in the Virtual Router 208 Backups. 210 4.1 Advertisement Interval 212 As stated above, the Advertisement Interval directly impacts the 213 fail over time for VRRP. To achieve sub-second fail over, the 214 Advertisement Interval must be set to less than one second. This 215 section discusses two options for specifying a sub-second 216 Advertisement Interval within the VRRP for IPv4 packet. The first 217 option is to introduce an optional flag that specifies the 218 resolution for the Advertisement Interval. A second option is to 219 align the specification of the Advertisement Interval with the 220 current work in progress for the VRRP for IPv6. 222 For either approach, it is proposed that the resolution used for 223 the Advertisement Interval, to provide the sub-second fail over 224 capability, match the resolution for VRRP for IPv6. The 225 Advertisement Interval is specified in centiseconds. 227 The following two sub-sections provide a discussion of options for 228 specifying a sub-second Advertisement Interval within VRRP for IPv4. 230 4.1.1 Support for an Advertisement Interval Flag 232 The current standard for VRRP for IPv4, RFC 3768, eliminated the 233 use of the Authenication Type. The standard did not re-allocate 234 the space in the packet inorder to maintain backwards compatibility. 235 Only two bits, from the possible 8 bits, were allocated in the 236 previous version of the standard, RFC 2338, for Authentication Type. 237 This alternative proposes to split the original Authentication Type 238 field into four 1-bit "flags" fields and a shortened 4-bit 239 Authentication Type field. The first flag field, the "C" Flag, would 240 be used to indicate the clock resolution for the Advertisement 241 Interval. When set to zero, the clock resolution would be set to 242 seconds, to maintain backwards compatibility. When set to one (1), 243 the clock resolution would be set to centiseconds. The next three 244 1-bit flag fields MUST be set to zero and would be reserved for 245 future use. 247 This proposal does change the interpretation of several fields within 248 the VRRP for IPv4 packet, but it still maintains backward 249 compatibility. To support the centisecond capability, a new variable 250 would have to be introduced to indicate the setting for the clock 251 resolution. This might be used for clock purposes and possibly to 252 differentiate the Skew_Time calculation differences that exist 253 between RFC 3768 and the current working draft for VRRP for IPv6. 255 The revised packet format could look like the following: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |C|R|R|R|Au Type| Adver Int | Checksum | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | IP Address (1) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | . | 267 | . | 268 | . | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | IP Address (n) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 4.1.2 Re-defining Advertisement Interval 275 The current work in progress to provide VRRP support for IPv6 has 276 recognized the requirement for sub-second fail over. The result is 277 a draft that has changed the resolution of the Advertisement 278 Interval from seconds to centiseconds and a change to the VRRP 279 packet which expands the size of the Advertisement Interval from 280 8 bits to 12 bits. Since RFC 3768 removed the authentication methods 281 from VRRP, this option proposes the reclaiming of that portion of 282 the VRRP packet and the alignment of the Advertisement Interval 283 with the VRRP for IPv6 efforts. This change would alter the packet 284 format and would thus require a revision change for VRRP for IPv4. 285 With this change, the Advertisement Interval would be specified in 286 centiseconds, with a default value of 100 centiseconds (1 second) 287 and the revised packet format would be as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |(Rsvd) | Adver Int | Checksum | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | IP Address (1) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | . | 299 | . | 300 | . | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | IP Address (n) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 The two fields created or changed are the Rsvd and Advertisement 306 Interval (Adver Int). The Rsvd field MUST be set to zero on 307 transmission and ignored on reception. The Advertisement Interval is 308 a 12-bit field that indicates the time interval (in centiseconds) 309 between ADVERTISEMENTS. The default is 100 centiseconds (1 second). 311 4.2 Timer Adjustments 313 The primary adjustment that must be made is the change from seconds 314 to centiseconds. If the alternative that maintains backward 315 compatibility is selected, a variable may be required to deal with 316 the differences in clock resolution. 318 It is suggested that the implementation of sub-second timers be 319 consistent with the ongoing work for VRRP for IPv6. Of the variables 320 and timers discussed in Section 3 (VRRP Fail Over Overview), above, 321 all of the variables are defined the same, with the exception of 322 the Skew_Time. RFC 3768 states that Skew_Time is calculated as: 324 ( (256 - Priority) / 256 ). 326 The current work for standardizing VRRP for IPv6 states that 327 Skew_Time is calculated as: 329 ( ( (256 - priority) * Advertisement_Interval ) / 256 ). 331 If the approach is to use FLAGs to indicate the clock resolution, 332 then the variable discribed above could be used to determine which 333 calculation should be used. If the decision is to change the 334 clock resolution, and revise VRRP for IPv4, then it is recommended 335 that the Skew_Time be calculated the same way for both IPv4 and 336 IPv6 implementations. 338 5. Operational Issues 340 The changes proposed to VRRP for IPv4 are intended to provide 341 additional capabilities to address specific operational requirements, 342 specifically, sub-second fail over from the Master. The use of 343 sub-second timers is not recommended for general purpose networking 344 environments. Missed ADVERTISEMENTS can lead to fail overs. Reducing 345 the time period for fail over, the MASTER_DOWN_TIMER, increases to 346 potential for missed ADVERTISEMENTS, due to network congestion and 347 denial of service attacks. One area for possible future activity 348 for VRRP is in mechanisms that prevent VRRP flapping. This can 349 occur regardless of the Advertisement Interval setting. 351 6. Security Considerations 353 This draft does not address the security issues relating to VRRP 354 that have been identified in RFC 3768. 356 7. Intellectual Property 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed 360 to pertain to the implementation or use of the technology described 361 in this document or the extent to which any license under such 362 rights might or might not be available; nor does it represent that 363 it has made any independent effort to identify any such rights. 364 Information on the procedures with respect to rights in RFC 365 documents can be found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use 370 of such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository 372 at http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org. 380 8. Acknowledgments 382 The work presented in this document is based upon the VRRP 383 specification in RFC3768 and the current work in progress for VRRP 384 for IPv6. The authors and contributors of these works are R. 385 Hinden, P. Higginson, R. Hinden, P. Hunt, S. Knight, A. Lindem, 386 D. Mitzel, M. Shand, D. Weaver, and D. Whipple. 388 The author of this document would also like to thank Karen 389 O'Donoghue, Leon Sangroniz, and Changming Liu for their helpful 390 suggestions. 392 9. IANA Considerations 394 This document has no actions for IANA. 396 10. Normative References 398 [RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol 399 (VRRP)", RFC 3768, April 2004. 401 11. Informative References 403 [RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol", 404 RFC2338, April 1998. 406 [VRRP-IPv6] 407 Hinden, R., "Virtual Router Redundancy Protocol for IPv6", 408 draft-ietf-vrrp-ipv6-spec-07 (work in progress), 409 September 2004. 411 12. Author's Address 413 Robert W. Hott 414 Naval Surface Warfare Center Dahlgren Division 415 Code B35 416 17320 Dahlgren Road 417 Dahlgren, VA 22448-5100 418 USA 420 Phone: +1 540 653-1497 421 EMail: robert.hott@navy.mil 423 13. Disclaimer of Validity 425 This document and the information contained herein are provided on an 426 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 427 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 428 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 429 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 430 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 431 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 433 14. Copyright Statement 435 Copyright (C) The Internet Society (2004). This document is subject 436 to the rights, licenses and restrictions contained in BCP 78, and 437 except as set forth therein, the authors retain all their rights.