idnits 2.17.1 draft-ietf-vrrp-spec-04.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. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 'SHOULD not' in this paragraph: When a VRRP router restarts or boots, it SHOULD not send any ARP messages with its physical MAC address for the IP address it owns, it 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 141, but not defined == Unused Reference: 'RFC2119' is defined on line 1154, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPX' ** Obsolete normative reference: RFC 1583 (ref. 'OSPF') (Obsoleted by RFC 2178) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. 'RIP') ** Downref: Normative reference to an Historic RFC: RFC 1469 -- Possible downref: Non-RFC (?) normative reference: ref. 'TKARCH' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Knight 2 November 21, 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. 13 Acee Lindem 14 IBM Corporation 16 Virtual Router Redundancy Protocol 18 20 Status of this Memo 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 To learn the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 34 Directories on ds.internic.net (US East Coast), nic.nordu.net 35 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 36 Rim). 38 This internet draft expires on May 21, 1998. 40 Abstract 42 This memo defines the Virtual Router Redundancy Protocol (VRRP). 43 VRRP specifies an election protocol that dynamically assigns 44 responsibility for a virtual router to one of the VRRP routers on a 45 LAN. The VRRP router controlling the IP address(es) associated with 46 a virtual router is called the Master, and forwards packets sent to 47 these IP addresses. The election process provides dynamic fail over 48 in the forwarding responsibility should the Master become 49 unavailable. This allows any of the virtual router IP addresses on 50 the LAN to be used as the default first hop router by end-hosts. The 51 advantage gained from using VRRP is a higher availability default 52 path without requiring configuration of dynamic routing or router 53 discovery protocols on every end-host. 55 Table of Contents 57 1. Introduction...............................................3 58 2. Required Features..........................................5 59 3. VRRP Overview..............................................6 60 4. Sample Configurations......................................8 61 5. Protocol..................................................10 62 5.1 VRRP Packet Format....................................10 63 5.2 IP Field Descriptions.................................10 64 5.3 VRRP Field Descriptions...............................11 65 6. Protocol State Machine....................................14 66 6.1 Parameters............................................14 67 6.2 Timers................................................15 68 6.3 State Transition Diagram..............................15 69 6.4 State Descriptions....................................15 70 7. Sending and Receiving VRRP Packets........................19 71 7.1 Receiving VRRP Packets................................19 72 7.2 Transmitting Packets..................................19 73 7.3 Virtual MAC Address...................................20 74 8. Operational Issues........................................20 75 8.1 ICMP Redirects........................................20 76 8.2 Host ARP Requests.....................................20 77 8.3 Proxy ARP.............................................21 78 9. Operation over FDDI and Token Ring........................21 79 9.1 Operation over FDDI...................................21 80 9.2 Operation over Token Ring.............................21 81 10. Security Considerations...................................24 82 10.1 No Authentication....................................24 83 10.2 Simple Text Password.................................24 84 10.3 IP Authentication Header.............................25 85 11. Acknowledgments...........................................25 86 12. References................................................26 87 13. Authors' Addresses........................................27 88 14. Changes from Previous Drafts..............................29 90 1. Introduction 92 There are a number of methods that an end-host can use to determine 93 its first hop router towards a particular IP destination. These 94 include running (or snooping) a dynamic routing protocol such as 95 Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running 96 an ICMP router discovery client [DISC] or using a statically 97 configured default route. 99 Running a dynamic routing protocol on every end-host may be 100 infeasible for a number of reasons, including administrative 101 overhead, processing overhead, security issues, or lack of a protocol 102 implementation for some platforms. Neighbor or router discovery 103 protocols may require active participation by all hosts on a network, 104 leading to large timer values to reduce protocol overhead in the face 105 of large numbers of hosts. This can result in a significant delay in 106 the detection of a lost (i.e., dead) neighbor, which may introduce 107 unacceptably long "black hole" periods. 109 The use of a statically configured default route is quite popular; it 110 minimizes configuration and processing overhead on the end-host and 111 is supported by virtually every IP implementation. This mode of 112 operation is likely to persist as dynamic host configuration 113 protocols [DHCP] are deployed, which typically provide configuration 114 for an end-host IP address and default gateway. However, this 115 creates a single point of failure. Loss of the default router 116 results in a catastrophic event, isolating all end-hosts that are 117 unable to detect any alternate path that may be available. 119 The Virtual Router Redundancy Protocol (VRRP) is designed to 120 eliminate the single point of failure inherent in the static default 121 routed environment. VRRP specifies an election protocol that 122 dynamically assigns responsibility for a virtual router to one of the 123 VRRP routers on a LAN. The VRRP router controlling the IP 124 address(es) associated with a virtual router is called the Master, 125 and forwards packets sent to these IP addresses. The election 126 process provides dynamic fail-over in the forwarding responsibility 127 should the Master become unavailable. Any of the virtual router's IP 128 addresses on a LAN can then be used as the default first hop router 129 by end-hosts. The advantage gained from using VRRP is a higher 130 availability default path without requiring configuration of dynamic 131 routing or router discovery protocols on every end-host. 133 VRRP provides a function similar to a Cisco Systems, Inc. proprietary 134 protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a 135 Digital Equipment Corporation, Inc. proprietary protocol named IP 136 Standby Protocol. 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 Virtual Router Master are presented. Finally, operational 148 issues related to MAC address mapping, handling of ARP requests, 149 generation of ICMP redirect messages, and security issues are 150 addressed. 152 This protocol is intended for use with IPv4 routers only. A separate 153 specification will be produced if it is decided that similar 154 functionality is desirable in an IPv6 environment. 156 1.2 Definitions 158 VRRP Router A router running the Virtual Router Redundancy 159 Protocol. It may participate in one or more 160 virtual routers. 162 Virtual Router A Virtual Router Identifier with a set of 163 associated IP address(es) across a common LAN. 164 This is the abstract object that is managed by 165 Virtual Router Redundancy Protocol. A VRRP 166 router may backup one or more virtual routers. 168 IP Address Owner The router that has the IP address(es) as real 169 interface address(es). This is the router 170 that, when up, will respond to packets 171 addressed to one of these IP addresses for 172 ICMP pings, TCP connections, etc. 174 Primary IP Address An IP address selected from the set of real 175 interface addresses. One possible selection 176 algorithm is to always select the first 177 address. VRRP advertisements are always sent 178 using the primary IP address as the source of 179 the IP packet. 181 Virtual Router Master The VRRP router that is assuming the 182 responsibility of forwarding packets sent to 183 the IP address(es) associated with the virtual 184 router, and answering ARP requests for these 185 IP addresses. Note that if the IP address 186 owner is available, then it will always become 187 the Master. 189 Virtual Router Backup The set of VRRP routers available to assume 190 forwarding responsibility for a virtual router 191 should the current Master fail. 193 2.0 Required Features 195 This section outlines the set of features that were considered 196 mandatory and that guided the design of VRRP. 198 2.1 IP Address Backup 200 Backup of IP addresses is the primary function of the Virtual Router 201 Redundancy Protocol. While providing election of a Virtual Router 202 Master and the additional functionality described below, the protocol 203 should strive to: 205 - Minimize the duration of black holes. 206 - Minimize the steady state bandwidth overhead and processing 207 complexity. 208 - Function over a wide variety of multiaccess LAN technologies 209 capable of supporting IP traffic. 210 - Provide for election of multiple virtual routers on a network for 211 load balancing 212 - Support of multiple logical IP subnets on a single LAN segment. 214 2.2 Preferred Path Indication 216 A simple model of Master election among a set of redundant routers is 217 to treat each router with equal preference and claim victory after 218 converging to any router as Master. However, there are likely to be 219 many environments where there is a distinct preference (or range of 220 preferences) among the set of redundant routers. For example, this 221 preference may be based upon access link cost or speed, router 222 performance or reliability, or other policy considerations. The 223 protocol should allow the expression of this relative path preference 224 in an intuitive manner, and guarantee Master convergence to the most 225 preferential router currently available. 227 2.3 Minimization of Unnecessary Service Disruptions 229 Once Master election has been performed then any unnecessary 230 transitions between Master and Backup routers can result in a 231 disruption in service. The protocol should ensure after Master 232 election that no state transition is triggered by any Backup router 233 of equal or lower preference as long as the Master continues to 234 function properly. 236 Some environments may find it beneficial to avoid the state 237 transition triggered when a router becomes available that is more 238 preferential than the current Master. It may be useful to support an 239 override of the immediate convergence to the preferred path. 241 2.4 Extensible Security 243 The virtual router functionality is applicable to a wide range of 244 internetworking environments that may employ different security 245 policies. The protocol should require minimal configuration and 246 overhead in the insecure operation, provide for strong authentication 247 when increased security is required, and allow integration of new 248 security mechanisms without breaking backwards compatible operation. 250 2.5 Efficient Operation over Extended LANs 252 Sending IP packets on a multiaccess LAN requires mapping from an IP 253 address to a MAC address. The use of the virtual router MAC address 254 in an extended LAN employing learning bridges can have a significant 255 effect on the bandwidth overhead of packets sent to the virtual 256 router. If the virtual router MAC address is never used as the 257 source address in a link level frame then the station location is 258 never learned, resulting in flooding of all packets sent to the 259 virtual router. To improve the efficiency in this environment the 260 protocol should: 1) use the virtual router MAC as the source in a 261 packet sent by the Master to trigger station learning; 2) trigger a 262 message immediately after transitioning to Master to update the 263 station learning; and 3) trigger periodic messages from the Master to 264 maintain the station learning cache. 266 3.0 VRRP Overview 268 VRRP specifies an election protocol to provide the virtual router 269 function described earlier. All protocol messaging is performed 270 using IP multicast datagrams, thus the protocol can operate over a 271 variety of multiaccess LAN technologies supporting IP multicast. 273 Each VRRP virtual router has a single well-known MAC address 274 allocated to it. This document currently only details the mapping to 275 networks using the IEEE 802 48-bit MAC address. The virtual router 276 MAC address is used as the source in all periodic VRRP messages sent 277 by the Master router to enable bridge learning in an extended LAN. 279 A virtual router is defined by its virtual router identifier (VRID) 280 and a set of IP addresses. A VRRP router may associate a virtual 281 router with its real addresses on an interface, and may also be 282 configured with additional virtual router mappings and priority for 283 virtual routers it is willing to backup. The mapping between VRID 284 and addresses must be coordinated among all VRRP routers on a LAN. 285 However, there is no restriction against reusing a VRID with a 286 different address mapping on different LANs. The scope of each 287 virtual router is restricted to a single LAN. 289 To minimize network traffic, only the Master for each virtual router 290 sends periodic VRRP Advertisement messages. A Backup router will not 291 attempt to pre-empt the Master unless it has higher priority. This 292 eliminates service disruption unless a more preferred path becomes 293 available. It's also possible to administratively prohibit all pre- 294 emption attempts. The only exception is a VRRP router will always 295 become Master of any virtual router associated with addresses it 296 owns. If the Master becomes unavailable then the highest priority 297 Backup will transition to Master after a short delay, providing a 298 controlled transition of the virtual router responsibility with 299 minimal service interruption. 301 VRRP defines three types of authentication providing simple 302 deployment in insecure environments, added protection against 303 misconfiguration, and strong sender authentication in security 304 conscious environments. Analysis of the protection provided and 305 vulnerability of each mechanism is deferred to Section 10.0 Security 306 Considerations. In addition new authentication types and data can be 307 defined in the future without affecting the format of the fixed 308 portion of the protocol packet, thus preserving backward compatible 309 operation. 311 The VRRP protocol design provides rapid transition from Backup to 312 Master to minimize service interruption, and incorporates 313 optimizations that reduce protocol complexity while guaranteeing 314 controlled Master transition for typical operational scenarios. The 315 optimizations result in an election protocol with minimal runtime 316 state requirements, minimal active protocol states, and a single 317 message type and sender. The typical operational scenarios are 318 defined to be two redundant routers and/or distinct path preferences 319 among each router. A side effect when these assumptions are violated 320 (i.e., more than two redundant paths all with equal preference) is 321 that duplicate packets may be forwarded for a brief period during 322 Master election. However, the typical scenario assumptions are 323 likely to cover the vast majority of deployments, loss of the Master 324 router is infrequent, and the expected duration in Master election 325 convergence is quite small ( << 1 second ). Thus the VRRP 326 optimizations represent significant simplifications in the protocol 327 design while incurring an insignificant probability of brief network 328 degradation. 330 4. Sample Configurations 332 4.1 Sample Configuration 1 334 The following figure shows a simple network with two virtual routers. 336 VRID=1 VRID=2 337 +-----+ +-----+ 338 | MR1 | | MR2 | 339 | & | | & | 340 | BR2 | | BR1 | 341 +-----+ +-----+ 342 IP A ---------->* *<---------- IP B 343 | | 344 | | 345 | | 346 ------------------+------------+-----+--------+--------+--------+-- 347 ^ ^ ^ ^ 348 | | | | 349 (IP A) (IP A) (IP A) (IP A) 350 | | | | 351 +--+--+ +--+--+ +--+--+ +--+--+ 352 | H1 | | H2 | | H3 | | H4 | 353 +-----+ +-----+ +--+--+ +--+--+ 355 Legend: 356 ---+---+---+-- = 802 network, Ethernet or FDDI 357 H = Host computer 358 MR = Master Router 359 BR = Backup Router 360 * = IP Address 361 (IP) = default router for hosts 363 The above configuration shows a simple VRRP scenario. In this 364 configuration, the end-hosts install a default route to the IP 365 address of virtual router #1 (IP A) and the routers run VRRP. The 366 router on the left becomes the Master for virtual router #1 (VRID=1) 367 and the router on the right becomes the Master for virtual router # 2 368 (VRID=2). Each router also backs up the other router. If the router 369 on the left should fail, the other router will take over virtual 370 router #1 and its IP addresses, and provide uninterrupted service for 371 the hosts. 373 4.2 Sample Configuration 2 375 The following figure shows a configuration with two virtual routers 376 with the hosts spitting their traffic between them. 378 VRID=1 VRID=2 379 +-----+ +-----+ 380 | MR1 | | MR2 | 381 | & | | & | 382 | BR2 | | BR1 | 383 +-----+ +-----+ 384 IP A ---------->* *<---------- IP B 385 | | 386 | | 387 | | 388 ------------------+------------+-----+--------+--------+--------+-- 389 ^ ^ ^ ^ 390 | | | | 391 (IP A) (IP A) (IP B) (IP B) 392 | | | | 393 +--+--+ +--+--+ +--+--+ +--+--+ 394 | H1 | | H2 | | H3 | | H4 | 395 +-----+ +-----+ +--+--+ +--+--+ 397 Legend: 398 ---+---+---+-- = 802 network, Ethernet or FDDI 399 H = Host computer 400 MR = Master Router 401 BR = Backup Router 402 * = IP Address 403 (IP) = default router for hosts 405 In the above configuration, half of the hosts install a default route 406 to virtual router #1's IP address (IP A), and the other half of the 407 hosts install a default route to virtual router #2's IP address (IP 408 B). This has the effect of load balancing the outgoing traffic, 409 while also providing full redundancy. 411 5.0 Protocol 413 The purpose of the VRRP packet is to communicate to all VRRP routers 414 the priority and the state of the Master router associated with the 415 Virtual Router ID. 417 VRRP packets are sent encapsulated in IP packets. They are sent to 418 the IPv4 multicast address assigned to VRRP. 420 5.1 VRRP Packet Format 422 This section defines the format of the VRRP packet and the relevant 423 fields in the IP header. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Auth Type | Adver Int | Checksum | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | IP Address (1) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | . | 435 | . | 436 | . | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | IP Address (n) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Authentication Data (1) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Authentication Data (2) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 5.2 IP Field Descriptions 447 5.2.1 Source Address 449 The primary IP address of the interface the packet is being sent 450 from. 452 5.2.2 Destination Address 454 The IP multicast address as assigned by the IANA for VRRP is: 456 224.0.0.18 458 This is a link local scope multicast address. Routers MUST NOT 459 forward a datagram with this destination address regardless of its 460 TTL. 462 5.2.3 TTL 464 The TTL MUST be set to 255. A VRRP router receiving a packet with 465 the TTL not equal to 255 MUST discard the packet. 467 5.2.4 Protocol 469 The IP protocol number assigned by the IANA for VRRP is 112 470 (decimal). 472 5.3 VRRP Field Descriptions 474 5.3.1 Version 476 The version field specifies the VRRP protocol version of this packet. 477 This document defines version 2. 479 5.3.2 Type 481 The type field specifies the type of this VRRP packet. The only 482 packet type defined in this version of the protocol is: 484 1 ADVERTISEMENT 486 A packet with unknown type MUST be discarded. 488 5.3.3 Virtual Rtr ID (VRID) 490 The Virtual Router Identifier (VRID) field identifies the virtual 491 router this packet is reporting status for. 493 5.3.4 Priority 495 The priority field specifies the sending VRRP router's priority for 496 the virtual router. Higher values equal higher priority. This field 497 is an 8 bit unsigned integer field. 499 The priority value for the VRRP router that owns the IP address(es) 500 associated with the virtual router MUST be 255 (decimal). 502 VRRP routers backing up a virtual router MUST use priority values 503 between 1-254 (decimal). The default priority value for VRRP routers 504 backing up a virtual router is 100 (decimal). 506 The priority value zero (0) has special meaning indicating that the 507 current Master has stopped participating in VRRP. This is used to 508 trigger Backup routers to quickly transition to Master without having 509 to wait for the current Master to timeout. 511 5.3.5 Count IP Addrs 513 The number of IP addresses contained in this VRRP advertisement. 515 5.3.6 Authentication Type 517 The authentication type field identifies the authentication method 518 being utilized. Authentication type is unique on a per interface 519 basis. The authentication type field is an 8 bit unsigned integer. 520 A packet with unknown authentication type or that does not match the 521 locally configured authentication method MUST be discarded. 523 The authentication methods currently defined are: 525 0 - No Authentication 526 1 - Simple Text Password 527 2 - IP Authentication Header 529 5.3.6.1 No Authentication 531 The use of this authentication type means that VRRP protocol 532 exchanges are not authenticated. The contents of the Authentication 533 Data field should be set to zero on transmission and ignored on 534 reception. 536 5.3.6.2 Simple Text Password 538 The use of this authentication type means that VRRP protocol 539 exchanges are authenticated by a clear text password. The contents 540 of the Authentication Data field should be set to the locally 541 configured password on transmission. There is no default password. 542 The receiver MUST check that the Authentication Data in the packet 543 matches its configured authentication string. Packets that do not 544 match MUST be discarded. 546 5.3.6.3 IP Authentication Header 548 The use of this authentication type means the VRRP protocol exchanges 549 are authenticated using the mechanisms defined by the IP 550 Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP 551 and AH" [HMAC]. Keys may be either configured manually or via a key 552 distribution protocol. 554 If a packet is received that does not pass the authentication check 555 due to a missing authentication header or incorrect message digest, 556 then the packet MUST be discarded. The contents of the 557 Authentication Data field should be set to zero on transmission and 558 ignored on reception. 560 5.3.7 Advertisement Interval (Adver Int) 562 The Advertisement interval indicates the time interval (in seconds) 563 between ADVERTISEMENTS. The default is 1 second. This field is used 564 for troubleshooting misconfigured routers. 566 5.3.8 Checksum 568 The checksum field is used to detect data corruption in the VRRP 569 message. 571 The checksum is the 16-bit one's complement of the one's complement 572 sum of the entire VRRP message starting with the version field. For 573 computing the checksum, the checksum field is set to zero. 575 5.3.9 IP Address(es) 577 One or more IP addresses that are associated with the virtual router. 578 The number of addresses included is specified in the "Count IP Addrs" 579 field. These fields are used for troubleshooting misconfigured 580 routers. 582 5.3.10 Authentication Data 584 The authentication string is currently only utilized for simple text 585 authentication, similar to the simple text authentication found in 586 the Open Shortest Path First routing protocol [OSPF]. It is up to 8 587 characters of plain text. If the configured authentication string is 588 shorter than 8 bytes, the remaining space MUST be zero-filled. Any 589 VRRP packet received with an authentication string that does not 590 match the locally configured authentication string MUST be discarded. 591 The authentication string is unique on a per interface basis. 593 There is no default value for this field. 595 6. Protocol State Machine 597 6.1 Parameters 599 6.1.1 Parameters per Interface 601 Authentication_Type Type of authentication being used. Values 602 are defined in section 5.3.6. 604 Authentication_Data Authentication data specific to the 605 Authentication_Type being used. 607 6.1.2 Parameters per Virtual Router 609 VRID Virtual Router Identifier. Configured item 610 in the range 1-255 (decimal). There is no 611 default. 613 Priority Priority value to be used by this VRRP 614 router in Master election for this virtual 615 router. The value of 255 (decimal) is 616 reserved for the router that owns the IP 617 addresses associated with the virtual 618 router. The value of 0 (zero) is reserved 619 for Master router to indicate it is 620 releasing responsibility for the virtual 621 router. The range 1-254 (decimal) is 622 available for VRRP routers backing up the 623 virtual router. The default value is 100 624 (decimal). 626 IP_Addresses One or more IP addresses associated with 627 this virtual router. Configured item. No 628 default. 630 Advertisement_Interval Time interval between ADVERTISEMENTS 631 (seconds). Default is 1 second. 633 Skew_Time Time to skew Master_Down_Interval in 634 seconds. Calculated as: 636 ( (256 - Priority) / 256 ) 638 Master_Down_Interval Time interval for Backup to declare Master 639 down (seconds). Calculated as: 641 (3 * Advertisement_Interval) + Skew_time 643 Preempt_Mode Controls whether a higher priority Backup 644 router preempts a lower priority Master. 645 Values are True to allow preemption and 646 False to not prohibit preemption. Default 647 is True. 649 Note: Exception is that the router that owns 650 the IP address(es) associated with the 651 virtual router always pre-empts independent 652 of the setting of this flag. 654 6.2 Timers 656 Master_Down_Timer Timer that fires when ADVERTISEMENT has not 657 been heard for Master_Down_Interval. 659 Adver_Timer Timer that fires to trigger sending of 660 ADVERTISEMENT based on 661 Advertisement_Interval. 663 6.3 State Transition Diagram 665 +---------------+ 666 +--------->| |<-------------+ 667 | | Initialize | | 668 | +------| |----------+ | 669 | | +---------------+ | | 670 | | | | 671 | V V | 672 +---------------+ +---------------+ 673 | |---------------------->| | 674 | Master | | Backup | 675 | |<----------------------| | 676 +---------------+ +---------------+ 678 6.4 State Descriptions 680 In the state descriptions below, the state names are identified by 681 {state-name}, and the packets are identified by all upper case 682 characters. 684 A VRRP router implements an instance of the state machine for each 685 virtual router election it is participating in. 687 6.4.1 Initialize 689 The purpose of this state is to wait for a Startup event. If a 690 Startup event is received, then: 692 - If the Priority = 255 (i.e., the router owns the IP address(es) 693 associated with the virtual router) 695 o Send an ADVERTISEMENT 696 o Broadcast a gratuitous ARP request containing the virtual 697 router MAC address for each IP address associated with the 698 virtual router. 699 o Set the Adver_Timer to Advertisement_Interval 700 o Transition to the {Master} state 702 else 704 o Set the Master_Down_Timer to Master_Down_Interval 705 o Transition to the {Backup} state 707 endif 709 6.4.2 Backup 711 The purpose of the {Backup} state is to monitor the availability and 712 state of the Master Router. 714 While in this state, a VRRP router MUST do the following: 716 - MUST NOT respond to ARP requests for the IP address(s) associated 717 with the virtual router. 719 - MUST discard packets with a destination link layer MAC address 720 equal to the virtual router MAC address. 722 - MUST NOT accept packets addressed to the IP address(es) associated 723 with the virtual router. 725 - If a Shutdown event is received, then: 727 o Cancel the Master_Down_Timer 728 o Transition to the {Initialize} state 730 endif 732 - If the Master_Down_Timer fires, then: 734 o Send an ADVERTISEMENT 735 o Broadcast a gratuitous ARP request containing the virtual 736 router MAC address for each IP address associated with the 737 virtual router 738 o Set the Adver_Timer to Advertisement_Interval 739 o Transition to the {Master} state 741 endif 743 - If an ADVERTISEMENT is received, then: 745 If the Priority in the ADVERTISEMENT is Zero, then: 747 o Set the Master_Down_Timer to Skew_Time 749 else: 751 If Preempt_Mode is False, or If the Priority in the 752 ADVERTISEMENT is greater than or equal to the local 753 Priority, then: 755 o Reset the Master_Down_Timer to Master_Down_Interval 757 else: 759 o Discard the ADVERTISEMENT 761 endif 762 endif 763 endif 765 6.4.3 Master 767 While in the {Master} state the router functions as the forwarding 768 router for the IP address(es) associated with the virtual router. 770 While in this state, a VRRP router MUST do the following: 772 - MUST respond to ARP requests for the IP address(es) associated 773 with the virtual router. 775 - MUST forward packets with a destination link layer MAC address 776 equal to the virtual router MAC address. 778 - MUST NOT accept packets addressed to the IP address(es) associated 779 with the virtual router if it is not the IP address owner. 781 - MUST accept packets addressed to the IP address(es) associated 782 with the virtual router if it is the IP address owner. 784 - If a Shutdown event is received, then: 786 o Cancel the Adver_Timer 787 o Send an ADVERTISEMENT with Priority = 0 788 o Transition to the {Initialize} state 790 endif 792 - If the Adver_Timer fires, then: 794 o Send an ADVERTISEMENT 795 o Reset the Adver_Timer to Advertisement_Interval 797 endif 799 - If an ADVERTISEMENT is received, then: 801 If the Priority in the ADVERTISEMENT is Zero, then: 803 o Send an ADVERTISEMENT 804 o Reset the Adver_Timer to Advertisement_Interval 806 else: 808 If the Priority in the ADVERTISEMENT is greater than the 809 local Priority, 810 or 811 If the Priority in the ADVERTISEMENT is equal to the local 812 Priority and the primary IP Address of the sender is greater 813 than the local primary IP Address, then: 815 o Cancel Adver_Timer 816 o Set Master_Down_Timer to Master_Down_Interval 817 o Transition to the {Backup} state 819 else: 821 o Discard ADVERTISEMENT 823 endif 824 endif 825 endif 827 7. Sending and Receiving VRRP Packets 829 7.1 Receiving VRRP Packets 831 Performed the following functions when a VRRP packet is received: 833 - MUST verify that the IP TTL is 255. 834 - MUST verify the VRRP version 835 - MUST verify that the received packet length is greater than or 836 equal to the VRRP header 837 - MUST verify the VRRP checksum 838 - MUST perform authentication specified by Auth Type 840 If any one of the above checks fails, the receiver MUST discard the 841 packet, SHOULD log the event and MAY indicate via network management 842 that an error occurred. 844 - MUST verify that the VRID is valid on the receiving interface 846 If the above check fails, the receiver MUST discard the packet. 848 - MAY verify that the IP address(es) associated with the VRID are 849 valid 851 If the above check fails, the receiver SHOULD log the event and MAY 852 indicate via network management that a misconfiguration was detected. 853 If the packet was not generated by the address owner (Priority does 854 not equal 255 (decimal)), the receiver MUST drop the packet, 855 otherwise continue processing. 857 - MUST verify that the Adver Interval in the packet is the same as 858 the locally configured for this virtual router 860 If the above check fails, the receiver MUST discard the packet, 861 SHOULD log the event and MAY indicate via network management that a 862 misconfiguration was detected. 864 7.2 Transmitting VRRP Packets 866 The following operations MUST be performed when transmitting a VRRP 867 packet. 869 - Fill in the VRRP packet fields with the appropriate virtual 870 router configuration state 871 - Compute the VRRP checksum 872 - Set the source MAC address to Virtual Router MAC Address 873 - Set the source IP address to interface primary IP address 874 - Set the IP protocol to VRRP 875 - Send the VRRP packet to the VRRP IP multicast group 877 Note: VRRP packets are transmitted with the virtual router MAC 878 address as the source MAC address to ensure that learning bridges 879 correctly determine the LAN segment the virtual router is attached 880 to. 882 7.3 Virtual Router MAC Address 884 The virtual router MAC address associated with a virtual router is an 885 IEEE 802 MAC Address in the following format: 887 00-00-5E-XX-XX-{VRID} (in hex in internet standard bit-order) 889 The first three octets are derived from the IANA's OUI. The next two 890 octets (to be assigned by the IANA) indicate the address block 891 assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router 892 Identifier. This mapping provides for up to 255 VRRP routers on a 893 network. 895 8. Operational Issues 897 8.1 ICMP Redirects 899 ICMP Redirects may be used normally when VRRP is running between a 900 group of routers. This allows VRRP to be used in environments where 901 the topology is not symmetric. 903 The IP source address of an ICMP redirect should be the address the 904 end host used when making its next hop routing decision. If a VRRP 905 router is acting as Master for virtual router(s) containing addresses 906 it does not own, then it must determine which virtual router the 907 packet was sent to when selecting the redirect source address. One 908 method to deduce the virtual router used is to examine the 909 destination MAC address in the packet that triggered the redirect. 911 It may be useful to disable Redirects for specific cases where VRRP 912 is being used to load share traffic between a number of routers in a 913 symmetric topology. 915 8.2 Host ARP Requests 917 When a host sends an ARP request for one of the virtual router IP 918 addresses, the Master virtual router MUST respond to the ARP request 919 with the virtual MAC address for the virtual router. The Master 920 virtual router MUST NOT respond with its physical MAC address. This 921 allows the client to always use the same MAC address regardless of 922 the current Master router. 924 When a VRRP router restarts or boots, it SHOULD not send any ARP 925 messages with its physical MAC address for the IP address it owns, it 926 should only send ARP messages that include Virtual MAC addresses. 927 This may entail: 929 - When configuring an interface, VRRP routers should broadcast a 930 gratuitous ARP request containing the virtual router MAC address 931 for each IP address on that interface. 933 - At system boot, when initializing interfaces for VRRP operation; 934 delay gratuitous ARP requests and ARP responses until both the IP 935 address and the virtual router MAC address are configured. 937 8.3 Proxy ARP 939 If Proxy ARP is to be used on a VRRP router, then the VRRP router 940 must advertise the Virtual Router MAC address in the Proxy ARP 941 message. Doing otherwise could cause hosts to learn the real MAC 942 address of the VRRP router. 944 9. Operation over FDDI and Token Ring 946 9.1 Operation over FDDI 948 FDDI interfaces remove from the FDDI ring frames that have a source 949 MAC address matching the device's hardware address. Under some 950 conditions, such as router isolations, ring failures, protocol 951 transitions, etc., VRRP may cause there to be more than one Master 952 router. If a Master router installs the virtual router MAC address 953 as the hardware address on a FDDI device, then other Masters' 954 ADVERTISEMENTS will be removed from the ring during the Master 955 convergence, and convergence will fail. 957 To avoid this an implementation SHOULD configure the virtual router 958 MAC address by adding a unicast MAC filter in the FDDI device, rather 959 than changing its hardware MAC address. This will prevent a Master 960 router from removing any ADVERTISEMENTS it did not originate. 962 9.2 Operation over Token Ring 964 Token ring has several characteristics which make running VRRP 965 difficult. These include: 967 - In order to switch to a new master located on a different bridge 968 token ring segment from the previous master when using source 969 route bridges, a mechanism is required to update cached source 970 route information. 972 - No general multicast mechanism supported across old and new token 973 ring adapter implementations. While many newer token ring adapters 974 support group addresses, token ring functional address support is 975 the only generally available multicast mechanism. Due to the 976 limited number of token ring functional addresses these may 977 collide with other usage of the same token ring functional 978 addresses. 980 Due to these difficulties, the preferred mode of operation over token 981 ring will be to use a token ring functional address for the VRID 982 virtual MAC address. Token ring functional addresses have the two 983 high order bits in the first MAC address octet set to B'1'. They 984 range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format). 985 However, unlike multicast addresses, there is only one unique 986 functional address per bit position. The functional addresses 987 addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved 988 by the Token Ring Architecture [TKARCH] for user-defined 989 applications. However, since there are only 12 user-defined token 990 ring functional addresses, there may be other non-IP protocols using 991 the same functional address. Since the Novell IPX [IPX] protocol uses 992 the 03-00-00-10-00-00 functional address, operation of VRRP over 993 token ring will avoid use of this functional address. In general, 994 token ring VRRP users will be responsible for resolution of other 995 user-defined token ring functional address conflicts. 997 VRIDs are mapped directly to token ring functional addresses. In 998 order to decrease the likelihood of functional address conflicts, 999 allocation will begin with the largest functional address. Most non- 1000 IP protocols use the first or first couple user-defined functional 1001 addresses and it is expected that VRRP users will choose VRIDs 1002 sequentially starting with 1. 1004 VRID Token Ring Functional Address 1005 ---- ----------------------------- 1006 1 03-00-02-00-00-00 1007 2 03-00-04-00-00-00 1008 3 03-00-08-00-00-00 1009 4 03-00-10-00-00-00 1010 5 03-00-20-00-00-00 1011 6 03-00-40-00-00-00 1012 7 03-00-80-00-00-00 1013 8 03-00-00-01-00-00 1014 9 03-00-00-02-00-00 1015 10 03-00-00-04-00-00 1016 11 03-00-00-08-00-00 1018 Or more succinctly, octets 3 and 4 of the functional address are 1019 equal to (0x4000 >> (VRID - 1)) in non-canonical format. 1021 Since a functional address cannot be used used as a MAC level source 1022 address, the real MAC address is used as the MAC source address in 1023 VRRP advertisements. This is not a problem for bridges since packets 1024 addressed to functional addresses will be sent on the spanning-tree 1025 explorer path [802.1D]. 1027 The functional address mode of operation MUST be implemented by 1028 routers supporting VRRP on token ring. 1030 Additionally, routers MAY support unicast mode of operation to take 1031 advantage of newer token ring adapter implementations which support 1032 non-promiscuous reception for multiple unicast MAC addresses and to 1033 avoid both the multicast traffic and usage conflicts associated with 1034 the use of token ring functional addresses. Unicast mode uses the 1035 same mapping of VRIDs to virtual MAC addresses as Ethernet. However, 1036 one important difference exists. ARP request/reply packets contain 1037 the virtual MAC address as the source MAC address. The reason for 1038 this is that some token ring driver implementations keep a cache of 1039 MAC address/source routing information independent of the ARP cache. 1040 Hence, these implementations need have to receive a packet with the 1041 virtual MAC address as the source address in order to transmit to 1042 that MAC address in a source-route bridged network. 1044 Unicast mode on token ring has one limitation which should be 1045 considered. If there are VRID routers on different source-route 1046 bridge segments and there are host implementations which keep their 1047 source-route information in the ARP cache and do not listen to 1048 gratuitous ARPs, these hosts will not update their ARP source-route 1049 information correctly when a switch-over occurs. The only possible 1050 solution is to put all routers with the same VRID on the same source- 1051 bridge segment and use techniques to prevent that bridge segment from 1052 being a single point of failure. These techniques are beyond the 1053 scope this document. 1055 For both the multicast and unicast mode of operation, VRRP 1056 advertisements sent to 224.0.0.TBD should be encapsulated as 1057 described in [RFC1469]. 1059 10. Security Considerations 1061 VRRP is designed for a range of internetworking environments that may 1062 employ different security policies. The protocol includes several 1063 authentication methods ranging from no authentication, simple clear 1064 text passwords, and strong authentication using IP Authentication 1065 with MD5 HMAC. The details on each approach including possible 1066 attacks and recommended environments follows. 1068 Independent of any authentication type VRRP includes a mechanism 1069 (setting TTL=255, checking on receipt) that protects against VRRP 1070 packets being injected from another remote network. This limits most 1071 vulnerabilities to local attacks. 1073 10.1 No Authentication 1075 The use of this authentication type means that VRRP protocol 1076 exchanges are not authenticated. This type of authentication SHOULD 1077 only be used in environments were there is minimal security risk and 1078 little chance for configuration errors (e.g., two VRRP routers on a 1079 LAN). 1081 10.2 Simple Text Password 1083 The use of this authentication type means that VRRP protocol 1084 exchanges are authenticated by a simple clear text password. 1086 This type of authentication is useful to protect against accidental 1087 misconfiguration of routers on a LAN. It protects against routers 1088 inadvertently backing up another router. A new router must first be 1089 configured with the correct password before it can run VRRP with 1090 another router. This type of authentication does not protect against 1091 hostile attacks where the password can be learned by a node snooping 1092 VRRP packets on the LAN. The Simple Text Authentication combined 1093 with the TTL check makes it difficult for a VRRP packet to be sent 1094 from another LAN to disrupt VRRP operation. 1096 This type of authentication is RECOMMENDED when there is minimal risk 1097 of nodes on a LAN actively disrupting VRRP operation. 1099 10.3 IP Authentication Header 1101 The use of this authentication type means the VRRP protocol exchanges 1102 are authenticated using the mechanisms defined by the IP 1103 Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP 1104 and AH", [HMAC]. This provides strong protection against 1105 configuration errors, replay attacks, and packet 1106 corruption/modification. 1108 This type of authentication is RECOMMENDED when there is limited 1109 control over the administration of nodes on a LAN. While this type 1110 of authentication does protect the operation of VRRP, there are other 1111 types of attacks that may be employed on shared media links (e.g., 1112 generation of bogus ARP replies) which are independent from VRRP and 1113 are not protected. 1115 11. Acknowledgments 1117 The authors would like to thank Glen Zorn, and Michael Lane, Clark 1118 Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, and Steve 1119 Bellovin for their comments and suggestions. 1121 12. References 1123 [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 1124 802.1D, 1993 edition. 1126 [AUTH] Atkinson, R., "IP Authentication Header", RFC-1826, August 1127 1995. 1129 [DISC] Deering, S., "ICMP Router Discovery Messages", RFC-1256, 1130 September 1991. 1132 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC-1541, 1133 October 1993. 1135 [HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1136 and AH", Internet Draft, , July 1997. 1139 [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Hot Standby Router 1140 Protocol (HSRP)", Internet Draft, , 1141 June 1997. 1143 [IPX] Novell Incorporated., "IPX Router Specification", Version 1144 1.10, October 1992. 1146 [OSPF] Moy, J., "OSPF version 2", RFC-1583, July 1997. 1148 [RIP] Hedrick, C., "Routing Information Protocol" , RFC-1058, 1149 June 1988. 1151 [RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June 1152 1993. 1154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1155 Requirement Levels", RFC-2119, BCP14, March 1997. 1157 [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication 1158 SC30-3374-02, Third Edition, (September, 1989). 1160 13. Author's Addresses 1162 Steven Knight Phone: +1 612 943-8990 1163 Ascend Communications EMail: Steven.Knight@ascend.com 1164 High Performance Network Division 1165 10250 Valley View Road, Suite 113 1166 Eden Prairie, MN USA 55344 1167 USA 1169 Douglas Weaver Phone: +1 612 943-8990 1170 Ascend Communications EMail: Doug.Weaver@ascend.com 1171 High Performance Network Division 1172 10250 Valley View Road, Suite 113 1173 Eden Prairie, MN USA 55344 1174 USA 1176 David Whipple Phone: +1 206 703-3876 1177 Microsoft Corporation EMail: dwhipple@microsoft.com 1178 One Microsoft Way 1179 Redmond, WA USA 98052-6399 1180 USA 1182 Robert Hinden Phone: +1 408 990-2004 1183 Ipsilon Networks, Inc. EMail: hinden@ipsilon.com 1184 232 Java Drive 1185 Sunnyvale, CA 94089 1186 USA 1188 Danny Mitzel Phone: +1 408 990-2037 1189 Ipsilon Networks, Inc. EMail: mitzel@ipsilon.com 1190 232 Java Drive 1191 Sunnyvale, CA 94089 1192 USA 1194 Peter Hunt Phone: +1 408 990-2093 1195 Ipsilon Networks, Inc. EMail: hunt@ipsilon.com 1196 232 Java Drive 1197 Sunnyvale, CA 94089 1198 USA 1200 P. Higginson Phone: +44 118 920 6293 1201 Digital Equipment Corp. EMail: higginson@mail.dec.com 1202 Digital Park 1203 Imperial Way 1204 Reading 1205 Berkshire 1206 RG2 0TE 1207 UK 1208 M. Shand Phone: +44 118 920 4424 1209 Digital Equipment Corp. EMail: shand@mail.dec.com 1210 Digital Park 1211 Imperial Way 1212 Reading 1213 Berkshire 1214 RG2 0TE 1215 UK 1217 Acee Lindem Phone: 1-919-254-1805 1218 IBM Corporation E-Mail: acee@raleigh.ibm.com 1219 P.O. Box 12195 1220 Research Triangle Park, NC 27709 1221 USA 1223 14. Changes from Previous Drafts 1225 Changes from 1227 - Added IANA assignments for protocol and multicast address. MAC 1228 prefix still needed. 1229 - Added Token Ring specific procedures supplied by Acee Lindem and 1230 added him as an author. 1231 - Tightened up terminology and definitions and made appropriate 1232 changes in the text. 1234 Changes from 1236 - Updated text and references to point to "The Use of HMAC-MD5-96 1237 within ESP and AH" that is the correct reference for the use of 1238 IPSEC AH with MD5. 1240 Changes from 1242 Major change to use real IP addresses instead of virtual IP 1243 addresses. Changes include: 1245 - Updated version number to 2. 1246 - Modified packet header 1247 - New terminology (removed cluster, virtual IP address, etc., added 1248 VRID, associated IP address(es), etc.). 1249 - Special case of priority = 255 for router owning VRID and 1250 associated IP address(es). 1251 - Reworked examples. 1252 - Rewrote introductory and overview sections. 1253 - Added rules for redirects and ARP. 1254 - Added sending gratuitous ARP request when transitioning to Master. 1256 Changes from 1258 - Added Preempt_Mode to allow user control over preemption 1259 independent of configured priorities. 1260 - Rewrote authentication section and expanded security 1261 considerations. 1262 - Expanded State Description section and removed State Table which 1263 become redundant and impossible to edit. 1264 - Changed authentication to be on a per interface basis (not per 1265 cluster). 1266 - Clarified text on disabling ICMP Redirects. 1267 - Added text on FDDI and Token Ring issues. 1269 - Added HSRP acknowledgment. 1270 - Rewrote Introduction, Required Features, and VRRP Overview 1271 sections. 1272 - Many small text clarifications. 1274 Changes from 1276 - Changed default behavior to stay with current master when 1277 priorities are equal. This behavior can be changed by configuring 1278 explicit priorities. 1279 - Changed Master state behavior to not send Advertisements when 1280 receiving Advertisement with lower priority. Change reduces worst 1281 case election message overhead to "n", where "n" is number of 1282 configured equal priority VRRP routers. 1283 - Added Skew_Time parameter and changed receiving advertisement with 1284 zero priority behavior to cause resulting advertisement sent to be 1285 skewed by priority. 1286 - Changed sending behavior to send VRRP packets with VMAC as source 1287 MAC and added text describing why this is important for bridged 1288 environments. 1289 - Changed definition of VMAC to be in IANA assigned unicast MAC 1290 block. 1291 - Added Advertisement Interval to VRRP header. 1292 - Added text regarding ICMP Redirects, Proxy ARP, and network 1293 management issues. 1294 - Various small text clarifications.