idnits 2.17.1 draft-ietf-vrrp-ipv4-timers-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 800. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 806. ** 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3768]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 3768' is mentioned on line 673, but not defined ** Obsolete undefined reference: RFC 3768 (Obsoleted by RFC 5798) == Missing Reference: 'RFC 2119' is mentioned on line 117, but not defined == Unused Reference: 'RFC3768' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'RFC2338' is defined on line 832, but no explicit reference was found in the text == Unused Reference: 'VRRP-IPv6' is defined on line 835, 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 (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hott 2 December 12, 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 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 12, 2006. 35 Abstract 37 The router survivability capability provided by the Virtual 38 Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the 39 requirements for many LAN environments. There are, however, 40 LAN environments that have sub-second failover requirements and 41 thus a need for finer granularity of the VRRP timers. This draft 42 proposes extensions to VRRPv4 [RFC 3768] for specifying sub-second 43 Advertisement Intervals. A new message type is introduced which 44 permits the timer granularity for the Advertisement Interval to 45 be specified. In addition, a new field is introduced permitting 46 the specification of the number of missed ADVERTISEMENTs before 47 a Virtual Router Master is declared down. 49 Table of Contents 51 1. Introduction...............................................3 52 1.1. Requirements notation................................3 53 1.2. Contributors.........................................3 54 1.3. Scope................................................4 55 2. Update to the VRRPv4 Protocol..............................4 56 2.1. Updates to the VRRPv4 Packet Format..................4 57 2.2. Updates to the VRRPv4 Field Descriptions.............5 58 3. Update to the VRRPv4 Protocol State Machine................6 59 3.1. Updates to the Parementers per Virtual Router........6 60 3.2. Update to the Timers.................................8 61 3.3. Updates to the State Descriptions....................8 62 4. Updates for Sending and Receiving VRRPv4 Packets..........15 63 4.1. Receiving VRRPv4 Packets............................15 64 4.2. Transmitting VRRPv4 Packets.........................16 65 5. Operational Issues........................................17 66 5.1. Sub-second Timers...................................17 67 5.2. Interoperability / Backward Compatibility...........17 68 6. Security Considerations...................................17 69 7. Intellectual Property.....................................17 70 8. Acknowledgments...........................................18 71 9. IANA Considerations.......................................18 72 10. Normative References......................................18 73 11. Informative References....................................18 74 12. Authors' Address..........................................19 75 13. Disclaimer of Validity....................................19 76 14. Copyright Statement.......................................19 78 1. Introduction 80 VRRPv4 [RFC 3768] specifies an election protocol that dynamically 81 assigns responsibility for a virtual router to one of the VRRP 82 routers on a LAN. This election process provides dynamic fail 83 over in the forwarding responsibility should the Master become 84 unavailable. While this capability may meet the survivability 85 requirements for many LAN environments, there are environments 86 in which sub-second recovery from outages is required. 88 To achieve sub-second failovers for VRRPv4, the granularity of 89 the timers within VRRPv4 must be reduced from one second 90 intervals to sub-second intervals. This document proposes an 91 optional message type which permits the specification of the 92 timer granularity. By specifying finer granularity timers, the 93 Advertisement Interval can be specified, in increments, based 94 upon the timer granularity. 96 In addition to specifying the timer granularity and the 97 Advertisement Interval in these new time increments, this 98 document also proposes the ability to specify the number of 99 ADVERTISEMENTS that must be missed prior to declaring a MASTER 100 inactive. In the current specification for VRRPv4 [RFC 3768], 101 the number of ADVERTISEMENTS missed prior to delaring a MASTER 102 inactive is three, based upon the calculation of the 103 Master_Down_Interval. In permitting the sub-second Advertisement 104 Interval, the potential for VRRP instability is increased. 105 Instability could occur due to processing requirements within the 106 router preventing the processing of ADVERTISEMENTS or loading 107 conditions on the network preventing reception of these 108 ADVERTISEMENTS. Specifiying the number of ADVERTISEMENTS that 109 can be missed offers a mechanism to address stability issues 110 with VRRPv4, regardless of the timer granularity specified. 112 1.1. Requirements notation 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC 2119]. 118 1.2. Contributors 120 The following people contributed to the text in this document: K. 121 O'Donoghue, R. Hinden, S. Bates, and M. Gupta. In addition, the 122 authors of VRRPv4 [RFC 3768] are recognized as the basis for the 123 text and concepts within this document. 125 1.3. Scope 127 The remainder of this document provides a description of the 128 optional message type for VRRPv4 and the associated changes to 129 VRRPv4 to support this new message type and the added funtionality. 131 A separate document will be produced if it is decided that similar 132 functionality is desirable in the IPv6 environment. 134 2. Update to the VRRPv4 Protocol 136 This section outlines the changes to Section 5 (Protocol) of the 137 VRRPv4 [RFC 3768] to accommodate the optional FAST ADVERTISEMENT, 138 Type 2, message. Changes were made to the VRRPv4 packet format 139 and VRRPv4 field descriptions. There were no changes made to 140 the IP field descriptions. 142 2.1. Updates to the VRRPv4 Packet Format 144 This section outlines the VRRPv4 packet format for the optional 145 Fast Advertisement, Type 2, message and the relevant fields in 146 packet. 148 The following is the VRRPv4 packet format for the mandatory 149 ADVERTISEMENT, Type 1, message. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Auth Type | Adver Int | Checksum | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | IP Address (1) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | . | 161 | . | 162 | . | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | IP Address (n) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Authentication Data (1) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Authentication Data (2) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 The VRRPv4 packet format for the optional FAST ADVERTISEMENT, 171 Type 2, message is as follows: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |Adv Cnt|AIG| Adver Int | Checksum | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | IP Address (1) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | . | 183 | . | 184 | . | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | IP Address (n) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 2.2. Updates to the VRRPv4 Field Descriptions 191 The following updates the VRRPv4 field descriptions. The Type and 192 Advertisement Interval are updated and two new fields are added. 194 2.2.1. Type 196 The Type field specifies the type of this VRRPv4 packet. There are 197 two types defined 199 1 ADVERTISEMENT 200 2 FAST ADVERTISEMENT (optional) 202 A packet with an unknown type MUST be discarded. 204 2.2.2. Advertisement Count (Adv_Cnt) 206 This field is only present in the FAST ADVERTISEMENT, Type 2, 207 message. The Advertisement Count field specifies the number of FAST 208 ADVERTISEMENT messages that can be missed before a BACKUP will 209 declare a MASTER down. Configurable item in the range 1-15. Default 210 is 3. 212 2.2.3. Advertisement Interval Granularity (AIG) 214 This field is only present in the FAST ADVERTISEMENT, Type 2, 215 message. The Advertisement Interval Granularity field specifies the 216 timer granularity. The currently recognized values are 218 0 seconds (default) 219 1 centiseconds 220 2 milliseconds 222 A packet with an unknown Advertisement Interval Granularity MUST 223 be discarded. 225 2.2.4. Advertisement Interval (Adver Int) 227 The Advertisement Interval field is present in both the 228 ADVERTISEMENT and the FAST ADVERTISEMENT messages. The field 229 indicates the number of time intervals between the respective 230 advertisements. For the ADVERTISEMENT, Type 1, message the 231 interval is measured in seconds and is an 8 bit field. For the 232 FAST ADVERTISEMENT, Type 2, message the interval is measured in 233 the units specified in the AIG field and is a 10 bit field. The 234 default for the Advertisement Interval is 1 second. 236 3. Update to the VRRPv4 Protocol State Machine 238 This section outlines the changes to Section 6 (Protocol State 239 Machine) of the VRRPv4 [RFC 3768] to accommodate the optional 240 FAST ADVERTISEMENT, Type 2, message. 242 With the introduction of the optional FAST ADVERTISEMENT message, 243 time values MUST reflect the granularity supported in the FAST 244 ADVERTISEMENT message. Thus all time values for both the 245 ADVERTISEMENT and FAST ADVERTISEMENT message are specified 246 according to the message format but are reflected internally 247 in milliseconds. 249 The state machines have also been updated to deal with 250 interoperability issues due to addition of the new message type. 252 3.1. Updates to the Parameters per Virtual Router 254 VR_Type The message type for this VRRP router 255 Configurable item with values 1 for 256 ADVERTISEMENT and 2 for FAST 257 ADVERTISEMENT. 259 VR_Mode The mode of operation for this VRRP 260 router environment. Values are 0 for 261 a homogeneous VRRP router environment 262 and 1 for a heterogeneous VRRP router 263 environment (i.e., both message types 264 are used). The default is 0. 266 VR_AIG The Advertisement Interval Granularity 267 for this VRRP router. Configurable item 268 with values 0 for seconds (default), 269 1 for centiseconds, and 2 for 270 milliseconds. 272 VR_Adver_Interval Time interval between ADVERTISEMENTs 273 or FAST ADVERTISEMENTs (milliseconds). 274 Configurable item. Default is 1,000 275 milliseconds (1 second) for both 276 message types. 278 Advertisement_Interval Time interval between ADVERTISEMENTs 279 or FAST ADVERTISEMENTs (milliseconds). 281 Type1_Adver_Interval Time interval between ADVERTISEMENTs 282 (seconds). 284 Skew_Time Time to skew Master_Down_Interval in 285 milliseconds. Calculated as: 287 ( ( ( 256 - Priority ) * 288 Advertisement_Interval ) / 256 ). 290 VR_Adver_Count The number of ADVERTISEMENTS or FAST 291 ADVERTISEMENTS that can be missed 292 before a BACKUP will declare a MASTER 293 down. Configurable item. When 294 ADVERTISEMENTs are used this is set to 295 3. When FAST ADVERTISEMENTs are used, 296 the range is 1-15. The default is 3. 298 Advertisement_Count The number of ADVERTISEMENTS or FAST 299 ADVERTISEMENTs that can be missed before 300 a BACKUP will declare a MASTER down. 302 Master_Down_Interval Time interval for Backup to declare Master 303 down (milliseconds). Calculated as: 305 ( Advertisement_Count * 306 Advertisement_Interval ) + Skew_time 308 3.2. Updates to the Timers 310 With the introduction of the optional FAST ADVERTISEMENT message, 311 time values MUST reflect the granularity supported in the FAST 312 ADVERTISEMENT message. Thus all timers MUST reflect the granularity 313 for FAST ADVERTISEMENT messages (milliseconds). 315 Master_Down_Timer Timer that fires when ADVERTISEMENT or 316 FAST ADVERTISEMENT has not been heard 317 for Master_Down_Interval. 319 Adver_Timer Timer that fires to trigger sending of 320 ADVERTISEMENT based on 321 Advertisement_Interval. 323 Adver_2_Timer Timer that fires to trigger sending of 324 FAST ADVERTISEMENT based on 325 Advertisement_Interval. 327 3.3. Updates to the State Descriptions 329 The State Transition Diagram does not change with the addition of 330 the FAST ADVERTISMENT message type. The following updates the 331 descriptions for the three states. 333 In the state descriptions below, the state names are identified by 334 {state-name}, and the packets are identified by all upper case 335 characters. 337 A VRRP router implements an instance of the state machine for each 338 virtual router election it is participating in. 340 3.3.1. Initialize 342 The purpose of this state is to wait for a Startup event. If a 343 Startup event is received, then: 345 o Initialize local Virtual Router settings (VR_Mode, VR_Type, 346 VR_AIG, VR_Adver_Interval, and VR_Adver_Count) 348 - If the Priority = 255, then: (i.e., the router owns the IP 349 address(es) associated with the virtual router) 351 If the VR_Mode = 1, then: 353 o Send an ADVERTISEMENT 354 o Set the Adver_Timer to Advertisement_Interval 356 else: 358 o Send a FAST ADVERTISEMENT 359 o Set the Adver_2_Timer to Advertisement_Interval 361 endif 363 o Broadcast a gratuitous ARP request containing the virtual 364 router MAC address for each IP address associated with the 365 virtual router. 367 o Transition to the {Master} state 369 else: 371 o Set the Master_Down_Timer to Master_Down_Interval 372 o Transition to the {Backup} state 374 endif 376 3.3.2. Backup 378 The purpose of the {Backup} state is to monitor the 379 availability and state of the Master Router. 381 While in this state, a VRRP router MUST do the following: 383 - MUST NOT respond to ARP requests for the IP address(s) 384 associated with the virtual router. 386 - MUST discard packets with a destination link layer MAC 387 address equal to the virtual router MAC address. 389 - MUST NOT accept packets addressed to the IP address(es) 390 associated with the virtual router. 392 - If a Shutdown event is received, then: 394 o Cancel the Master_Down_Timer 395 o Transition to the {Initialize} state 397 endif 399 - If the Master_Down_Timer fires, then: 401 If the VR_Mode = 0, then: 403 If the VR_Type = 1, then: 405 o Send an ADVERTISEMENT 406 o Set the Adver_Timer to Advertisement_Interval 408 else: 410 o Send a FAST ADVERTISEMENT 411 o Set the Adver_2_Timer to Advertisement_Interval 413 endif 415 else: 417 o Send an ADVERTISEMENT 418 o Send a FAST ADVERTISEMENT 419 o Set the Adver_Timer to Maximum of (1 second, 420 Advertisement_Interval) 421 o Set the Adver_2_Timer to Advertisement_Interval 423 endif 425 o Broadcast a gratuitous ARP request containing the virtual 426 router MAC address for each IP address associated with the 427 virtual router 428 o Transition to the {Master} state 430 endif 432 - If an ADVERTISEMENT is received, then: 434 If VR_Type is 2, then: 436 o Set the VR_Mode to 1 (mixed message type VRRP 437 environment) 439 endif 441 If the Priority in the ADVERTISEMENT is Zero, then: 443 o Set the Master_Down_Timer to Skew_Time 445 else: 447 If Preempt_Mode is False, or If the Priority in the 448 ADVERTISEMENT is greater than or equal to the local 449 Priority, then: 451 o Reset the Master_Down_Timer to Master_Down_Interval 453 else: 455 o Discard the ADVERTISEMENT 457 endif 458 endif 459 endif 461 - If a FAST ADVERTISEMENT is received, then: 463 If VR_Type is 1, then: 465 o Set the VR_Mode to 1 (mixed message type VRRP 466 environment) 468 endif 470 If the Priority in the FAST ADVERTISEMENT is Zero, 471 then: 473 o Set the Master_Down_Timer to Skew_Time 475 else: 477 If Preempt_Mode is False, or If the Priority in the 478 FAST ADVERTISEMENT is greater than or equal to the 479 local Priority, then: 481 o Reset the Master_Down_Timer to Master_Down_Interval 483 else: 485 o Discard the FAST ADVERTISEMENT 487 endif 488 endif 489 endif 491 3.3.3. Master 493 While in the {Master} state the router functions as the forwarding 494 router for the IP address(es) associated with the virtual router. 496 While in this state, a VRRP router MUST do the following: 498 - MUST respond to ARP requests for the IP address(es) associated 499 with the virtual router. 501 - MUST forward packets with a destination link layer MAC address 502 equal to the virtual router MAC address. 504 - MUST NOT accept packets addressed to the IP address(es) associated 505 with the virtual router if it is not the IP address owner. 507 - MUST accept packets addressed to the IP address(es) associated 508 with the virtual router if it is the IP address owner. 510 - If a Shutdown event is received, then: 512 o Cancel the Adver_Timer 513 o Cancel the Adver_2_Timer 515 If the VR_Mode is zero, then 517 If the VR_Type is 1, then: 519 o Send an ADVERTISEMENT with Priority = 0 521 else 523 o Send a FAST ADVERTISEMENT with Priority = 0 525 endif 527 else 529 o Send an ADVERTISEMENT with Priority = 0 530 o Send a FAST ADVERTISEMENT with Priority = 0 532 endif 534 - If the Adver_Timer fires, then: 536 If the VR_Mode is 1 537 or 538 if the VR_Type is 1, then: 540 o Send an ADVERTISEMENT 541 o Reset the Adver_Timer to Maximum of (1 second, 542 VR_Adver_Interval) 544 endif 545 endif 547 - If the Adver_2_Timer fires, then: 549 If the VR_Mode is 1 550 or 551 if the VR_Type is 2, then: 553 o Send a FAST ADVERTISEMENT 554 o Reset the Adver_2_Timer to VR_Adver_Interval 556 endif 557 endif 559 - If an ADVERTISEMENT is received, then: 561 If the VR_Mode is 0 562 and 563 If the VR_Type is 2, then 565 o Set VR_Mode to 1 (heterogeneous VRRP environment) 566 o Set the Adver_Timer to Maximum of 1 second and 567 VR_Adver_Interval 569 endif 571 If the Priority in the ADVERTISEMENT is Zero, then: 573 If the VR_Mode is zero, then 575 If the VR_Type is 1, then: 577 o Send an ADVERTISEMENT 578 o Reset the Adver_Timer to Maximum of 1 second and 579 VR_Adver_Interval 581 else 583 o Send a FAST ADVERTISEMENT 584 o Reset the Adver_2_Timer to VR_Adver_Interval 586 endif 588 else 590 o Send an ADVERTISEMENT 591 o Send a FAST ADVERTISEMENT 592 o Reset the Adver_Timer to Maximum of 1 second and 593 VR_Adver_Interval 594 o Reset the Adver_2_Timer to VR_Adver_Interval 596 endif 598 else: 600 If the Priority in the ADVERTISEMENT is greater than the 601 local Priority, 602 or 603 If the Priority in the ADVERTISEMENT is equal to the 604 local Priority and the primary IP Address of the sender 605 is greater than the local primary IP Address, then: 607 o Cancel Adver_Timer 608 o Cancel Adver_2_Timer 609 o Set Master_Down_Timer to Master_Down_Interval 610 o Transition to the {Backup} state 612 else: 614 o Discard ADVERTISEMENT 616 endif 617 endif 618 endif 620 - If a FAST ADVERTISEMENT is received, then: 622 If the VR_Mode is 0 623 and 624 If the VR_Type is 1, then 626 o Set VR_Mode to 1 (heterogeneous VRRP environment) 627 o Set the Adver_2_Timer to VR_Adver_Interval 629 endif 631 If the Priority in the FAST ADVERTISEMENT is Zero, then: 633 If the VR_Mode is zero, then 635 o Send a FAST ADVERTISEMENT 636 o Reset the Adver_2_Timer to VR_Adver_Interval 638 else 640 o Send an ADVERTISEMENT 641 o Send a FAST ADVERTISEMENT 642 o Reset the Adver_Timer to Maximum of 1 second and 643 VR_Adver_Interval 644 o Reset the Adver_2_Timer to VR_Adver_Interval 646 endif 648 else: 650 If the Priority in the FAST ADVERTISEMENT is greater 651 than the local Priority, 652 or 653 If the Priority in the FAST ADVERTISEMENT is equal to 654 the local Priority and the primary IP Address of the 655 sender is greater than the local primary IP Address, then: 657 o Cancel Adver_Timer 658 o Cancel Adver_2_Timer 659 o Set Master_Down_Timer to Master_Down_Interval 660 o Transition to the {Backup} state 662 else: 664 o Discard FAST ADVERTISEMENT 666 endif 667 endif 668 endif 670 4. Updates for Sending and Receiving VRRPv4 Packets 672 This section outlines the changes to Section 7 (Sending and 673 Receiving VRRP Packets) of the VRRPv4 [RFC 3768] to accommodate 674 the optional FAST ADVERTISEMENT, Type 2, message. 676 4.1. Receiving VRRPv4 Packets 678 Perform the following functions when a VRRP packet is received: 680 - MUST verify that the IP TTL is 255. 681 - MUST verify the VRRP version is 2. 682 - MUST verify that the received packet contains the complete VRRP 683 packet (including fixed and variable fields) for either Type 1 684 or Type 2 messages. 685 - MUST verify the VRRP checksum. 686 - MUST verify that the VRID is configured on the receiving 687 interface and the local router is not the IP Address owner 688 (Priority equals 255 (decimal)). 689 - For Type 1 (ADVERTISEMENT) messages, MUST verify that the 690 Auth Type matches the locally configured authentication 691 method for the virtual router and perform that 692 authentication method. 694 If any one of the above checks fails, the receiver MUST discard 695 the packet, SHOULD log the event and MAY indicate via network 696 management that an error occurred. 698 - MAY verify that the message Type matches the locally 699 configured VRRP Advertisement Type for the virtual router 700 (either Type 1 for ADVERTISEMENT or Type 2 for FAST 701 ADVERTISEMENT). 703 If the above check fails, the receiver SHOULD log the event 704 and MAY indicate via network management that a misconfiguration 705 was detected. 707 - MAY verify that "Count IP Addrs" and the list of IP Address 708 matches the IP_Addresses configured for the VRID. 710 If the above check fails, the receiver SHOULD log the event 711 and MAY indicate via network management that a misconfiguration 712 was detected. If the packet was not generated by the address 713 owner (Priority does not equal 255 (decimal)), the receiver 714 MUST drop the packet, otherwise continue processing. 716 - For Type 2 (FAST ADVERTISEMENT) messages, MUST verify that 717 the Advertisement Count is the same as locally configured 718 for this virtual router. 719 - For Type 2 (FAST ADVERTISEMENT) messages, MUST verify that 720 the Advertisement Interval Granularity is the same as 721 locally configured for this virtual router. 722 - MUST verify that the Advertisement Interval in the packet 723 is the same as locally configured for this virtual router. 725 If any of the above checks fail, the receiver SHOULD log the 726 event and MAY indicate via network management that a 727 misconfiguration was detected. 729 4.2. Transmitting VRRPv4 Packets 731 The following operations MUST be performed when transmitting a VRRP 732 packet. 734 - Fill in the VRRP packet fields with the appropriate virtual router 735 configuration state (based on the message Type) 736 - Compute the VRRP checksum 737 - Set the source MAC address to Virtual Router MAC Address 738 - Set the source IP address to interface primary IP address 739 - Set the IP protocol to VRRP 740 - Send the VRRP packet to the VRRP IP multicast group 742 Note: VRRP packets are transmitted with the virtual router MAC 743 address as the source MAC address to ensure that learning bridges 744 correctly determine the LAN segment the virtual router is attached 745 to. 747 5. Operational Issues 749 5.1 Sub-second Timers 751 The changes proposed to VRRP for IPv4 are intended to provide 752 additional capabilities to address specific operational requirements, 753 specifically, sub-second fail over from the Master. The use of 754 sub-second timers is not recommended for general purpose networking 755 environments. Missed ADVERTISEMENTS can lead to fail overs. Reducing 756 the time period for fail over, the MASTER_DOWN_TIMER, increases the 757 potential for missed ADVERTISEMENTS, due to router processing 758 requirements, network congestion, or even denial of service attacks. 760 The new message type provides extensions to VRRPv4 allowing the 761 specification of sub-second timers. It also provides the ability to 762 specify the number of advertisement messages that can be missed by 763 a BACKUP before declaring a MASTER down. 765 5.2. Interoperability / Backward Compatibility 767 The addition of the new message type introduces the potential for 768 routers that do not support the new message type configured on 769 the same network with routers that use the new message type. 770 The state machines have been updated to interoperate with routers 771 only supporting Type 1 Advertisements. When routers configured to 772 send Type 2 Fast Advertisements discover routers sending Type 1 773 Advertisements, it sends both types of advertisements. In the 774 Type 1 Advertisements, the Advertisement Interval is set to the 775 larger of the interval value from the MASTER or one second (the 776 minimum setting for Type 1 Advertisements). Type 2 messages will 777 not support authentication. 779 6. Security Considerations 781 This draft does not address the security issues relating to VRRP 782 that have been identified in RFC 3768. 784 7. Intellectual Property 786 The IETF takes no position regarding the validity or scope of any 787 Intellectual Property Rights or other rights that might be claimed 788 to pertain to the implementation or use of the technology described 789 in this document or the extent to which any license under such 790 rights might or might not be available; nor does it represent that 791 it has made any independent effort to identify any such rights. 792 Information on the procedures with respect to rights in RFC 793 documents can be found in BCP 78 and BCP 79. 795 Copies of IPR disclosures made to the IETF Secretariat and any 796 assurances of licenses to be made available, or the result of an 797 attempt made to obtain a general license or permission for the use 798 of such proprietary rights by implementers or users of this 799 specification can be obtained from the IETF on-line IPR repository 800 at http://www.ietf.org/ipr. 802 The IETF invites any interested party to bring to its attention any 803 copyrights, patents or patent applications, or other proprietary 804 rights that may cover technology that may be required to implement 805 this standard. Please address the information to the IETF at 806 ietf-ipr@ietf.org. 808 8. Acknowledgments 810 The work presented in this document is based upon the VRRP 811 specification in RFC3768 and the current work in progress for VRRP 812 for IPv6. The authors and contributors of these works are R. 813 Hinden, P. Higginson, R. Hinden, P. Hunt, S. Knight, A. Lindem, 814 D. Mitzel, M. Shand, D. Weaver, and D. Whipple. 816 The author of this document would also like to thank Karen 817 O'Donoghue, Leon Sangroniz, and Changming Liu, Mukesh Gupta, 818 Steve Bates, and Bob Hinden for their guidance and helpful 819 suggestions. 821 9. IANA Considerations 823 This document has no actions for IANA. 825 10. Normative References 827 [RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol 828 (VRRP)", RFC 3768, April 2004. 830 11. Informative References 832 [RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol", 833 RFC2338, April 1998. 835 [VRRP-IPv6] 836 Hinden, R., "Virtual Router Redundancy Protocol for IPv6", 837 draft-ietf-vrrp-ipv6-spec-07 (work in progress), 838 September 2004. 840 12. Author's Address 842 Robert W. Hott 843 Naval Surface Warfare Center Dahlgren Division 844 Code B35 845 17320 Dahlgren Road 846 Dahlgren, VA 22448-5100 847 USA 849 Phone: +1 540 653-1497 850 EMail: robert.hott@navy.mil 852 13. Disclaimer of Validity 854 This document and the information contained herein are provided on 855 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 856 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 857 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 858 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 859 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 860 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 14. Copyright Statement 864 Copyright (C) The Internet Society (2005). This document is subject 865 to the rights, licenses and restrictions contained in BCP 78, and 866 except as set forth therein, the authors retain all their rights.