idnits 2.17.1 draft-ietf-vrrp-spec-03.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-26) 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 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 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 907 has weird spacing: '...alizing any o...' == Line 917 has weird spacing: '...address of th...' == 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 'SHOULD not' in this paragraph: When a virtual router restarts or boots, it SHOULD not send any ARP messages with it's physical MAC addresses for the IP addresses it owns. They should only send ARP messages that include Virtual MAC addresses. This may entail: -- 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 135, but not defined == Unused Reference: 'RFC2119' is defined on line 1042, 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) -- Possible downref: Non-RFC (?) normative reference: 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: 12 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Knight 2 October 23, 1997 D. Weaver 3 Ascend Communications, Inc. 4 D. Whipple 5 Microsoft, Inc. 6 R. Hinden 7 D. Mitzel 8 P. Hunt 9 Ipsilon Networks, Inc. 10 P. Higginson 11 M. Shand 12 Digital Equipment Corp. 14 Virtual Router Redundancy Protocol 16 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 To learn the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 32 Directories on ds.internic.net (US East Coast), nic.nordu.net 33 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 34 Rim). 36 This internet draft expires on April 23, 1998. 38 Abstract 40 This memo defines the Virtual Router Redundancy Protocol (VRRP). 41 VRRP specifies an election protocol that dynamically allows a set of 42 routers running VRRP to backup each other on a LAN. The VRRP router 43 controlling one or more IP addresses is called the Master router, and 44 forwards packets sent to these IP addresses. The election process 45 provides dynamic fail over in the forwarding responsibility should 46 the Master become unavailable. This allows any of the VRRP routers 47 IP addresses on the LAN to be used as the default first hop router by 48 end-hosts. The advantage gained from using the VRRP is a higher 49 availability default path without requiring configuration of dynamic 50 routing or router discovery protocols on every end-host. 52 Table of Contents 54 1. Introduction...............................................3 55 2. Required Features..........................................5 56 3. VRRP Overview..............................................6 57 4. Sample Configurations......................................8 58 5. Protocol..................................................10 59 5.1 VRRP Packet Format...................................10 60 5.2 IP Field Descriptions................................10 61 5.3 VRRP Field Descriptions..............................11 62 6. Protocol State Machine....................................14 63 6.1 Parameters.............................................14 64 6.2 Timers.................................................14 65 6.3 State Transition Diagram..............................15 66 6.4 State Descriptions....................................15 67 7. Sending and Receiving VRRP Packets........................18 68 7.1 Receiving VRRP Packets................................18 69 7.2 Transmitting Packets...................................18 70 7.3 Virtual MAC Address....................................19 71 8. Operational Issues........................................20 72 8.1 ICMP Redirects.......................................20 73 8.2 Host ARP Requests.....................................20 74 8.3 Proxy ARP.............................................21 75 9. Operation over FDDI and Token Ring........................21 76 10. Security Considerations...................................22 77 10.1 No Authentication.....................................22 78 10.2 Simple Text Password..................................22 79 10.3 IP Authentication Header..............................22 80 11. Acknowledgments...........................................23 81 12. References................................................24 82 13. Authors' Addresses........................................24 83 14. Changes from Previous Drafts..............................26 85 1. Introduction 87 There are a number of methods that an end-host can use to determine 88 its first hop router towards a particular IP destination. These 89 include running (or snooping) a dynamic routing protocol such as 90 Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running 91 an ICMP router discovery client [DISC] or using a statically 92 configured default route. 94 Running a dynamic routing protocol on every end-host may be 95 infeasible for a number of reasons, including administrative 96 overhead, processing overhead, security issues, or lack of a protocol 97 implementation for some platforms. Neighbor or router discovery 98 protocols may require active participation by all hosts on a network, 99 leading to large timer values to reduce protocol overhead in the face 100 of large numbers of hosts. This can result in a significant delay in 101 the detection of a lost (i.e., dead) neighbor, which may introduce 102 unacceptably long "black hole" periods. 104 The use of a statically configured default route is quite popular; it 105 minimizes configuration and processing overhead on the end-host and 106 is supported by virtually every IP implementation. This mode of 107 operation is likely to persist as dynamic host configuration 108 protocols [DHCP] are deployed, which typically provide configuration 109 for an end-host IP address and default gateway. However, this 110 creates a single point of failure. Loss of the default router 111 results in a catastrophic event, isolating all end-hosts that are 112 unable to detect any alternate path that may be available. 114 The Virtual Router Redundancy Protocol (VRRP) is designed to 115 eliminate the single point of failure inherent in the static default 116 routed environment. VRRP specifies an election protocol that 117 dynamically allows a set of routers to backup each other. The VRRP 118 router controlling one or more IP addresses is called the Master 119 router, and forwards packets sent to these IP addresses. The 120 election process provides dynamic fail-over in the forwarding 121 responsibility should the Master become unavailable. Any of the IP 122 addresses on a virtual router can then be used as the default first 123 hop router by end-hosts. The advantage gained from using the VRRP is 124 a higher availability default path without requiring configuration of 125 dynamic routing or router discovery protocols on every end-host. 127 VRRP provides a function similar to a Cisco Systems, Inc. proprietary 128 protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a 129 Digital Equipment Corporation, Inc. proprietary protocol named IP 130 Standby Protocol. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC 2119]. 136 1.1 Scope 138 The remainder of this document describes the features, design goals, 139 and theory of operation of VRRP. The message formats, protocol 140 processing rules and state machine that guarantee convergence to a 141 single Master router are presented. Finally, operational issues 142 related to MAC address mapping, handling of ARP requests, generation 143 of ICMP redirect messages, and security issues are addressed. 145 This protocol is intended for use with IPv4 routers only. A separate 146 specification will be produced if it is decided that similar 147 functionality is desirable in an IPv6 environment. 149 1.2 Definitions 151 Virtual Router One of a set of routers running VRRP on a LAN. 153 IP Address Owner The virtual router than has the IP address(es) 154 as real interface address(es). This is the 155 router that, when up, will respond to packets 156 addressed to one of these IP addresses for ICMP 157 pings, TCP connections, etc. 159 Primary IP Address An IP address selected from the set of real 160 interface addresses. One possible selection 161 algorithm is to always select the first address. 162 VRRP advertisements are always sent using the 163 primary IP address as the source of the IP 164 packet. 166 Master Router The virtual router that is assuming the 167 responsibility of forwarding packets sent to the 168 IP addresses associated with a virtual router 169 and answering ARP requests for these IP 170 addresses. The Master Router may or may not be 171 the owner. Note that if the IP address owner is 172 available, then it will always be the master 173 router. 175 Backup Router The set of virtual routers available to assume 176 forwarding responsibility for a virtual router 177 should the current master router fail. 179 2.0 Required Features 181 This section outlines the set of features that were considered 182 mandatory and that guided the design of VRRP. 184 2.1 IP Address Backup 186 Backup of IP addresses is the primary function of the Virtual Router 187 Redundancy Protocol. While providing election of a Master router and 188 the additional functionality described below, the protocol should 189 strive to: 191 - Minimize the duration of black holes. 192 - Minimize the steady state bandwidth overhead and processing 193 complexity. 194 - Function over a wide variety of multiaccess LAN technologies 195 capable of supporting IP traffic. 196 - Provide for election of multiple virtual routers on a network for 197 load balancing or in support of multiple logical IP subnets on a 198 single LAN segment. 200 2.2 Preferred Path Indication 202 A simple model of Master election among a set of redundant routers is 203 to treat each router with equal preference and claim victory after 204 converging to any router as Master. However, there are likely to be 205 many environments where there is a distinct preference (or range of 206 preferences) among the set of redundant routers. For example, this 207 preference may be based upon access link cost or speed, router 208 performance or reliability, or other policy considerations. The 209 protocol should allow the expression of this relative path preference 210 in an intuitive manner, and guarantee Master convergence to the most 211 preferential router currently available. 213 2.3 Minimization of Unnecessary Service Disruptions 215 Once Master election has been performed then any unnecessary 216 transitions between Master and Backup routers can result in a 217 disruption in service. The protocol should ensure after Master 218 election that no state transition is triggered by any Backup router 219 of equal or lower preference as long as the Master continues to 220 function properly. 222 Some environments may find it beneficial to avoid the state 223 transition triggered when a router becomes available that is more 224 preferential than the current Master. It may be useful to support an 225 override of the immediate convergence to the preferred path. 227 2.4 Extensible Security 229 The virtual router functionality is applicable to a wide range of 230 internetworking environments that may employ different security 231 policies. The protocol should require minimal configuration and 232 overhead in the insecure operation, provide for strong authentication 233 when increased security is required, and allow integration of new 234 security mechanisms without breaking backwards compatible operation. 236 2.5 Efficient Operation over Extended LANs 238 Sending IP packets on a multiaccess LAN requires mapping from an IP 239 address to a MAC address. The use of the virtual router MAC address 240 in an extended LAN employing learning bridges can have a significant 241 effect on the bandwidth overhead of packets sent to the virtual 242 router. If the virtual router MAC address is never used as the 243 source address in a link level frame then the station location is 244 never learned, resulting in flooding of all packets sent to the 245 virtual router. To improve the efficiency in this environment the 246 protocol should: 1) use the virtual router MAC as the source in a 247 packet sent by the Master to trigger station learning; 2) trigger a 248 message immediately after transitioning to Master to update the 249 station learning; and 3) trigger periodic messages from the Master to 250 maintain the station learning cache. 252 3.0 VRRP Overview 254 VRRP specifies an election protocol to provide the virtual router 255 function described earlier. All protocol messaging is performed 256 using IP multicast datagrams, thus the protocol can operate over a 257 variety of multiaccess LAN technologies supporting IP multicast. 258 Each VRRP virtual router has a single well-known MAC address 259 allocated to it. This document currently only details the mapping to 260 networks using the IEEE 802 48-bit MAC address. The virtual router 261 MAC address is used as the source in all periodic messages sent by 262 the Master router to enable bridge learning in an extended LAN. 264 A virtual router is identified by its virtual router identifier. A 265 VRRP router has a set of addresses that it owns and one or more other 266 virtual routers it is responsible for backing up. On an interface 267 running VRRP, each VRRP router must be configured with a virtual 268 router identifier for the addresses it owns, and the other virtual 269 router identifiers and associated IP addresses that it is responsible 270 for backing up. In addition, each VRRP router is assigned a priority 271 to indicate it's preference in Master election for each virtual 272 router. Multiple virtual routers can be elected on a network and a 273 single router can backup one or more virtual routers. 275 To minimize network traffic, only the Master router sends periodic 276 Advertisement messages. A Backup router will not attempt to pre-empt 277 the Master unless it has higher priority. This eliminates service 278 disruption unless a more preferred path becomes available. It's also 279 possible to administratively prohibit all pre-emption attempts. The 280 only exception to this is that the owner will always become master 281 when it is up. If the Master becomes unavailable then the highest 282 priority Backup will transition to Master after a short delay, 283 providing a controlled transition of the virtual router 284 responsibility with minimal service interruption. 286 VRRP defines three types of authentication providing simple 287 deployment in insecure environments, added protection against 288 misconfiguration, and strong sender authentication in security 289 conscious environments. Analysis of the protection provided and 290 vulnerability of each mechanism is deferred to Section 10.0 Security 291 Considerations. In addition new authentication types and data can be 292 defined in the future without affecting the format of the fixed 293 portion of the protocol packet, thus preserving backward compatible 294 operation. 296 The VRRP protocol design provides rapid transition from Backup to 297 Master to minimize service interruption, and incorporates 298 optimizations that reduce protocol complexity while guaranteeing 299 controlled Master transition for typical operational scenarios. The 300 optimizations result in an election protocol with minimal runtime 301 state requirements, minimal active protocol states, and a single 302 message type and sender. The typical operational scenarios are 303 defined to be two redundant routers and/or distinct path preferences 304 among each router. A side effect when these assumptions are violated 305 (i.e., more than two redundant paths all with equal preference) is 306 that duplicate packets may be forwarded for a brief period during 307 Master election. However, the typical scenario assumptions are 308 likely to cover the vast majority of deployments, loss of the Master 309 router is infrequent, and the expected duration in Master election 310 convergence is quite small ( << 1 second ). Thus the VRRP 311 optimizations represent significant simplifications in the protocol 312 design while incurring an insignificant probability of brief network 313 degradation. 315 4. Sample Configurations 317 4.1 Sample Configuration 1 319 The following figure shows a simple network with two virtual routers. 321 VRID=1 VRID=2 322 +-----+ +-----+ 323 | MR1 | | MR2 | 324 | & | | & | 325 | BR2 | | BR1 | 326 +-----+ +-----+ 327 IP A ---------->* *<---------- IP B 328 | | 329 | | 330 | | 331 ------------------+------------+-----+--------+--------+--------+-- 332 ^ ^ ^ ^ 333 | | | | 334 (IP A) (IP A) (IP A) (IP A) 335 | | | | 336 +--+--+ +--+--+ +--+--+ +--+--+ 337 | H1 | | H2 | | H3 | | H4 | 338 +-----+ +-----+ +--+--+ +--+--+ 340 Legend: 341 ---+---+---+-- = 802 network, Ethernet or FDDI 342 H = Host computer 343 MR = Master Router 344 BR = Backup Router 345 * = IP Address 346 (IP) = default router for hosts 348 The above configuration shows a simple VRRP scenario. In this 349 configuration, the end-hosts install a default route to the IP 350 address of one of the virtual routers (IP A) and the routers run 351 VRRP. The router on the left (VRID=1) becomes the Master router for 352 the IP addresses it owns (IP A) and the router on the right (VRID=2) 353 becomes the Master router for the IP addresses it owns (IP B). Each 354 router also backs up the other router. If the router on the left 355 (VRID=1) should fail, the other router will take over its IP 356 addresses and provide uninterrupted service for the hosts. 358 4.2 Sample Configuration 2 360 The following figure shows a configuration with two virtual routers 361 with the hosts slitting their traffic between them. 363 VRID=1 VRID=2 364 +-----+ +-----+ 365 | MR1 | | MR2 | 366 | & | | & | 367 | BR2 | | BR1 | 368 +-----+ +-----+ 369 IP A ---------->* *<---------- IP B 370 | | 371 | | 372 | | 373 ------------------+------------+-----+--------+--------+--------+-- 374 ^ ^ ^ ^ 375 | | | | 376 (IP A) (IP A) (IP B) (IP B) 377 | | | | 378 +--+--+ +--+--+ +--+--+ +--+--+ 379 | H1 | | H2 | | H3 | | H4 | 380 +-----+ +-----+ +--+--+ +--+--+ 382 Legend: 383 ---+---+---+-- = 802 network, Ethernet or FDDI 384 H = Host computer 385 MR = Master Router 386 BR = Backup Router 387 * = IP Address 388 (IP) = default router for hosts 390 In the above configuration, half of the hosts install a default route 391 to virtual router 1's IP address (IP A), and the other half of the 392 hosts install a default route to virtual router 2's IP address (IP 393 B). This has the effect of load balancing the outgoing traffic, 394 while also providing full redundancy. 396 5.0 Protocol 398 The purpose of the VRRP packet is to communicate to all VRRP routers 399 the priority and the state of the Master router associated with the 400 Virtual Router ID. 402 VRRP packets are sent encapsulated in IP packets. They are sent to 403 an IPv4 multicast address assigned to VRRP. 405 5.1 VRRP Packet Format 407 This section defines the format of the VRRP packet and the relevant 408 fields in the IP header. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Auth Type | Adver Int | Checksum | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | IP Address (1) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | . | 420 | . | 421 | . | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | IP Address (n) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Authentication Data (1) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Authentication Data (2) | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 5.2 IP Field Descriptions 432 5.2.1 Source Address 434 The primary IP address of the interface the packet is being sent 435 from. 437 5.2.2 Destination Address 439 The VRRP IP multicast address assigned by the IANA. It is defined to 440 be: 442 224.0.0.(TBD IANA assignment) 444 This is a link local scope multicast address. Routers MUST NOT 445 forward a datagram with this destination address regardless of its 446 TTL. 448 5.2.3 TTL 450 The TTL MUST be set to 255. A VRRP router receiving a packet with 451 the TTL not equal to 255 MUST discard the packet. 453 5.2.4 Protocol 455 The VRRP IP protocol number assigned by the IANA. It is defined to 456 be (TBD). 458 5.3 VRRP Field Descriptions 460 5.3.1 Version 462 The version field specifies the VRRP protocol version of this packet. 463 This document defines version 2. 465 5.3.2 Type 467 The type field specifies the type of this VRRP packet. The only 468 packet type defined in this version of the protocol is: 470 1 ADVERTISEMENT 472 A packet with unknown type MUST be discarded. 474 5.3.3 Virtual Rtr ID (VRID) 476 The Virtual Router Identifier (VRID) field identifies the virtual 477 router this packet is reporting status for. 479 5.3.4 Priority 481 The priority field specifies the router's priority for the virtual 482 router. Higher values equal higher priority. This field is an 8 bit 483 unsigned field. 485 The priority value for the router that owns the IP address(es) 486 associated with the virtual router MUST be 255 (decimal). 488 VRRP routers backing up another virtual router MAY use priority 489 values between 1-254 (decimal). The default priority value for 490 routers backing up another virtual router is 100 (decimal). 492 The priority value zero (0) has special meaning indicating that the 493 current Master has stopped participating in VRRP. This is used to 494 trigger Backup routers to quickly transition to Master without having 495 to wait for the current Master to timeout. 497 5.3.5 Count IP Addrs 499 The number of IP addresses contained in this VRRP advertisement. 501 5.3.6 Authentication Type 503 The authentication type field identifies the authentication method 504 being utilized. Authentication type is unique on a per interface 505 basis. The authentication type field is an 8 bit number. A packet 506 with unknown authentication type or that does not match the locally 507 configured authentication method MUST be discarded. 509 The authentication methods currently defined are: 511 0 - No Authentication 512 1 - Simple Text Password 513 2 - IP Authentication Header 515 5.3.6.1 No Authentication 517 The use of this authentication type means that VRRP protocol 518 exchanges are not authenticated. The contents of the Authentication 519 Data field should be set to zero on transmission and ignored on 520 reception. 522 5.3.6.2 Simple Text Password 524 The use of this authentication type means that VRRP protocol 525 exchanges are authenticated by a clear text password. The contents 526 of the Authentication Data field should be set to the locally 527 configured password on transmission. There is no default password. 528 The receiver MUST check that the Authentication Data in the packet 529 matches its configured authentication string. Packets that do not 530 match MUST be discarded. 532 5.3.6.3 IP Authentication Header 534 The use of this authentication type means the VRRP protocol exchanges 535 are authenticated using the mechanisms defined by the IP 536 Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP 537 and AH" [HMAC]. Keys may be either configured manually or via a key 538 distribution protocol. 540 If a packet is received that does not pass the authentication check 541 due to a missing authentication header or incorrect message digest, 542 then the packet MUST be discarded. The contents of the 543 Authentication Data field should be set to zero on transmission and 544 ignored on reception. 546 5.3.7 Advertisement Interval (Adver Int) 548 The Advertisement interval indicates the time interval (in seconds) 549 between ADVERTISEMENTS. The default is 1 second. This field is used 550 for troubleshooting misconfigured routers. 552 5.3.8 Checksum 554 The checksum field is used to detect data corruption in the VRRP 555 message. 557 The checksum is the 16-bit one's complement of the one's complement 558 sum of the entire VRRP message starting with the version field. For 559 computing the checksum, the checksum field is set to zero. 561 5.3.9 IP Address(es) 563 One or more IP addresses that are associated with the virtual router. 564 The number of addresses included is specified in the "Count IP Addrs" 565 field. These fields are used for troubleshooting misconfigured 566 routers. 568 5.3.10 Authentication Data 570 The authentication string is currently only utilized for simple text 571 authentication, similar to the simple text authentication found in 572 the Open Shortest Path First routing protocol [OSPF]. It is up to 8 573 characters of plain text. If the configured authentication string is 574 shorter than 8 bytes, the remaining space MUST be zero-filled. Any 575 VRRP packet with an authentication string that does not match its 576 configured authentication string SHOULD be discarded. The 577 authentication string is unique on a per interface basis. 579 There is no default value for this field. 581 6. Protocol State Machine 583 6.1 Parameters 585 6.1.1 Parameters per Interface 587 Authentication_Type Type of authentication being used. Values 588 are defined in section 5.3.6. 590 Authentication_Data Authentication data specific to the 591 Authentication_Type being used. 593 6.1.2 Parameters per Virtual Router 595 Virtual Router Identifier. Configured item in the range 1-255 596 (decimal). There is no default. 598 Priority Priority value to be used in Master election 599 for this virtual router. The value of 255 600 (decimal) is reserved for the router that 601 owns the IP addresses associated with the 602 virtual router. The value of 0 (zero) is 603 reserved for Master router to indicate it 604 has stopped running VRRP. The range 1-254 605 (decimal) is available for VRRP routers 606 backing up the virtual router. The default 607 value is 100 (decimal). 609 IP_Addresses One or more IP addresses associated with 610 this virtual router. Configured item. No 611 default. 613 Advertisement_Interval Time interval between ADVERTISEMENTS 614 (seconds). Default is 1 second. 616 Skew_Time Time to skew Master_Down_Interval in 617 seconds. Calculated as: 619 ( (256 - Priority) / 256 ) 621 Master_Down_Interval Time interval for Backup to declare Master 622 down (seconds). Calculated as: 624 (3 * Advertisement_Interval) + Skew_time 626 Preempt_Mode Controls whether a higher priority Backup 627 router preempts a lower priority Master. 628 Values are True to preempt and False to not 629 preempt. Default is True. 631 Note: Exception is that the router that owns 632 the IP address(es) associated with the 633 virtual router always pre-empts independent 634 of the setting of this flag. 636 6.2 Timers 638 Master_Down_Timer Timer that fires when ADVERTISEMENT has not 639 been heard for Master_Down_Interval. 641 Adver_Timer Timer that fires to trigger sending of 642 ADVERTISEMENT based on 643 Advertisement_Interval. 645 6.3 State Transition Diagram 647 +---------------+ 648 +--------->| |<-------------+ 649 | | Initialize | | 650 | +------| |----------+ | 651 | | +---------------+ | | 652 | | | | 653 | V V | 654 +---------------+ +---------------+ 655 | |---------------------->| | 656 | Master | | Backup | 657 | |<----------------------| | 658 +---------------+ +---------------+ 660 6.4 State Descriptions 662 In the state descriptions below, the state names are identified by 663 {state-name}, and the packets are identified by all upper case 664 characters. 666 6.4.1 Initialize 668 {Initialize} is the state a virtual router takes when it is inactive 669 with respect to the virtual router. The purpose of this state is to 670 wait for a Startup event. If a Startup event is received, then: 672 - If the Priority = 255 (i.e., the router owns the IP address(es) 673 associated with the virtual router) 675 o Send an ADVERTISEMENT 676 o Send a gratuitous ARP request containing the virtual router MAC 677 address for each IP address associated with the virtual router. 678 o Set the Adver_Timer to Advertisement_Interval 679 o Transition to the {Master} state 681 else 683 o Set the Master_Down_Timer to Master_Down_Interval 684 o Transition to the {Backup} state 686 endif 688 6.4.2 Backup 690 The purpose of the {Backup} state is to monitor the availability and 691 state of the Master Router. 693 While in this state, an virtual router MUST do the following: 695 - MUST NOT respond to ARP requests for the IP address(s) associated 696 with this VRID. 698 - MUST discard packets with a destination link layer MAC address 699 equal to the virtual router MAC address for this VRID. 701 - MUST NOT accept packets addressed to the IP address(es) associated 702 with this VRID. 704 - If a Shutdown event is received, then: 706 o Cancel the Master_Down_Timer 707 o Transition to the {Initialize} state 709 endif 711 - If the Master_Down_Timer fires, then: 713 o Send an ADVERTISEMENT 714 o Send a gratuitous ARP request containing their virtual router 715 MAC address for each IP address associated with the virtual 716 router 717 o Set the Adver_Timer to Advertisement_Interval 718 o Transition to the {Master} state 720 endif 722 - If an ADVERTISEMENT is received, then: 724 If the Priority in the ADVERTISEMENT is Zero, then: 726 o Set the Master_Down_Timer to Skew_Time 728 else: 730 If Preempt_Mode is False, or If the Priority in the 731 ADVERTISEMENT is greater than or equal to the local 732 Priority, then: 734 o Reset the Master_Down_Timer to Master_Down_Interval 736 else: 738 o Discard the ADVERTISEMENT 740 endif 741 endif 742 endif 744 6.4.3 Master 746 While in the {Master} state the router functions as the forwarding 747 router for the IP address(es) associated with the virtual router. 749 While in this state, a virtual router MUST do the following: 751 - MUST respond to ARP requests for the IP address(es) associated 752 with the VRID with the virtual router MAC address. 754 - MUST forward packets with a destination link layer MAC address 755 equal to the virtual router MAC address. 757 - MUST NOT accept packets addressed to the IP address(es) associated 758 for the virtual router if it is not the IP address owner. 760 - MUST accept packets addressed to the IP address(es) if it is the 761 IP address owner. 763 - If a Shutdown event is received, then: 765 o Cancel the Adver_Timer 766 o Send an ADVERTISEMENT with Priority = 0 767 o Transition to the {Initialize} state 769 endif 771 - If the Adver_Timer fires, then: 773 o Send an ADVERTISEMENT 774 o Reset the Adver_Timer to Advertisement_Interval 776 endif 778 - If an ADVERTISEMENT is received, then: 780 If the Priority in the ADVERTISEMENT is Zero, then: 782 o Send an ADVERTISEMENT 783 o Reset the Adver_Timer to Advertisement_Interval 785 else: 787 If the Priority in the ADVERTISEMENT is greater than the 788 local Priority, 789 or 790 If the Priority in the ADVERTISEMENT is equal to the local 791 Priority and the primary IP Address of the sender is greater 792 than the local primary IP Address, then: 794 o Cancel Adver_Timer 795 o Set Master_Down_Timer to Master_Down_Interval 796 o Transition to the {Backup} state 798 else: 800 o Discard ADVERTISEMENT 802 endif 803 endif 804 endif 806 7. Sending and Receiving VRRP Packets 808 7.1 Receiving VRRP Packets 810 Performed the following functions when a VRRP packet is received: 812 - MUST verify that the IP TTL is 255. 813 - MUST verify that the received packet length is greater than or 814 equal to the VRRP header 815 - MUST verify the VRRP checksum 816 - MUST verify the VRRP version 817 - MUST perform authentication specified by Auth Type 819 If any one of the above checks fails, the receiver MUST discard the 820 packet, SHOULD log the event and MAY indicate via network management 821 that an error occurred. 823 - MUST verify that the VRID is valid on the receiving interface 825 If the above checks fails, the receiver MUST discard the packet. 827 - MAY verify that the IP address(es) associated with the VRID are 828 valid 830 If the above check fails, the receiver SHOULD log the event and MAY 831 indicate via network management that an error occurred. If the 832 Priority does not equal 255 (decimal), the receiver MUST drop the 833 packet. If the Priority equals 255 (decimal) continue processing. 835 - MUST verify that the Adver Interval in the packet is the same as 836 the locally configured for this virtual router 838 If the above check fails, the receiver MUST discard the packet, 839 SHOULD log the event and MAY indicate via network management that an 840 error occurred. 842 7.2 Transmitting Packets 844 The following operations MUST be performed prior to transmitting a 845 VRRP packet. 847 - Fill in the VRRP packet fields with the appropriate virtual 848 router configuration state 849 - Compute the VRRP checksum 850 - Set the source MAC address to Virtual Router MAC Address 851 - Set the source IP address to interface primary IP address 852 - Send the VRRP packet to the VRRP IP multicast group 854 Note: VRRP packets are transmitted with the virtual router MAC 855 address as the source MAC address to ensure that learning bridges 856 correctly determine the LAN segment the virtual router is attached 857 to. 859 7.3 Virtual Router MAC Address 861 The virtual router MAC address associated with a virtual router is an 862 IEEE 802 MAC Address in the following format: 864 00-00-5E-XX-XX-{VRID} (in hex in internet standard bit-order) 866 The first three octets are derived from the IANA's OUI. The next two 867 octets (to be assigned by the IANA) indicate the address block 868 assigned to the VRRP protocol. {VRID} is the VRRP Router Identifier. 869 This mapping provides for up to 255 VRRP routers on a network. 871 8. Operational Issues 873 8.1 ICMP Redirects 875 ICMP Redirects may be used normally when VRRP is running between a 876 group of routers. This allows VRRP to be used in environments where 877 the topology is not symmetric. 879 When acting as a Master for a VRID it is not the owner, the virtual 880 router MUST send ICMP Redirects using the IP address associated with 881 the VRID as the source of the ICMP Redirect. This entails looking at 882 the destination MAC address in the packet that is being redirected 883 and selecting the appropriate IP address. 885 It may be useful to disable Redirects for specific cases where is 886 VRRP is being used to load share traffic between a number of routers 887 in a symmetric topology. 889 8.2 Host ARP Requests 891 When a host sends an ARP request for one of the virtual routers IP 892 addresses, the Master router MUST respond to the ARP request with the 893 virtual MAC address for the virtual router. The virtual router MUST 894 NOT respond with it's physical MAC address. This allows the client 895 to always use the same MAC address regardless of the current Master 896 router. The request MUST be handled as a standard ARP reply. 898 When a virtual router restarts or boots, it SHOULD not send any ARP 899 messages with it's physical MAC addresses for the IP addresses it 900 owns. They should only send ARP messages that include Virtual MAC 901 addresses. This may entail: 903 - When configuring their interfaces, virtual routers should send a 904 gratuitous ARP request containing their virtual MAC address for 905 each IP address they own on that interface. 907 - At system boot, when initializing any of its IP addresses for 908 which VRRP is configured, delay gratuitous ARP requests and ARP 909 responses for that interface until both the IP address and the 910 virtual MAC address are configured. 912 8.3 Proxy ARP 914 If Proxy ARP is to be used on a router running VRRP, then the VRRP 915 router must advertise the Virtual Router MAC address in the Proxy ARP 916 message. Doing otherwise could cause hosts to learn the real MAC 917 address of the VRRP routers. 919 9. Operation over FDDI and Token Ring 921 9.1 Operation over FDDI 923 FDDI interfaces strip from the FDDI ring frames that have a source 924 MAC address matching the device's hardware address. Under some 925 conditions, such as router isolations, ring failures, protocol 926 transitions, etc., VRRP may cause there to be more than one Master 927 router. If a Master router installs the virtual router MAC address 928 as the hardware address on a FDDI device, then other Masters' 929 ADVERTISEMENTS will be stripped off the ring during the Master 930 convergence, and convergence will fail. 932 To avoid this an implementation SHOULD configure the virtual router 933 MAC address by adding a unicast MAC filter in the FDDI device, rather 934 than changing its hardware MAC address. This will prevent a Master 935 router from stripping any ADVERTISEMENTS it did not originate. 937 9.2 Operation over Token Ring 939 Token Ring has several characteristics which make running VRRP 940 problematic. This includes: 942 - No general multicast mechanism. Required use of "functional 943 addresses" as a substitute, which may collide with other usage of 944 the same "functional addresses". 945 - Token Ring interfaces may have a limited ability to receive on 946 multiple MAC addresses. 947 - In order to switch to a new master located on a different physical 948 ring from the previous master when using source route bridges, a 949 mechanism is required to update cached source route information. 951 Due the these issues and the limited knowledge about the detailed 952 operation of Token Ring by the authors, this version of VRRP does not 953 work over Token Ring networks. This may be remedied in new version 954 of this document, or in a separate document. 956 10. Security Considerations 958 VRRP is designed for a range of internetworking environments that may 959 employ different security policies. The protocol includes several 960 authentication methods ranging from no authentication, simple clear 961 text passwords, and strong authentication using IP Authentication 962 with MD5 HMAC. The details on each approach including possible 963 attacks and recommended environments follows. 965 Independent of any authentication type VRRP includes a mechanism 966 (setting TTL=255, checking on receipt) that protects against VRRP 967 packets being injected from another remote network. This limits most 968 vulnerabilities to local attacks. 970 10.1 No Authentication 972 The use of this authentication type means that VRRP protocol 973 exchanges are not authenticated. This type of authentication SHOULD 974 only be used in environments were there is minimal security risk and 975 little chance for configuration errors (e.g., two VRRP routers on a 976 link). 978 10.2 Simple Text Password 980 The use of this authentication type means that VRRP protocol 981 exchanges are authenticated by a simple clear text password. 983 This type of authentication is useful to protect against accidental 984 misconfiguration of routers on a link. It protects against routers 985 inadvertently backing up another router. A new router must first be 986 configured with the correct password before it can run VRRP with 987 another router. This type of authentication does not protect against 988 hostile attacks where the password can be learned by a node snooping 989 VRRP packets on the link. The Simple Text Authentication combined 990 with the TTL check makes it difficult for a VRRP packet to be sent 991 from another link to disrupt VRRP operation. 993 This type of authentication is RECOMMENDED when there is minimal risk 994 of nodes on the link actively disrupting VRRP operation. 996 10.3 IP Authentication Header 998 The use of this authentication type means the VRRP protocol exchanges 999 are authenticated using the mechanisms defined by the IP 1000 Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP 1001 and AH", [HMAC]. This provides strong protection against 1002 configuration errors, replay attacks, and packet 1003 corruption/modification. 1005 This type of authentication is RECOMMENDED when there is limited 1006 control over the administration of nodes on the link. While this 1007 type of authentication does protect the operation of VRRP, there are 1008 other types of attacks that may be employed on shared media links 1009 (e.g., generation of bogus ARP replies) which are independent from 1010 VRRP and are not protected. 1012 11. Acknowledgments 1014 The authors would like to thank Glen Zorn, and Michael Lane, Clark 1015 Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve 1016 Bellovin, and Acee Lindem for their comments and suggestions. 1018 12. References 1020 [AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August 1021 1995. 1023 [DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256, 1024 September 1991. 1026 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541, 1027 October 1993. 1029 [HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1030 and AH", Internet Draft, , July 1997. 1033 [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router 1034 Protocol (HSRP)", Internet Draft, , 1035 June 1997. 1037 [OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997. 1039 [RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058, 1040 June 1988. 1042 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1043 Requirement Levels", RFC-2119, BCP14, March 1997. 1045 13. Author's Addresses 1047 Steven Knight Phone: +1 612 943-8990 1048 Ascend Communications EMail: Steven.Knight@ascend.com 1049 High Performance Network Division 1050 10250 Valley View Road, Suite 113 1051 Eden Prairie, MN USA 55344 1052 USA 1054 Douglas Weaver Phone: +1 612 943-8990 1055 Ascend Communications EMail: Doug.Weaver@ascend.com 1056 High Performance Network Division 1057 10250 Valley View Road, Suite 113 1058 Eden Prairie, MN USA 55344 1059 USA 1060 David Whipple Phone: +1 206 703-3876 1061 Microsoft Corporation EMail: dwhipple@microsoft.com 1062 One Microsoft Way 1063 Redmond, WA USA 98052-6399 1064 USA 1066 Robert Hinden Phone: +1 408 990-2004 1067 Ipsilon Networks, Inc. EMail: hinden@ipsilon.com 1068 232 Java Drive 1069 Sunnyvale, CA 94089 1070 USA 1072 Danny Mitzel Phone: +1 408 990-2037 1073 Ipsilon Networks, Inc. EMail: mitzel@ipsilon.com 1074 232 Java Drive 1075 Sunnyvale, CA 94089 1076 USA 1078 Peter Hunt Phone: +1 408 990-2093 1079 Ipsilon Networks, Inc. EMail: hunt@ipsilon.com 1080 232 Java Drive 1081 Sunnyvale, CA 94089 1082 USA 1084 P. Higginson Phone: +44 118 920 6293 1085 REO2-F/E9 EMail: higginson@mail.dec.com 1086 Digital Equipment Corp. 1087 Digital Park 1088 Imperial Way 1089 Reading 1090 Berkshire 1091 RG2 0TE 1092 UK 1094 M. Shand Phone: +44 118 920 4424 1095 REO2-F/D9 EMail: shand@mail.dec.com 1096 Digital Equipment Corp. 1097 Digital Park 1098 Imperial Way 1099 Reading 1100 Berkshire 1101 RG2 0TE 1102 UK 1104 14. Changes from Previous Drafts 1106 Changes from 1108 - Updated text and references to point to "The Use of HMAC-MD5-96 1109 within ESP and AH" that is the correct reference for the use of 1110 IPSEC AH with MD5. 1112 Changes from 1114 Major change to use real IP addresses instead of virtual IP 1115 addresses. Changes include: 1117 - Updated version number to 2. 1118 - Modified packet header 1119 - New terminology (removed cluster, virtual IP address, etc., added 1120 VRID, associated IP address(es), etc.). 1121 - Special case of priority = 255 for router owning VRID and 1122 associated IP address(es). 1123 - Reworked examples. 1124 - Rewrote introductory and overview sections. 1125 - Added rules for redirects and ARP. 1126 - Added sending gratuitous ARP request when transitioning to Master. 1128 Changes from 1130 - Added Preempt_Mode to allow user control over preemption 1131 independent of configured priorities. 1132 - Rewrote authentication section and expanded security 1133 considerations. 1134 - Expanded State Description section and removed State Table which 1135 become redundant and impossible to edit. 1136 - Changed authentication to be on a per interface basis (not per 1137 cluster). 1138 - Clarified text on disabling ICMP Redirects. 1139 - Added text on FDDI and Token Ring issues. 1140 - Added HSRP acknowledgment. 1141 - Rewrote Introduction, Required Features, and VRRP Overview 1142 sections. 1143 - Many small text clarifications. 1145 Changes from 1147 - Changed default behavior to stay with current master when 1148 priorities are equal. This behavior can be changed by configuring 1149 explicit priorities. 1150 - Changed Master state behavior to not send Advertisements when 1151 receiving Advertisement with lower priority. Change reduces worst 1152 case election message overhead to "n", where "n" is number of 1153 configured equal priority VRRP routers. 1154 - Added Skew_Time parameter and changed receiving advertisement with 1155 zero priority behavior to cause resulting advertisement sent to be 1156 skewed by priority. 1157 - Changed sending behavior to send VRRP packets with VMAC as source 1158 MAC and added text describing why this is important for bridged 1159 environments. 1160 - Changed definition of VMAC to be in IANA assigned unicast MAC 1161 block. 1162 - Added Advertisement Interval to VRRP header. 1163 - Added text regarding ICMP Redirects, Proxy ARP, and network 1164 management issues. 1165 - Various small text clarifications.