idnits 2.17.1 draft-ietf-vrrp-spec-v2-10.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: ---------------------------------------------------------------------------- ** 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.) == There are 2 instances 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 -- The abstract seems to indicate that this document obsoletes RFC2338, but the header doesn't have an 'Obsoletes:' line to match this. 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: == 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: A VRRP router SHOULD not forward packets addressed to the IP Address(es) it becomes Master for if it is not the owner. Forwarding these packets would result in unnecessary traffic. Also in the case of LANs that receive packets they transmit (e.g., token ring) this can result in a forwarding loop that is only terminated when the IP TTL expires. -- 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 131, but not defined == Unused Reference: 'RFC2119' is defined on line 1162, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1071 (ref. 'CKSM') ** Downref: Normative reference to an Informational RFC: RFC 2281 (ref. 'HSRP') -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSTB' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPX' ** Downref: Normative reference to an Historic RFC: RFC 1469 ** Obsolete normative reference: RFC 2338 (Obsoleted by RFC 3768) -- Possible downref: Non-RFC (?) normative reference: ref. 'TKARCH' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Editor 2 February 4, 2004 Nokia 4 Virtual Router Redundancy Protocol 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of [RFC2026]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 This internet draft expires on August 9, 2004. 28 Abstract 30 This memo defines the Virtual Router Redundancy Protocol (VRRP). 31 VRRP specifies an election protocol that dynamically assigns 32 responsibility for a virtual router to one of the VRRP routers on a 33 LAN. The VRRP router controlling the IP address(es) associated with 34 a virtual router is called the Master, and forwards packets sent to 35 these IP addresses. The election process provides dynamic fail over 36 in the forwarding responsibility should the Master become 37 unavailable. This allows any of the virtual router IP addresses on 38 the LAN to be used as the default first hop router by end-hosts. The 39 advantage gained from using VRRP is a higher availability default 40 path without requiring configuration of dynamic routing or router 41 discovery protocols on every end-host. 43 This document replaces RFC2338 "Virtual Router Redundancy Protocol". 45 Table of Contents 47 1. Introduction...............................................3 48 2. Required Features..........................................5 49 3. VRRP Overview..............................................6 50 4. Sample Configurations......................................8 51 5. Protocol..................................................11 52 5.1 VRRP Packet Format....................................11 53 5.2 IP Field Descriptions.................................11 54 5.3 VRRP Field Descriptions...............................12 55 6. Protocol State Machine....................................15 56 6.1 Parameters per Virtual Router.........................15 57 6.2 Timers................................................16 58 6.3 State Transition Diagram..............................16 59 6.4 State Descriptions....................................16 60 7. Sending and Receiving VRRP Packets........................20 61 7.1 Receiving VRRP Packets................................20 62 7.2 Transmitting Packets..................................20 63 7.3 Virtual MAC Address...................................21 64 8. Operational Issues........................................22 65 8.1 ICMP Redirects........................................22 66 8.2 Host ARP Requests.....................................22 67 8.3 Proxy ARP.............................................22 68 8.4 Potential Forwarding Loop.............................23 69 9. Operation over FDDI, Token Ring, and ATM LANE.............23 70 9.1 Operation over FDDI...................................23 71 9.2 Operation over Token Ring.............................23 72 9.3 Operation over ATM LANE...............................25 73 10. Security Considerations...................................26 74 11. Intellectual Property.....................................26 75 12. Acknowledgments...........................................27 76 13. Normative References......................................27 77 14. Informative References....................................28 78 15. Editors' Address..........................................28 79 16. Changes from RFC2338......................................29 81 1. Introduction 83 There are a number of methods that an end-host can use to determine 84 its first hop router towards a particular IP destination. These 85 include running (or snooping) a dynamic routing protocol such as 86 Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running 87 an ICMP router discovery client [DISC] or using a statically 88 configured default route. 90 Running a dynamic routing protocol on every end-host may be 91 infeasible for a number of reasons, including administrative 92 overhead, processing overhead, security issues, or lack of a protocol 93 implementation for some platforms. Neighbor or router discovery 94 protocols may require active participation by all hosts on a network, 95 leading to large timer values to reduce protocol overhead in the face 96 of large numbers of hosts. This can result in a significant delay in 97 the detection of a lost (i.e., dead) neighbor, that may introduce 98 unacceptably long "black hole" periods. 100 The use of a statically configured default route is quite popular; it 101 minimizes configuration and processing overhead on the end-host and 102 is supported by virtually every IP implementation. This mode of 103 operation is likely to persist as dynamic host configuration 104 protocols [DHCP] are deployed, which typically provide configuration 105 for an end-host IP address and default gateway. However, this 106 creates a single point of failure. Loss of the default router 107 results in a catastrophic event, isolating all end-hosts that are 108 unable to detect any alternate path that may be available. 110 The Virtual Router Redundancy Protocol (VRRP) is designed to 111 eliminate the single point of failure inherent in the static default 112 routed environment. VRRP specifies an election protocol that 113 dynamically assigns responsibility for a virtual router to one of the 114 VRRP routers on a LAN. The VRRP router controlling the IP 115 address(es) associated with a virtual router is called the Master, 116 and forwards packets sent to these IP addresses. The election 117 process provides dynamic fail-over in the forwarding responsibility 118 should the Master become unavailable. Any of the virtual router's IP 119 addresses on a LAN can then be used as the default first hop router 120 by end-hosts. The advantage gained from using VRRP is a higher 121 availability default path without requiring configuration of dynamic 122 routing or router discovery protocols on every end-host. 124 VRRP provides a function similar to the proprietary protocols "Hot 125 Standby Router Protocol (HSRP)" [HSRP] and "IP Standby Protocol" 126 [IPSTB]. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC 2119]. 132 1.1 Contributors 134 The following people, who are the authors of the RFC2338 that this 135 document is based on and replaces, contributed to the text in this 136 document. They are P. Higginson, R. Hinden, P. Hunt, S. Knight, A. 137 Lindem, D. Mitzel, M. Shand, D. Weaver, and D. Whipple. They are not 138 listed as authors of the document due to current RFC-Editor policies. 140 1.2 Scope 142 The remainder of this document describes the features, design goals, 143 and theory of operation of VRRP. The message formats, protocol 144 processing rules and state machine that guarantee convergence to a 145 single Virtual Router Master are presented. Finally, operational 146 issues related to MAC address mapping, handling of ARP requests, 147 generation of ICMP redirect messages, and security issues are 148 addressed. 150 This protocol is intended for use with IPv4 routers only. A separate 151 specification will be produced if it is decided that similar 152 functionality is desirable in an IPv6 environment. 154 1.3 Definitions 156 VRRP Router A router running the Virtual Router Redundancy 157 Protocol. It may participate in one or more 158 virtual routers. 160 Virtual Router An abstract object managed by VRRP that acts 161 as a default router for hosts on a shared LAN. 162 It consists of a Virtual Router Identifier and 163 a set of associated IP address(es) across a 164 common LAN. A VRRP Router may backup one or 165 more virtual routers. 167 IP Address Owner The VRRP router that has the virtual router's 168 IP address(es) as real interface address(es). 169 This is the router that, when up, will respond 170 to packets addressed to one of these IP 171 addresses for ICMP pings, TCP connections, 172 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 238 preferred over the current Master. It may be useful to support an 239 override of the immediate convergence to the preferred path. 241 2.4 Efficient Operation over Extended LANs 243 Sending IP packets on a multiaccess LAN requires mapping from an IP 244 address to a MAC address. The use of the virtual router MAC address 245 in an extended LAN employing learning bridges can have a significant 246 effect on the bandwidth overhead of packets sent to the virtual 247 router. If the virtual router MAC address is never used as the 248 source address in a link level frame then the station location is 249 never learned, resulting in flooding of all packets sent to the 250 virtual router. To improve the efficiency in this environment the 251 protocol should: 1) use the virtual router MAC as the source in a 252 packet sent by the Master to trigger station learning; 2) trigger a 253 message immediately after transitioning to Master to update the 254 station learning; and 3) trigger periodic messages from the Master to 255 maintain the station learning cache. 257 3.0 VRRP Overview 259 VRRP specifies an election protocol to provide the virtual router 260 function described earlier. All protocol messaging is performed 261 using IP multicast datagrams, thus the protocol can operate over a 262 variety of multiaccess LAN technologies supporting IP multicast. 263 Each VRRP virtual router has a single well-known MAC address 264 allocated to it. This document currently only details the mapping to 265 networks using the IEEE 802 48-bit MAC address. The virtual router 266 MAC address is used as the source in all periodic VRRP messages sent 267 by the Master router to enable bridge learning in an extended LAN. 269 A virtual router is defined by its virtual router identifier (VRID) 270 and a set of IP addresses. A VRRP router may associate a virtual 271 router with its real addresses on an interface, and may also be 272 configured with additional virtual router mappings and priority for 273 virtual routers it is willing to backup. The mapping between VRID 274 and addresses must be coordinated among all VRRP routers on a LAN. 275 However, there is no restriction against reusing a VRID with a 276 different address mapping on different LANs. The scope of each 277 virtual router is restricted to a single LAN. 279 To minimize network traffic, only the Master for each virtual router 280 sends periodic VRRP Advertisement messages. A Backup router will not 281 attempt to pre-empt the Master unless it has higher priority. This 282 eliminates service disruption unless a more preferred path becomes 283 available. It's also possible to administratively prohibit all pre- 284 emption attempts. The only exception is that a VRRP router will 285 always become Master of any virtual router associated with addresses 286 it owns. If the Master becomes unavailable then the highest priority 287 Backup will transition to Master after a short delay, providing a 288 controlled transition of the virtual router responsibility with 289 minimal service interruption. 291 The VRRP protocol design provides rapid transition from Backup to 292 Master to minimize service interruption, and incorporates 293 optimizations that reduce protocol complexity while guaranteeing 294 controlled Master transition for typical operational scenarios. The 295 optimizations result in an election protocol with minimal runtime 296 state requirements, minimal active protocol states, and a single 297 message type and sender. The typical operational scenarios are 298 defined to be two redundant routers and/or distinct path preferences 299 among each router. A side effect when these assumptions are violated 300 (i.e., more than two redundant paths all with equal preference) is 301 that duplicate packets may be forwarded for a brief period during 302 Master election. However, the typical scenario assumptions are 303 likely to cover the vast majority of deployments, loss of the Master 304 router is infrequent, and the expected duration in Master election 305 convergence is quite small ( << 1 second ). Thus the VRRP 306 optimizations represent significant simplifications in the protocol 307 design while incurring an insignificant probability of brief network 308 degradation. 310 4. Sample Configurations 312 4.1 Sample Configuration 1 314 The following figure shows a simple network with two VRRP routers 315 implementing one virtual router. Note that this example is provided 316 to help understand the protocol, but is not expected to occur in 317 actual practice. 319 +-----------+ +-----------+ 320 | Rtr1 | | Rtr2 | 321 |(MR VRID=1)| |(BR VRID=1)| 322 | | | | 323 VRID=1 +-----------+ +-----------+ 324 IP A ---------->* *<--------- IP B 325 | | 326 | | 327 ------------------+------------+-----+--------+--------+--------+-- 328 ^ ^ ^ ^ 329 | | | | 330 (IP A) (IP A) (IP A) (IP A) 331 | | | | 332 +--+--+ +--+--+ +--+--+ +--+--+ 333 | H1 | | H2 | | H3 | | H4 | 334 +-----+ +-----+ +--+--+ +--+--+ 335 Legend: 336 ---+---+---+-- = Ethernet, Token Ring, or FDDI 337 H = Host computer 338 MR = Master Router 339 BR = Backup Router 340 * = IP Address 341 (IP) = default router for hosts 343 Eliminating all mention of VRRP (VRID=1) from the figure above leaves 344 it as a typical IP deployment. Each router is permanently assigned 345 an IP address on the LAN interface (Rtr1 is assigned IP A and Rtr2 is 346 assigned IP B), and each host installs a static default route through 347 one of the routers (in this example they all use Rtr1's IP A). 349 Moving to the VRRP environment, each router has the exact same 350 permanently assigned IP address. Rtr1 is said to be the IP address 351 owner of IP A, and Rtr2 is the IP address owner of IP B. A virtual 352 router is then defined by associating a unique identifier (the 353 virtual router ID) with the address owned by a router. Finally, the 354 VRRP protocol manages virtual router fail over to a backup router. 356 The example above shows a virtual router configured to cover the IP 357 address owned by Rtr1 (VRID=1,IP_Address=A). When VRRP is enabled on 358 Rtr1 for VRID=1 it will assert itself as Master, with priority=255, 359 since it is the IP address owner for the virtual router IP address. 360 When VRRP is enabled on Rtr2 for VRID=1 it will transition to Backup, 361 with priority=100, since it is not the IP address owner. If Rtr1 362 should fail then the VRRP protocol will transition Rtr2 to Master, 363 temporarily taking over forwarding responsibility for IP A to provide 364 uninterrupted service to the hosts. 366 Note that in this example IP B is not backed up, it is only used by 367 Rtr2 as its interface address. In order to backup IP B, a second 368 virtual router must be configured. This is shown in the next 369 section. 371 4.2 Sample Configuration 2 373 The following figure shows a configuration with two virtual routers 374 with the hosts spitting their traffic between them. This example is 375 expected to be very common in actual practice. 377 +-----------+ +-----------+ 378 | Rtr1 | | Rtr2 | 379 |(MR VRID=1)| |(BR VRID=1)| 380 |(BR VRID=2)| |(MR VRID=2)| 381 VRID=1 +-----------+ +-----------+ VRID=2 382 IP A ---------->* *<---------- IP B 383 | | 384 | | 385 ------------------+------------+-----+--------+--------+--------+-- 386 ^ ^ ^ ^ 387 | | | | 388 (IP A) (IP A) (IP B) (IP B) 389 | | | | 390 +--+--+ +--+--+ +--+--+ +--+--+ 391 | H1 | | H2 | | H3 | | H4 | 392 +-----+ +-----+ +--+--+ +--+--+ 393 Legend: 394 ---+---+---+-- = Ethernet, Token Ring, or FDDI 395 H = Host computer 396 MR = Master Router 397 BR = Backup Router 398 * = IP Address 399 (IP) = default router for hosts 401 In the example above, half of the hosts have configured a static 402 route through Rtr1's IP A and half are using Rtr2's IP B. The 403 configuration of virtual router VRID=1 is exactly the same as in the 404 first example (see section 4.1), and a second virtual router has been 405 added to cover the IP address owned by Rtr2 (VRID=2, IP_Address=B). 406 In this case Rtr2 will assert itself as Master for VRID=2 while Rtr1 407 will act as a backup. This scenario demonstrates a deployment 408 providing load splitting when both routers are available while 409 providing full redundancy for robustness. 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. Configurable item in the 492 range 1-255 (decimal). There is no default. 494 5.3.4 Priority 496 The priority field specifies the sending VRRP router's priority for 497 the virtual router. Higher values equal higher priority. This field 498 is an 8 bit unsigned integer field. 500 The priority value for the VRRP router that owns the IP address(es) 501 associated with the virtual router MUST be 255 (decimal). 503 VRRP routers backing up a virtual router MUST use priority values 504 between 1-254 (decimal). The default priority value for VRRP routers 505 backing up a virtual router is 100 (decimal). 507 The priority value zero (0) has special meaning indicating that the 508 current Master has stopped participating in VRRP. This is used to 509 trigger Backup routers to quickly transition to Master without having 510 to wait for the current Master to timeout. 512 5.3.5 Count IP Addrs 514 The number of IP addresses contained in this VRRP advertisement. 516 5.3.6 Authentication Type 518 The authentication type field identifies the authentication method 519 being utilized. Authentication type is unique on a Virtual Router 520 basis. The authentication type field is an 8 bit unsigned integer. 521 A packet with unknown authentication type or that does not match the 522 locally configured authentication method MUST be discarded. 524 Note: Earlier version of the VRRP specification had several defined 525 authentication types [RFC2338]. These were removed in this 526 specification because operational experience showed that they did not 527 provide any real security and would only cause multiple masters to be 528 created. 530 The authentication methods currently defined are: 532 0 - No Authentication 533 1 - Reserved 534 2 - Reserved 536 5.3.6.1 Authentication Type 0 - No Authentication 538 The use of this authentication type means that VRRP protocol 539 exchanges are not authenticated. The contents of the Authentication 540 Data field should be set to zero on transmission and ignored on 541 reception. 543 5.3.6.2 Authentication Type 1 - Reserved 545 This authentication type is reserved to maintain backwards 546 compatibility with RFC2338. 548 5.3.6.3 Authentication Type 2 - Reserved 550 This authentication type is reserved to maintain backwards 551 compatibility with RFC2338. 553 5.3.7 Advertisement Interval (Adver Int) 555 The Advertisement interval indicates the time interval (in seconds) 556 between ADVERTISEMENTS. The default is 1 second. This field is used 557 for troubleshooting misconfigured routers. 559 5.3.8 Checksum 561 The checksum field is used to detect data corruption in the VRRP 562 message. 564 The checksum is the 16-bit one's complement of the one's complement 565 sum of the entire VRRP message starting with the version field. For 566 computing the checksum, the checksum field is set to zero. See 567 RFC1071 for more detail [CKSM]. 569 5.3.9 IP Address(es) 571 One or more IP addresses that are associated with the virtual router. 572 The number of addresses included is specified in the "Count IP Addrs" 573 field. These fields are used for troubleshooting misconfigured 574 routers. 576 5.3.10 Authentication Data 578 The authentication string is currently only used to maintain 579 backwards compatibility with RFC2338. It SHOULD be set to zero on 580 transmission and ignored on reception. 582 6. Protocol State Machine 584 6.1 Parameters per Virtual Router 586 VRID Virtual Router Identifier. Configurable 587 item in the range 1-255 (decimal). There is 588 no default. 590 Priority Priority value to be used by this VRRP 591 router in Master election for this virtual 592 router. The value of 255 (decimal) is 593 reserved for the router that owns the IP 594 addresses associated with the virtual 595 router. The value of 0 (zero) is reserved 596 for Master router to indicate it is 597 releasing responsibility for the virtual 598 router. The range 1-254 (decimal) is 599 available for VRRP routers backing up the 600 virtual router. The default value is 100 601 (decimal). 603 IP_Addresses One or more IP addresses associated with 604 this virtual router. Configured item. No 605 default. 607 Advertisement_Interval Time interval between ADVERTISEMENTS 608 (seconds). Default is 1 second. 610 Skew_Time Time to skew Master_Down_Interval in 611 seconds. Calculated as: 613 ( (256 - Priority) / 256 ) 615 Master_Down_Interval Time interval for Backup to declare Master 616 down (seconds). Calculated as: 618 (3 * Advertisement_Interval) + Skew_time 620 Preempt_Mode Controls whether a higher priority Backup 621 router preempts a lower priority Master. 622 Values are True to allow preemption and 623 False to prohibit preemption. Default is 624 True. 626 Note: Exception is that the router that owns 627 the IP address(es) associated with the 628 virtual router always pre-empts independent 629 of the setting of this flag. 631 Authentication_Type Type of authentication being used. Values 632 are defined in section 5.3.6. 634 Authentication_Data Authentication data specific to the 635 Authentication_Type being used. 637 6.2 Timers 639 Master_Down_Timer Timer that fires when ADVERTISEMENT has not 640 been heard for Master_Down_Interval. 642 Adver_Timer Timer that fires to trigger sending of 643 ADVERTISEMENT based on 644 Advertisement_Interval. 646 6.3 State Transition Diagram 648 +---------------+ 649 +--------->| |<-------------+ 650 | | Initialize | | 651 | +------| |----------+ | 652 | | +---------------+ | | 653 | | | | 654 | V V | 655 +---------------+ +---------------+ 656 | |---------------------->| | 657 | Master | | Backup | 658 | |<----------------------| | 659 +---------------+ +---------------+ 661 6.4 State Descriptions 663 In the state descriptions below, the state names are identified by 664 {state-name}, and the packets are identified by all upper case 665 characters. 667 A VRRP router implements an instance of the state machine for each 668 virtual router election it is participating in. 670 6.4.1 Initialize 672 The purpose of this state is to wait for a Startup event. If a 673 Startup event is received, then: 675 - If the Priority = 255 (i.e., the router owns the IP address(es) 676 associated with the virtual router) 678 o Send an ADVERTISEMENT 679 o Broadcast a gratuitous ARP request containing the virtual 680 router MAC address for each IP address associated with the 681 virtual router. 682 o Set the Adver_Timer to Advertisement_Interval 683 o Transition to the {Master} state 685 else 687 o Set the Master_Down_Timer to Master_Down_Interval 688 o Transition to the {Backup} state 690 endif 692 6.4.2 Backup 694 The purpose of the {Backup} state is to monitor the availability and 695 state of the Master Router. 697 While in this state, a VRRP router MUST do the following: 699 - MUST NOT respond to ARP requests for the IP address(s) associated 700 with the virtual router. 702 - MUST discard packets with a destination link layer MAC address 703 equal to the virtual router MAC address. 705 - MUST NOT accept packets addressed to the IP address(es) associated 706 with the virtual router. 708 - If a Shutdown event is received, then: 710 o Cancel the Master_Down_Timer 711 o Transition to the {Initialize} state 713 endif 715 - If the Master_Down_Timer fires, then: 717 o Send an ADVERTISEMENT 718 o Broadcast a gratuitous ARP request containing the virtual 719 router MAC address for each IP address associated with the 720 virtual router 721 o Set the Adver_Timer to Advertisement_Interval 722 o Transition to the {Master} state 724 endif 726 - If an ADVERTISEMENT is received, then: 728 If the Priority in the ADVERTISEMENT is Zero, then: 730 o Set the Master_Down_Timer to Skew_Time 732 else: 734 If Preempt_Mode is False, or If the Priority in the 735 ADVERTISEMENT is greater than or equal to the local 736 Priority, then: 738 o Reset the Master_Down_Timer to Master_Down_Interval 740 else: 742 o Discard the ADVERTISEMENT 744 endif 745 endif 746 endif 748 6.4.3 Master 750 While in the {Master} state the router functions as the forwarding 751 router for the IP address(es) associated with the virtual router. 753 While in this state, a VRRP router MUST do the following: 755 - MUST respond to ARP requests for the IP address(es) associated 756 with the virtual router. 758 - MUST forward packets with a destination link layer MAC address 759 equal to the virtual router MAC address. 761 - MUST NOT accept packets addressed to the IP address(es) associated 762 with the virtual router if it is not the IP address owner. 764 - MUST accept packets addressed to the IP address(es) associated 765 with the virtual router if it is the IP address owner. 767 - If a Shutdown event is received, then: 769 o Cancel the Adver_Timer 770 o Send an ADVERTISEMENT with Priority = 0 771 o Transition to the {Initialize} state 773 endif 775 - If the Adver_Timer fires, then: 777 o Send an ADVERTISEMENT 778 o Reset the Adver_Timer to Advertisement_Interval 780 endif 782 - If an ADVERTISEMENT is received, then: 784 If the Priority in the ADVERTISEMENT is Zero, then: 786 o Send an ADVERTISEMENT 787 o Reset the Adver_Timer to Advertisement_Interval 789 else: 791 If the Priority in the ADVERTISEMENT is greater than the 792 local Priority, 793 or 794 If the Priority in the ADVERTISEMENT is equal to the local 795 Priority and the primary IP Address of the sender is greater 796 than the local primary IP Address, then: 798 o Cancel Adver_Timer 799 o Set Master_Down_Timer to Master_Down_Interval 800 o Transition to the {Backup} state 802 else: 804 o Discard ADVERTISEMENT 806 endif 807 endif 808 endif 810 7. Sending and Receiving VRRP Packets 812 7.1 Receiving VRRP Packets 814 Performed the following functions when a VRRP packet is received: 816 - MUST verify that the IP TTL is 255. 817 - MUST verify the VRRP version is 2. 818 - MUST verify that the received packet contains the complete VRRP 819 packet (including fixed fields, IP Address(es), and 820 Authentication Data). 821 - MUST verify the VRRP checksum. 822 - MUST verify that the VRID is configured on the receiving 823 interface and the local router is not the IP Address owner 824 (Priority equals 255 (decimal)). 825 - MUST verify that the Auth Type matches the locally configured 826 authentication method for the virtual router and perform that 827 authentication method. 829 If any one of the above checks fails, the receiver MUST discard the 830 packet, SHOULD log the event and MAY indicate via network management 831 that an error occurred. 833 - MAY verify that "Count IP Addrs" and the list of IP Address 834 matches the IP_Addresses configured for the VRID 836 If the above check fails, the receiver SHOULD log the event and MAY 837 indicate via network management that a misconfiguration was detected. 838 If the packet was not generated by the address owner (Priority does 839 not equal 255 (decimal)), the receiver MUST drop the packet, 840 otherwise continue processing. 842 - MUST verify that the Adver Interval in the packet is the same as 843 the locally configured for this virtual router 845 If the above check fails, the receiver MUST discard the packet, 846 SHOULD log the event and MAY indicate via network management that a 847 misconfiguration was detected. 849 7.2 Transmitting VRRP Packets 851 The following operations MUST be performed when transmitting a VRRP 852 packet. 854 - Fill in the VRRP packet fields with the appropriate virtual 855 router configuration state 856 - Compute the VRRP checksum 857 - Set the source MAC address to Virtual Router MAC Address 858 - Set the source IP address to interface primary IP address 859 - Set the IP protocol to VRRP 860 - Send the VRRP packet to the VRRP IP multicast group 862 Note: VRRP packets are transmitted with the virtual router MAC 863 address as the source MAC address to ensure that learning bridges 864 correctly determine the LAN segment the virtual router is attached 865 to. 867 7.3 Virtual Router MAC Address 869 The virtual router MAC address associated with a virtual router is an 870 IEEE 802 MAC Address in the following format: 872 00-00-5E-00-01-{VRID} (in hex in internet standard bit-order) 874 The first three octets are derived from the IANA's OUI. The next two 875 octets (00-01) indicate the address block assigned to the VRRP 876 protocol. {VRID} is the VRRP Virtual Router Identifier. This 877 mapping provides for up to 255 VRRP routers on a network. 879 8. Operational Issues 881 8.1 ICMP Redirects 883 ICMP Redirects may be used normally when VRRP is running between a 884 group of routers. This allows VRRP to be used in environments where 885 the topology is not symmetric. 887 The IP source address of an ICMP redirect should be the address the 888 end host used when making its next hop routing decision. If a VRRP 889 router is acting as Master for virtual router(s) containing addresses 890 it does not own, then it must determine which virtual router the 891 packet was sent to when selecting the redirect source address. One 892 method to deduce the virtual router used is to examine the 893 destination MAC address in the packet that triggered the redirect. 895 It may be useful to disable Redirects for specific cases where VRRP 896 is being used to load share traffic between a number of routers in a 897 symmetric topology. 899 8.2 Host ARP Requests 901 When a host sends an ARP request for one of the virtual router IP 902 addresses, the Master virtual router MUST respond to the ARP request 903 with the virtual MAC address for the virtual router. The Master 904 virtual router MUST NOT respond with its physical MAC address. This 905 allows the client to always use the same MAC address regardless of 906 the current Master router. 908 When a VRRP router restarts or boots, it SHOULD not send any ARP 909 messages with its physical MAC address for the IP address it owns, it 910 should only send ARP messages that include Virtual MAC addresses. 911 This may entail: 913 - When configuring an interface, VRRP routers should broadcast a 914 gratuitous ARP request containing the virtual router MAC address 915 for each IP address on that interface. 917 - At system boot, when initializing interfaces for VRRP operation; 918 delay gratuitous ARP requests and ARP responses until both the IP 919 address and the virtual router MAC address are configured. 921 8.3 Proxy ARP 923 If Proxy ARP is to be used on a VRRP router, then the VRRP router 924 must advertise the Virtual Router MAC address in the Proxy ARP 925 message. Doing otherwise could cause hosts to learn the real MAC 926 address of the VRRP router. 928 8.4 Potential Forwarding Loop 930 A VRRP router SHOULD not forward packets addressed to the IP 931 Address(es) it becomes Master for if it is not the owner. Forwarding 932 these packets would result in unnecessary traffic. Also in the case 933 of LANs that receive packets they transmit (e.g., token ring) this 934 can result in a forwarding loop that is only terminated when the IP 935 TTL expires. 937 One such mechanism for VRRP routers is to add/delete a reject host 938 route for each adopted IP address when transitioning to/from MASTER 939 state. 941 9. Operation over FDDI, Token Ring, and ATM LANE 943 9.1 Operation over FDDI 945 FDDI interfaces remove from the FDDI ring frames that have a source 946 MAC address matching the device's hardware address. Under some 947 conditions, such as router isolations, ring failures, protocol 948 transitions, etc., VRRP may cause there to be more than one Master 949 router. If a Master router installs the virtual router MAC address 950 as the hardware address on a FDDI device, then other Masters' 951 ADVERTISEMENTS will be removed from the ring during the Master 952 convergence, and convergence will fail. 954 To avoid this an implementation SHOULD configure the virtual router 955 MAC address by adding a unicast MAC filter in the FDDI device, rather 956 than changing its hardware MAC address. This will prevent a Master 957 router from removing any ADVERTISEMENTS it did not originate. 959 9.2 Operation over Token Ring 961 Token ring has several characteristics that make running VRRP 962 difficult. These include: 964 - In order to switch to a new master located on a different bridge 965 token ring segment from the previous master when using source 966 route bridges, a mechanism is required to update cached source 967 route information. 969 - No general multicast mechanism supported across old and new token 970 ring adapter implementations. While many newer token ring adapters 971 support group addresses, token ring functional address support is 972 the only generally available multicast mechanism. Due to the 973 limited number of token ring functional addresses these may 974 collide with other usage of the same token ring functional 975 addresses. 977 Due to these difficulties, the preferred mode of operation over token 978 ring will be to use a token ring functional address for the VRID 979 virtual MAC address. Token ring functional addresses have the two 980 high order bits in the first MAC address octet set to B'1'. They 981 range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format). 982 However, unlike multicast addresses, there is only one unique 983 functional address per bit position. The functional addresses 984 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by the Token 985 Ring Architecture [TKARCH] for user-defined applications. However, 986 since there are only 12 user-defined token ring functional addresses, 987 there may be other non-IP protocols using the same functional 988 address. Since the Novell IPX [IPX] protocol uses the 989 03-00-00-10-00-00 functional address, operation of VRRP over token 990 ring will avoid use of this functional address. In general, token 991 ring VRRP users will be responsible for resolution of other user- 992 defined token ring functional address conflicts. 994 VRIDs are mapped directly to token ring functional addresses. In 995 order to decrease the likelihood of functional address conflicts, 996 allocation will begin with the largest functional address. Most non- 997 IP protocols use the first or first couple user-defined functional 998 addresses and it is expected that VRRP users will choose VRIDs 999 sequentially starting with 1. 1001 VRID Token Ring Functional Address 1002 ---- ----------------------------- 1003 1 03-00-02-00-00-00 1004 2 03-00-04-00-00-00 1005 3 03-00-08-00-00-00 1006 4 03-00-10-00-00-00 1007 5 03-00-20-00-00-00 1008 6 03-00-40-00-00-00 1009 7 03-00-80-00-00-00 1010 8 03-00-00-01-00-00 1011 9 03-00-00-02-00-00 1012 10 03-00-00-04-00-00 1013 11 03-00-00-08-00-00 1015 Or more succinctly, octets 3 and 4 of the functional address are 1016 equal to (0x4000 >> (VRID - 1)) in non-canonical format. 1018 Since a functional address cannot be used used as a MAC level source 1019 address, the real MAC address is used as the MAC source address in 1020 VRRP advertisements. This is not a problem for bridges since packets 1021 addressed to functional addresses will be sent on the spanning-tree 1022 explorer path [802.1D]. 1024 The functional address mode of operation MUST be implemented by 1025 routers supporting VRRP on token ring. 1027 Additionally, routers MAY support unicast mode of operation to take 1028 advantage of newer token ring adapter implementations that support 1029 non-promiscuous reception for multiple unicast MAC addresses and to 1030 avoid both the multicast traffic and usage conflicts associated with 1031 the use of token ring functional addresses. Unicast mode uses the 1032 same mapping of VRIDs to virtual MAC addresses as Ethernet. However, 1033 one important difference exists. ARP request/reply packets contain 1034 the virtual MAC address as the source MAC address. The reason for 1035 this is that some token ring driver implementations keep a cache of 1036 MAC address/source routing information independent of the ARP cache. 1037 Hence, these implementations need to receive a packet with the 1038 virtual MAC address as the source address in order to transmit to 1039 that MAC address in a source-route bridged network. 1041 Unicast mode on token ring has one limitation that should be 1042 considered. If there are VRID routers on different source-route 1043 bridge segments and there are host implementations that keep their 1044 source-route information in the ARP cache and do not listen to 1045 gratuitous ARPs, these hosts will not update their ARP source-route 1046 information correctly when a switch-over occurs. The only possible 1047 solution is to put all routers with the same VRID on the same source- 1048 bridge segment and use techniques to prevent that bridge segment from 1049 being a single point of failure. These techniques are beyond the 1050 scope this document. 1052 For both the multicast and unicast mode of operation, VRRP 1053 advertisements sent to 224.0.0.18 should be encapsulated as described 1054 in [RFC1469]. 1056 9.3 Operation over ATM LANE 1058 Operation of VRRP over ATM LANE on routers with ATM LANE interfaces 1059 and/or routers behind proxy LEC's are beyond the scope of this 1060 document. 1062 10. Security Considerations 1064 VRRP does not currently include any type of authentication. Earlier 1065 versions of the VRRP specification included several types of 1066 authentication ranging from none to strong. Operational experience 1067 and further analysis determined that these did not provide any real 1068 measure of security. Due to the nature of the VRRP protocol, even if 1069 VRRP messages are cryptographically protected, it does not prevent 1070 hostile routers from behaving as if they are a VRRP master, creating 1071 multiple masters. Authentication of VRRP messages could have 1072 prevented a hostile router from causing all properly functioning 1073 routers from going into backup state. However, having multiple 1074 masters can cause as much disruption as no routers, which 1075 authentication cannot prevent. Also, even if a hostile router could 1076 not disrupt VRRP, it can disrupt ARP and create the same effect as 1077 having all routers go into backup. 1079 It should be noted that these attacks are not worse and are a subset 1080 of the attacks that any node attached to a LAN can do independently 1081 of VRRP. The kind of attacks a malicious node on a LAN can do 1082 include promiscuously receiving packets for any routers MAC address, 1083 sending packets with the routers MAC address as the source MAC 1084 addresses in the L2 header to tell the L2 switches to send packets 1085 addressed to the router to the malicious node instead of the router, 1086 send redirects to tell the hosts to send their traffic somewhere 1087 else, send unsolicited ARP replies, answer ARP requests, etc., etc. 1088 All of this can be done independently of implementing VRRP. VRRP 1089 does not add to these vulnerabilities. 1091 Independent of any authentication type VRRP includes a mechanism 1092 (setting TTL=255, checking on receipt) that protects against VRRP 1093 packets being injected from another remote network. This limits most 1094 vulnerabilities to local attacks. 1096 VRRP does not provide any confidentiality. Confidentiality is not 1097 necessary for the correct operation of VRRP and there is no 1098 information in the VRRP messages that must be kept secret from other 1099 nodes on the LAN. 1101 11. Intellectual Property 1103 The IETF takes no position regarding the validity or scope of any 1104 intellectual property or other rights that might be claimed to 1105 pertain to the implementation or use of the technology described in 1106 this document or the extent to which any license under such rights 1107 might or might not be available; neither does it represent that it 1108 has made any effort to identify any such rights. Information on the 1109 IETF's procedures with respect to rights in standards-track and 1110 standards-related documentation can be found in BCP-11. Copies of 1111 claims of rights made available for publication and any assurances of 1112 licenses to be made available, or the result of an attempt made to 1113 obtain a general license or permission for the use of such 1114 proprietary rights by implementors or users of this specification can 1115 be obtained from the IETF Secretariat. See the IETF IPR web page at 1116 http://www.ietf.org/ipr.html for additional information. 1118 The IETF invites any interested party to bring to its attention any 1119 copyrights, patents or patent applications, or other proprietary 1120 rights which may cover technology that may be required to practice 1121 this standard. Please address the information to the IETF Executive 1122 Director. 1124 The IETF has been notified of intellectual property rights claimed in 1125 regard to some or all of the specification contained in this 1126 document. For more information consult the online list of claimed 1127 rights. 1129 12. Acknowledgments 1131 The authors would like to thank Glen Zorn, and Michael Lane, Clark 1132 Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve 1133 Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Radia Perlman, 1134 Russ Housley, Harald Alvestrand, Steve Bellovin, Ned Freed, Ted 1135 Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex Zinin for 1136 their comments and suggestions. 1138 13. Normative References 1140 [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 1141 802.1D, 1993 edition. 1143 [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the 1144 Internet Checksum", RFC1071, September 1988. 1146 [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby 1147 Router Protocol (HSRP)", RFC2281, March 1998. 1149 [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to 1150 Provide Fast Failover in IP Networks", Digital Technical 1151 Journal, Volume 9 Number 3, Winter 1997. 1153 [IPX] Novell Incorporated., "IPX Router Specification", Version 1154 1.10, October 1992. 1156 [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area 1157 Networks", RFC1469, June 1993. 1159 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1160 3", RFC2026, BCP00009, October 1996. 1162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1163 Requirement Levels", RFC2119, BCP0014, March 1997. 1165 [RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol", 1166 RFC2338, April 1998. 1168 [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication 1169 SC30-3374-02, Third Edition, (September, 1989). 1171 14. Informative References 1173 [DISC] Deering, S., "ICMP Router Discovery Messages", RFC1256, 1174 September 1991. 1176 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, 1177 March 1997. 1179 [OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998. 1181 [RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November 1182 1998. 1184 15. Editor's Address 1186 Robert Hinden 1187 Nokia 1188 313 Fairchild Drive 1189 Mountain View, CA 94043 1190 US 1192 Phone: +1 650 625-2004 1193 Email: bob.hinden@nokia.com 1195 16. Changes from RFC2338 1197 - Moved authors of RFC2338 to new Contributers section to comply 1198 with RFC editor policy and listed R. Hinden as Editor. 1199 - Removed authentication methods from VRRP. Changes included: 1200 o Removed the values for password and IPSEC based authentication. 1201 The fields and values are retained to keep backwards 1202 compatibility with RFC2338. 1203 o Removed section on extensible security 1204 o Updated security consideration section to remove discussion of 1205 different authentication methods and added new text explaining 1206 motivation for change and describe vulnerabilities. 1207 - Revised the section 4 examples text with a clearer description of 1208 mapping of IP address owner, priorities, etc. 1209 - Clarify the section 7.1 text describing address list validation. 1210 - Corrected text in Preempt_Mode definition. 1211 - Changed authentication to be per Virtual Router instead of per 1212 Interface. 1213 - Added new subsection (9.3) stating that VRRP over ATM LANE is 1214 beyond the scope of this document. 1215 - Clarified text describing received packet length check. 1216 - Clarified text describing received authentication check. 1217 - Clarified text describing VRID verification check. 1218 - Added new subsection (8.4) describing need to not forward packets 1219 for adopted IP addresses. 1220 - Added clarification to the security considerations section. 1221 - Added reference for computing the internet checksum. 1222 - Updated references and author information. 1223 - Various small editorial changes.