idnits 2.17.1 draft-ietf-vrrp-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - MUST not accept packets addressed to the Virtual IP address - If a Shutdown event is received, then: -- 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 141, but not defined == Unused Reference: 'RFC2119' is defined on line 963, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1826 (ref. 'AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1541 (ref. 'DHCP') (Obsoleted by RFC 2131) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'HSRP' ** Obsolete normative reference: RFC 1583 (ref. 'OSPF') (Obsoleted by RFC 2178) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. 'RIP') Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Knight 2 July 28, 1997 D. Weaver 3 Ascend Communications, Inc. 4 D. Whipple 5 Microsoft, Inc. 6 R. Hinden 7 D. Mitzel 8 Ipsilon Networks, Inc. 10 Virtual Router Redundancy Protocol 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 This internet draft expires on January 29, 1998. 34 Abstract 36 This memo defines the Virtual Router Redundancy Protocol (VRRP). 37 VRRP specifies an election protocol that dynamically assigns 38 responsibility for a virtual IP address to a single router among a 39 collection of VRRP routers. The VRRP router controlling the virtual 40 IP address is called the Master router, and forwards packets sent to 41 the virtual IP address. The election process provides dynamic fail 42 over in the forwarding responsibility should the Master become 43 unavailable. The virtual IP address can then be used as the default 44 first hop router by end-hosts. The advantage gained from using the 45 VRRP virtual IP address is a higher availability default path without 46 requiring configuration of dynamic routing or router discovery 47 protocols on every end-host. 49 This memo describes the features and theory of operation of VRRP. 50 The protocol processing and state machine that guarantee convergence 51 to a single Master router is presented. Also issues related to MAC 52 address mapping, handling ARP requests, generating ICMP redirects, 53 and security issues are addressed. 55 Table of Contents 57 1. Introduction...............................................3 58 2. Scope......................................................4 59 3. Definitions................................................6 60 4. Sample Configurations......................................8 61 4.1 Sample Configuration 1................................8 62 4.2 Sample Configuration 2................................9 63 5. Protocol..................................................10 64 5.1 VRRP Packet Format...................................10 65 5.2 IP Field Descriptions................................10 66 5.3 VRRP Field Descriptions..............................11 67 6. Protocol State Machine....................................14 68 6.1 Parameters.............................................14 69 6.2 Timers.................................................14 70 6.3 State Transition Diagram..............................15 71 6.4 State Descriptions....................................15 72 7. Sending and Receiving VRRP Packets........................18 73 7.1 Receiving VRRP Packets................................18 74 7.2 Transmitting Packets...................................18 75 7.3 Virtual MAC Address....................................19 76 8. Host Operation............................................19 77 8.1 Host ARP Requests....................................19 78 9. Operational Issues........................................19 79 9.1 ICMP Redirects.........................................19 80 9.2 Proxy ARP..............................................19 81 9.3 Network Management.....................................19 82 10. Operation over FDDI and Token Ring.......................20 83 11. Security Considerations...................................21 84 11.1 No Authentication.....................................21 85 11.2 Simple Text Password..................................21 86 11.3 IP Authentication Header..............................21 87 12. References................................................23 88 13. Authors' Addresses........................................23 89 14. Acknowledgments...........................................24 90 15. Changes from Previous Drafts..............................25 92 1. Introduction 94 There are a number of methods that an end-host can use to determine 95 its first hop router towards a particular IP destination. These 96 include running (or snooping) a dynamic routing protocol such as 97 Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running 98 an ICMP router discovery client [DISC] or using a statically 99 configured default route. 101 Running a dynamic routing protocol on every end-host may be 102 infeasible for a number of reasons, including administrative 103 overhead, processing overhead, security issues, or lack of a protocol 104 implementation for some platforms. Neighbor or router discovery 105 protocols may require active participation by all hosts on a network, 106 leading to large timer values to reduce protocol overhead in the face 107 of large numbers of hosts. This can result in a significant delay in 108 the detection of a lost (i.e., dead) neighbor, which may introduce 109 unacceptably long "black hole" periods. 111 The use of a statically configured default route is quite popular; it 112 minimizes configuration and processing overhead on the end-host and 113 is supported by virtually every IP implementation. This mode of 114 operation is likely to persist as dynamic host configuration 115 protocols [DHCP] are deployed, which typically provide configuration 116 for an end-host IP address and default gateway. However, this 117 creates a single point of failure. Loss of the default router 118 results in a catastrophic event, isolating all end-hosts that are 119 unable to detect any alternate path that may be available. 121 The Virtual Router Redundancy Protocol (VRRP) is designed to 122 eliminate the single point of failure inherent in the static default 123 routed environment. VRRP specifies an election protocol that 124 dynamically assigns responsibility for a virtual IP address to a 125 single router among a collection of VRRP routers. The VRRP router 126 controlling the virtual IP address is called the Master router, and 127 forwards packets sent to the virtual IP address. The election 128 process provides dynamic fail-over in the forwarding responsibility 129 should the Master become unavailable. The virtual IP address can 130 then be used as the default first hop router by end-hosts. The 131 advantage gained from using the VRRP virtual IP address is a higher 132 availability default path without requiring configuration of dynamic 133 routing or router discovery protocols on every end-host. 135 VRRP provides a function similar to a Cisco Systems, Inc. proprietary 136 protocol named Hot Standby Router Protocol (HSRP) [HSRP]. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC 2119]. 142 1.1 Scope 144 The remainder of this document describes the features, design goals, 145 and theory of operation of VRRP. The message formats, protocol 146 processing rules and state machine that guarantee convergence to a 147 single Master router are presented. Finally, operational issues 148 related to MAC address mapping, handling of ARP requests, generation 149 of ICMP redirect messages, and security issues are addressed. 151 This protocol is intended for use with IPv4 routers only. A separate 152 specification will be produced if it is decided that similar 153 functionality is desirable in an IPv6 environment. 155 1.2 Definitions 157 Cluster The set of routers participating in VRRP to emulate a 158 virtual router. 160 Master Router The VRRP router controlling the virtual IP address 161 and assuming the responsibility of forwarding packets 162 sent to the virtual router. 164 Backup Router The set of routers in the quiescent state with regard 165 to the virtual router operation. This set includes 166 all active VRRP routers within a cluster that are not 167 the Master router. 169 2.0 Required Features 171 This section outlines the set of features that were considered 172 mandatory and that guided the design of VRRP. 174 2.1 Virtual IP Management 176 Management of the virtual IP address is the primary function of the 177 virtual router protocol. While providing election of a Master router 178 and the additional functionality described below, the protocol should 179 strive to: 181 - Minimize the duration of black holes. 182 - Minimize the steady state bandwidth overhead and processing 183 complexity. 184 - Function over a wide variety of multiaccess LAN technologies 185 capable of supporting IP traffic. 186 - Provide for election of multiple virtual routers on a network for 187 load balancing or in support of multiple logical IP subnets on a 188 single LAN segment. 190 2.2 Preferred Path Indication 192 A simple model of Master election among a set of redundant routers is 193 to treat each router with equal preference and claim victory after 194 converging to any router as Master. However, there are likely to be 195 many environments where there is a distinct preference (or range of 196 preferences) among the set of redundant routers. For example, this 197 preference may be based upon access link cost or speed, router 198 performance or reliability, or other policy considerations. The 199 protocol should allow the expression of this relative path preference 200 in an intuitive manner, and guarantee Master convergence to the most 201 preferential router currently available. 203 2.3 Minimization of Unnecessary Service Disruptions 205 Once Master election has been performed then any unnecessary 206 transitions between Master and Backup routers can result in a 207 disruption in service. The protocol should ensure after Master 208 election that no state transition is triggered by any Backup router 209 of equal or lower preference as long as the Master continues to 210 function properly. 212 Some environments may find it beneficial to avoid the state 213 transition triggered when a router becomes available that is more 214 preferential than the current Master. It may be useful to support an 215 override of the immediate convergence to the preferred path. 217 2.4 Extensible Security 219 The virtual router functionality is applicable to a wide range of 220 internetworking environments that may employ different security 221 policies. The protocol should require minimal configuration and 222 overhead in the insecure operation, provide for strong authentication 223 when increased security is required, and allow integration of new 224 security mechanisms without breaking backwards compatible operation. 226 2.5 Efficient Operation over Extended LANs 228 Sending IP packets on a multiaccess LAN requires mapping from the 229 virtual IP address to a MAC address. The use of the virtual router 230 MAC address in an extended LAN employing learning bridges can have a 231 significant effect on the bandwidth overhead of packets sent to the 232 virtual router. If the virtual router MAC address is never used as 233 the source address in a link level frame then the station location is 234 never learned, resulting in flooding of all packets sent to the 235 virtual router. To improve the efficiency in this environment the 236 protocol should: 1) use the virtual router MAC as the source in a 237 packet sent by the Master to trigger station learning; 2) trigger a 238 message immediately after transitioning to Master to update the 239 station learning; and 3) trigger periodic messages from the Master to 240 maintain the station learning cache. 242 3.0 VRRP Overview 244 VRRP assumes that each router has a consistent set of routes. The 245 mechanism used to learn or configure this routing state and ensure 246 its consistency is beyond the scope of this specification. 248 VRRP specifies an election protocol to provide the virtual router 249 function described earlier. All protocol messaging is performed 250 using IP multicast datagrams, thus the protocol can operate over a 251 variety of multiaccess LAN technologies supporting IP multicast. 252 Each VRRP virtual router has a single well-known MAC address 253 allocated to it. This document currently only details the mapping to 254 networks using the IEEE 802 48-bit MAC address. The virtual router 255 MAC address is used as the source in all periodic messages sent by 256 the Master router to enable bridge learning in an extended LAN. 258 A virtual router is identified by its virtual IP address, and 259 associated with a VRRP cluster. The virtual IP address must not 260 match the real IP address of any host or the virtual IP address of 261 any other VRRP cluster on the LAN. Each VRRP router assigned to the 262 cluster must be configured with the same virtual IP address and must 263 have a real IP address with a prefix matching the virtual router 264 address. In addition, each VRRP router is assigned a priority to 265 indicate the preference for Master election. Multiple virtual 266 routers can be elected on a network by associating them with 267 different VRRP clusters, and a single router can participate in 268 multiple VRRP clusters by maintaining independent state machines for 269 each cluster. 271 To minimize network traffic, only the Master router sends periodic 272 Advertisement messages. A Backup router will not attempt to pre-empt 273 the Master unless it has higher priority. This eliminates service 274 disruption unless a more preferred path becomes available; it's also 275 possible to administratively prohibit all pre-emption attempts. If 276 the Master becomes unavailable then the highest priority Backup will 277 transition to Master after a short delay, providing a controlled 278 transition of the virtual router responsibility with minimal service 279 interruption. 281 VRRP defines three types of authentication providing simple 282 deployment in insecure environments, added protection against 283 misconfiguration, and strong sender authentication in security 284 conscious environments. Analysis of the protection provided and 285 vulnerability of each mechanism is deferred to Section 11.0 Security 286 Considerations. In addition new authentication types and data can be 287 defined in the future without affecting the format of the fixed 288 portion of the protocol packet, thus preserving backward compatible 289 operation. 291 The VRRP protocol design provides rapid transition from Backup to 292 Master to minimize service interruption, and incorporates 293 optimizations that reduce protocol complexity while guaranteeing 294 controlled Master transition for typical operational scenarios. The 295 optimizations result in an election protocol with minimal runtime 296 state requirements, minimal active protocol states, and a single 297 message type and sender. The typical operational scenarios are 298 defined to be two redundant routers in a VRRP cluster (i.e., a Master 299 and one Backup), and/or distinct path preferences among each router. 300 A side effect when these assumptions are violated (i.e., more than 301 two redundant paths all with equal preference) is that duplicate 302 packets may be forwarded for a brief period during Master election. 303 However, the typical scenario assumptions are likely to cover the 304 vast majority of deployments, loss of the Master router is 305 infrequent, and the expected duration in Master election convergence 306 is quite small ( << 1 second ). Thus the VRRP optimizations 307 represent significant simplifications in the protocol design while 308 incurring an insignificant probability of brief network degradation. 310 4. Sample Configurations 312 4.1 Sample Configuration 1 314 The following figure shows a simple VRRP network. 316 +--------------------------+ 317 | Cluster X | 318 | | 319 | +-------+ +-------+ | 320 | | MRX | | BRX | | 321 | | | | | | 322 | |(P=200)| |(P=100)| | 323 | | | | | | 324 | +-------+ +-------+ | 325 Real IP 1 ---------->* *<---------- Real IP 2 326 | | * | | 327 +-------------^------------+ 328 | | | 329 -------------------+------|-----+-----+-------------+------ 330 | ^ ^ 331 Virtual IP --(VIPX)-+ (VIPX) (VIPX) 332 | | 333 +--+--+ +--+--+ 334 | H1 | | H2 | 335 +-----+ +-----+ 337 Legend: 338 ---+---+---+-- = 802 network, Ethernet or FDDI 339 H = Host computer 340 MR = Master Router (Priority=200) 341 BR = Backup Router (Priority=100) 342 * = IP Address 343 VIP = default router for hosts (Virtual IP) 345 The above configuration shows a typical VRRP scenario. In this 346 configuration, the end-hosts install a default route to the virtual 347 IP address (VIPX), and the routers run VRRP to elect the Master 348 router. The router on the left (MRX) becomes the Master router 349 because it has the highest priority and the router on the right (BRX) 350 becomes the backup router. 352 4.2 Sample Configuration 2 354 The following figure shows a configuration with two clusters. 356 +--------------------------+ 357 | Cluster X and Cluster Y | 358 | | 359 | +-----+ +-----+ | 360 | | MRX | | BRX | | 361 | | & | | & | | 362 | | BRY | | MRY | | 363 | +-----+ +-----+ | 364 Real IP 1 ---------->* *<---------- Real IP 2 365 | | * * | | 366 +---------^------^---------+ 367 | | | | 368 ------------------+--|------|--+-----+--------+--------+--------+-- 369 | | ^ ^ ^ ^ 370 Virtual IP --(VIPX)-+ | (VIPX) (VIPX) (VIPY) (VIPY) 371 | | | | | 372 Virtual IP --(VIPY)--------+ +--+--+ +--+--+ +--+--+ +--+--+ 373 | H1 | | H2 | | H3 | | H4 | 374 +-----+ +-----+ +--+--+ +--+--+ 376 Legend: 377 ---+---+---+-- = 802 network, Ethernet or FDDI 378 H = Host computer 379 MR = Master Router 380 BR = Backup Router 381 * = IP Address 382 VIP = default router for hosts (Virtual IP) 384 In the above configuration, half of the hosts install a default route 385 to cluster X's virtual IP address (VIPX), and the other half of the 386 hosts install a default route to cluster Y's virtual IP address 387 (VIPY). This has the effect of load balancing the outgoing traffic, 388 while also providing full redundancy. 390 5.0 Protocol 392 The purpose of the VRRP packet is to communicate to all VRRP routers 393 the priority and the state of the Master router associated with the 394 Virtual IP address. 396 VRRP packets are sent encapsulated in IP packets. They are sent to 397 an IPv4 multicast address assigned to VRRP. 399 5.1 VRRP Packet Format 401 This section defines the format of the VRRP packet and the relevant 402 fields in the IP header. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 0 | Version | VRRP Cluster | Priority | Type | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 1 | Auth Type | Adver Int | Checksum | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 2 | Virtual IP address | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 3 | Authentication Data | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 4 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 5.2 IP Field Descriptions 420 5.2.1 Source Address 422 The real IP address of the interface the packet is being sent from. 424 5.2.2 Destination Address 426 The VRRP IP multicast address assigned by the IANA. It is defined to 427 be: 429 224.0.0.(TBD IANA assignment) 431 This is a link local scope multicast address. Routers MUST NOT 432 forward a datagram with this destination address regardless of its 433 TTL. 435 5.2.3 TTL 437 The TTL MUST be set to 255. A VRRP router receiving a packet with 438 the TTL not equal to 255 MUST discard the packet. 440 5.2.4 Protocol 442 The VRRP IP protocol number assigned by the IANA. It is defined to 443 be (TBD). 445 5.3 VRRP Field Descriptions 447 5.3.1 Version 449 The version field specifies the VRRP protocol version of this packet. 450 This document defines version 1. 452 5.3.2 VRRP Cluster 454 The VRRP Cluster field specifies the cluster this packet applies to. 455 Note: The interface may participate in more than one VRRP cluster 456 simultaneously, perhaps serving as Master in one cluster, while 457 simultaneously serving as backup in other clusters. 459 5.3.3 Priority 461 The priority field specifies the router's priority for the Virtual IP 462 address and cluster. Higher values equal higher priority. This 463 field is an 8 bit unsigned field, giving 1 as the minimum priority, 464 and 255 as the maximum priority. The default priority is 100 465 (decimal). 467 The priority value zero (0) has special meaning indicating that the 468 current Master has stopped running VRRP. This is used to trigger 469 Backup routers to quickly transition to Master without having to wait 470 for the current Master to timeout. 472 In the event that two or more routers within a cluster have equal 473 priority, and that priority is the highest priority for the cluster, 474 initially the router with the higher real interface IP address 475 (interpreted as a 32 bit unsigned integer) will become Master. Any 476 router joining the cluster with the same priority will not become 477 Master even if it has a higher IP address unless the current Master 478 goes down. 480 5.3.4 Type 482 The type field specifies the type of this VRRP packet. The only 483 packet type defined in this version of the protocol is: 485 1 ADVERTISEMENT 487 A packet with unknown type MUST be discarded. 489 5.3.5 Authentication Type 491 The authentication type field identifies the authentication method 492 being utilized. The authentication type field is an 8 bit number. A 493 packet with unknown authentication type or that does not match the 494 locally configured authentication method MUST be discarded. 496 The authentication methods currently defined are: 498 0 - No Authentication 499 1 - Simple Text Password 500 2 - IP Authentication Header 502 5.3.5.1 No Authentication 504 The use of this authentication type means that VRRP protocol 505 exchanges are not authenticated. The contents of the Authentication 506 Data field should be set to zero on transmission and ignored on 507 reception. 509 5.3.5.2 Simple Text Password 511 The use of this authentication type means that VRRP protocol 512 exchanges are authenticated by a clear text password. The contents 513 of the Authentication Data field should be set to the locally 514 configured password on transmission. There is no default password. 515 The receiver MUST check that the Authentication Data in the packet 516 matches its configured authentication string. Packets that do not 517 match MUST be discarded. 519 5.3.5.3 IP Authentication Header 521 The use of this authentication type means the VRRP protocol exchanges 522 are authenticated using the mechanisms defined by the IP 523 Authentication Header [AUTH] using HMAC: Keyed-Hashing for Message 524 Authentication [HMAC]. Keys may be either configured manually or via 525 a key distribution protocol. 527 If a packet is received that does not pass the authentication check 528 due to a missing authentication header or incorrect message digest, 529 then the packet MUST be discarded. The contents of the 530 Authentication Data field should be set to zero on transmission and 531 ignored on reception. 533 5.3.6 Advertisement Interval (Adver Int) 535 The Advertisement interval indicates the time interval (in seconds) 536 between ADVERTISEMENTS. The default is 1 second. This field is used 537 for troubleshooting misconfigured routers. 539 5.3.7 Checksum 541 The checksum field is used to detect data corruption in the VRRP 542 message. 544 The checksum is the 16-bit one's complement of the one's complement 545 sum of the entire VRRP message starting with the version field. For 546 computing the checksum, the checksum field is set to zero. 548 5.3.8 Virtual IP address 550 The virtual IP address field specifies the Virtual IP (VIP) address 551 associated with the particular cluster. This field is used for 552 troubleshooting misconfigured routers. 554 The VIP MUST be an IP address assigned from the subnet that the 555 interface is attached and does not match any hosts real IP or cluster 556 VIP address. 558 5.3.9 Authentication Data 560 The authentication string is currently only utilized for simple text 561 authentication, similar to the simple text authentication found in 562 the Open Shortest Path First routing protocol [OSPF]. It is up to 8 563 characters of plain text. If the configured authentication string is 564 shorter than 8 bytes, the remaining space MUST be zero-filled. Any 565 VRRP packet with an authentication string that does not match its 566 configured authentication string SHOULD be discarded. The 567 authentication string is unique on a per interface basis. 569 There is no default value for this field. 571 6. Protocol State Machine 573 6.1 Parameters 575 Cluster_ID Cluster identifier. Configured item. There 576 is no default. 578 Priority Priority value for this cluster. Configured 579 item. Range is between 1-255. Default is 580 100 (decimal). 582 Virtual_IP Virtual IP Address for this cluster. 583 Configured item. 585 Advertisement_Interval Time interval between ADVERTISEMENTS in 586 seconds. Default is 1 second. 588 Skew_Time Calculated time to skew Master_Down_Interval 589 in seconds. Defined to be: 591 ( (256 - Priority) / 256 ) 593 Master_Down_Interval Time interval for Backup to declare Master 594 down in seconds. Defined to be: 596 (3 * Advertisement_Interval) + Skew_time 598 Preempt_Mode Configuration switch controlling whether a 599 higher priority VRRP router preempts a lower 600 priority VRRP Master. Values are True to 601 preempt and False to not preempt. Default 602 is True. 604 6.2 Timers 606 Master_Down_Timer Timer that fires when ADVERTISEMENT has not 607 been heard for Master_Down_Interval. 609 Adver_Timer Timer that fires to trigger sending of 610 ADVERTISEMENT based on 611 Advertisement_Interval. 613 6.3 State Transition Diagram 615 +---------------+ 616 | |<-------------+ 617 +--------->| Initialize | | 618 | | |----------+ | 619 | +---------------+ | | 620 | | | 621 | V | 622 +---------------+ +---------------+ 623 | |---------------------->| | 624 | Master | | Backup | 625 | |<----------------------| | 626 +---------------+ +---------------+ 628 6.4 State Descriptions 630 In the state descriptions below, the state names are identified by 631 {state-name}, and the packets are identified by all upper case 632 characters. 634 6.4.1 Initialize 636 {Initialize} is the state a virtual router takes when VRRP is 637 inactive. The purpose of this state is to wait for a Startup event. 638 If a Startup event is received, then: 640 - Set the Master_Down_Timer to Master_Down_Interval 642 - Transition to the {Backup} state 644 6.4.2 Backup 646 The purpose of the {Backup} state is to monitor the availability and 647 state of the Master Router. 649 While in this state, an virtual router MUST do the following: 651 - MUST NOT respond to ARP requests for the virtual router IP address 653 - MUST discard packets with a destination link layer MAC address 654 equal to the virtual router MAC address 656 - MUST not accept packets addressed to the Virtual IP address 657 - If a Shutdown event is received, then: 659 o Cancel the Master_Down_Timer 660 o Transition to the {Initialize} state 662 endif 664 - If the Master_Down_Timer fires, then: 666 o Send an ADVERTISEMENT 667 o Set the Adver_Timer to Advertisement_Interval 668 o Transition to the {Master} state 670 endif 672 - If an ADVERTISEMENT is received, then: 674 If the Priority in the ADVERTISEMENT is Zero, then: 676 o Set the Master_Down_Timer to Skew_Time 678 else: 680 If Preempt_Mode is False, or If the Priority in the 681 ADVERTISEMENT is greater than or equal to the local 682 Priority, then: 684 o Reset the Master_Down_Timer to Master_Down_Interval 686 else: 688 o Discard the ADVERTISEMENT 690 endif 691 endif 692 endif 694 6.4.3 Master 696 While in the {Master} state the router functions as the physical 697 router for the Virtual IP address. 699 While in this state, a virtual router MUST do the following: 701 - MUST respond to ARP requests for the VIP address with the virtual 702 router MAC address 704 - Must accept and forward packets with a destination link layer MAC 705 address equal to the virtual router MAC address 707 - Must accept packets addressed to the VIP address 709 - If a Shutdown event is received, then: 711 o Cancel the Adver_Timer 712 o Send an ADVERTISEMENT with Priority = 0 713 o Transition to the {Initialize} state 715 endif 717 - If the Adver_Timer fires, then: 719 o Send an ADVERTISEMENT 720 o Reset the Adver_Timer to Advertisement_Interval 722 endif 724 - If an ADVERTISEMENT is received, then: 726 If the Priority in the ADVERTISEMENT is Zero, then: 728 o Send an ADVERTISEMENT 729 o Reset the Adver_Timer to Advertisement_Interval 731 else: 733 If the Priority in the ADVERTISEMENT is greater than the 734 local Priority, 735 or 736 If the Priority in the ADVERTISEMENT is equal to the local 737 Priority and the IP Address of the sender is greater than 738 the local IP Address, then: 740 o Cancel Adver_Timer 741 o Set Master_Down_Timer to Master_Down_Interval 742 o Transition to the {Backup} state 744 else: 746 o Discard ADVERTISEMENT 748 endif 749 endif 750 endif 752 7. Sending and Receiving VRRP Packets 754 7.1 Receiving VRRP Packets 756 The following actions MUST be performed when a VRRP packet is 757 received: 759 - Verify that the IP TTL is 255. 760 - Verify that the received packet length is greater than or equal 761 to the VRRP header length 762 - Verify the VRRP checksum 763 - Verify the VRRP version 764 - Perform authentication specified by Auth Type 766 If any one of the above checks fails, the receiver MUST discard the 767 packet, SHOULD log the event and MAY indicate via network management 768 that an error occurred. 770 - Verify that the Cluster identifier and the VIP are valid on the 771 receiving interface 772 - Verify that the VIP in packet is same as the configured VIP for 773 this cluster 775 If any one of the above checks fails, the receiver MUST discard the 776 packet. 778 - Verify that the Adver Interval in the packet is the same as the 779 locally configured for this virtual router 781 If the above check fails, the receiver MUST discard the packet, 782 SHOULD log the event and MAY indicate via network management that an 783 error occurred. 785 7.2 Transmitting Packets 787 The following operations MUST be performed prior to transmitting a 788 VRRP packet. 790 - Fill in the VRRP packet fields with the appropriate virtual 791 router configuration state 792 - Compute the VRRP checksum 793 - Set the source MAC address to Virtual Router MAC Address 794 - Send the VRRP packet to the VRRP IP multicast group 796 Note: VRRP packets are transmitted with the virtual MAC address as 797 the source MAC address to ensure that learning bridges correctly 798 determine the LAN segment the virtual router is attached to. 800 7.3 Virtual Router MAC Address 802 The virtual router MAC address associated with a virtual router is an 803 IEEE 802 MAC Address in the following format: 805 00-00-5E-XX-XX-{cluster id} (in hex in internet standard bit-order) 807 The first three octets are derived from the IANA's OUI. The next two 808 octets (to be assigned by the IANA) indicate the address block 809 assigned to the VRRP protocol. {cluster id} is the VRRP cluster 810 identifier. This mapping provides for up to 255 VRRP clusters on a 811 network. 813 8. Host Operation 815 8.1 Host ARP Requests 817 When a host sends an ARP request for the virtual IP address, the 818 Master router MUST respond to the ARP request with the virtual MAC 819 address for the virtual router. This allows the client to always use 820 the same MAC address regardless of the current Master router. The 821 request MUST be handled as a standard ARP reply. 823 9. Operational Issues 825 9.1 ICMP Redirects 827 VRRP operation relies on hosts only using the Virtual IP address. It 828 is important that client hosts do not learn the real IP address of 829 any VRRP router on the LAN segment. Consequently VRRP routers MUST 830 NOT send ICMP Redirects on any interface they are running VRRP on. 832 9.2 Proxy ARP 834 If Proxy ARP is to be used on a router running VRRP, then the VRRP 835 router must advertise the Virtual Router MAC address in the Proxy ARP 836 message. Doing otherwise could cause hosts to learn the real IP 837 address of the VRRP routers. 839 9.3 Network Management 841 It is important that network management tools (e.g., SNMP, Telnet, 842 etc.) always use the real IP addresses of a VRRP router. This 843 ensures that network management is aware of the status of the real 844 routers (e.g., to detect that a router has failed so that it can be 845 repaired). 847 10. Operation over FDDI and Token Ring 849 10.1 Operation over FDDI 851 FDDI interfaces strip from the FDDI ring frames that have a source 852 MAC address matching the device's hardware address. Under some 853 conditions, such as router isolations, ring failures, protocol 854 transitions, etc., VRRP may cause there to be more than one Master 855 router. If a Master router installs the virtual router MAC address 856 as the hardware address on a FDDI device, then other Masters' 857 ADVERTISEMENTS will be stripped off the ring during the Master 858 convergence, and convergence will fail. 860 To avoid this an implementations SHOULD configure the virtual router 861 MAC address by adding a unicast MAC filter in the FDDI device, rather 862 than changing its hardware MAC address. This will prevent a Master 863 router from stripping any ADVERTISEMENTS it did not originate. 865 10.2 Operation over Token Ring 867 Token Ring has several characteristics which make running VRRP 868 problematic. This includes: 870 - No general multicast mechanism. Required use of "functional 871 addresses" as a substitute, which may collide with other usage of 872 the same "functional addresses". 873 - Token Ring interfaces may have a limited ability to receive on 874 multiple MAC addresses. 875 - In order to switch to a new master located on a different physical 876 ring from the previous master when using source route bridges, a 877 mechanism is required to update cached source route information. 879 Due the these issues and the limited knowledge about the detailed 880 operation of Token Ring by the authors, this version of VRRP does not 881 work over Token Ring networks. This may be remedied in new version 882 of this document, or in a separate document. 884 11. Security Considerations 886 VRRP is designed for a range of internetworking environments that may 887 employ different security policies. The protocol includes several 888 authentication methods ranging from no authentication, simple clear 889 text passwords, and strong authentication using IP Authentication 890 with HMAC. The details on each approach including possible attacks 891 and recommended environments follows. 893 Independent of any authentication type VRRP includes a mechanism 894 (setting TTL=255, checking on receipt) that protects against VRRP 895 packets being injected from another remote network. This limits most 896 vulnerabilities to local attacks. 898 11.1 No Authentication 900 The use of this authentication type means that VRRP protocol 901 exchanges are not authenticated. This type of authentication SHOULD 902 only be used in environments were there is minimal security risk and 903 little chance for configuration errors (e.g., two VRRP routers in a 904 single cluster on a link). 906 11.2 Simple Text Password 908 The use of this authentication type means that VRRP protocol 909 exchanges are authenticated by a simple clear text password. 911 This type of authentication is useful to protect against accidental 912 misconfiguration of routers on a link. It protects against routers 913 inadvertently becoming a member of a VRRP cluster. A new router must 914 first be configured with the correct password before it can become a 915 member of the VRRP cluster. This type of authentication does not 916 protect against hostile attacks where the password can be learned by 917 a node snooping VRRP packets on the link. The Simple Text 918 Authentication combined with the TTL check makes it difficult for a 919 VRRP packet to be sent from another link to disrupt VRRP operation. 921 This type of authentication is RECOMMENDED when there is minimal risk 922 of nodes on the link actively disrupting VRRP operation. 924 11.3 IP Authentication Header 926 The use of this authentication type means the VRRP protocol exchanges 927 are authenticated using the mechanisms defined by the IP 928 Authentication Header [AUTH] using HMAC: Keyed-Hashing for Message 929 Authentication [HMAC]. This provides strong protection against 930 configuration errors, replay attacks, and packet 931 corruption/modification. 933 This type of authentication is RECOMMENDED when there is limited 934 control over the administration of nodes on the link. While this 935 type of authentication does protect the operation of VRRP, there are 936 other types of attacks that may be employed on shared media links 937 (e.g., generation of bogus ARP replies) which are independent from 938 VRRP and are not protected. 940 12. References 942 [AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August 943 1995. 945 [DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256, 946 September 1991. 948 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541, 949 October 1993. 951 [HMAC] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 952 for Message Authentication", RFC-2104, February 1997. 954 [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router 955 Protocol (HSRP)", Internet Draft, , 956 June 1997. 958 [OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997. 960 [RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058, 961 June 1988. 963 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 964 Requirement Levels", RFC-2119, BCP14, March 1997. 966 13. Author's Addresses 968 Steven Knight Phone: +1 612 943-8990 969 Ascend Communications EMail: Steven.Knight@ascend.com 970 High Performance Network Division 971 10250 Valley View Road, Suite 113 972 Eden Prairie, MN USA 55344 973 USA 975 Douglas Weaver Phone: +1 612 943-8990 976 Ascend Communications EMail: Doug.Weaver@ascend.com 977 High Performance Network Division 978 10250 Valley View Road, Suite 113 979 Eden Prairie, MN USA 55344 980 USA 981 David Whipple Phone: +1 206 703-3876 982 Microsoft Corporation EMail: dwhipple@microsoft.com 983 One Microsoft Way 984 Redmond, WA USA 98052-6399 985 USA 987 Robert Hinden Phone: +1 408 990-2004 988 Ipsilon Networks, Inc. EMail: hinden@ipsilon.com 989 232 Java Drive 990 Sunnyvale, CA 94089 991 USA 993 Danny Mitzel Phone: +1 408 990-2037 994 Ipsilon Networks, Inc. EMail: mitzel@ipsilon.com 995 232 Java Drive 996 Sunnyvale, CA 94089 997 USA 999 14. Acknowledgments 1001 The authors would like to thank Glen Zorn, and Michael Lane, Clark 1002 Bremer, Hal Peterson, Peter Hunt, Tony Li, Barbara Denny, and Steve 1003 Bellovin for their comments and suggestions. 1005 15. Changes from Previous Drafts 1007 Changes from 1009 - Added Preempt_Mode to allow user control over preemption 1010 independent of configured priorities. 1011 - Rewrote authentication section and expanded security 1012 considerations. 1013 - Expanded State Description section and removed State Table which 1014 become redundant and impossible to edit. 1015 - Changed authentication to be on a per interface basis (not per 1016 cluster). 1017 - Clarified text on disabling ICMP Redirects. 1018 - Added text on FDDI and Token Ring issues. 1019 - Added HSRP acknowledgment. 1020 - Rewrote Introduction, Required Features, and VRRP Overview 1021 sections. 1022 - Many small text clarifications. 1024 Changes from 1026 - Changed default behavior to stay with current master when 1027 priorities are equal. This behavior can be changed by configuring 1028 explicit priorities. 1029 - Changed Master state behavior to not send Advertisements when 1030 receiving Advertisement with lower priority. Change reduces worst 1031 case election message overhead to "n", where "n" is number of 1032 configured equal priority VRRP routers. 1033 - Added Skew_Time parameter and changed receiving advertisement with 1034 zero priority behavior to cause resulting advertisement sent to be 1035 skewed by priority. 1036 - Changed sending behavior to send VRRP packets with VMAC as source 1037 MAC and added text describing why this is important for bridged 1038 environments. 1039 - Changed definition of VMAC to be in IANA assigned unicast MAC 1040 block. 1041 - Added Advertisement Interval to VRRP header. 1042 - Added text regarding ICMP Redirects, Proxy ARP, and network 1043 management issues. 1044 - Various small text clarifications.