idnits 2.17.1 draft-nadas-vrrp-unified-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1886. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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 IPv4 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: When a VRRP router restarts or boots, it SHOULD not send any ND messages with its physical MAC address for the IPv6 address it owns, it should only send ND 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 IPvX Address 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 IPvX 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.) -- The document date (October 17, 2007) is 6029 days in the past. Is this intentional? 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: 'SJN4' is mentioned on line 1823, but not defined == Missing Reference: 'SJN7' is mentioned on line 1826, but not defined == Missing Reference: 'SJN8' is mentioned on line 1828, but not defined == Missing Reference: 'SJN2' is mentioned on line 1831, but not defined == Missing Reference: 'SJN5' is mentioned on line 1835, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IPX' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798) -- Possible downref: Non-RFC (?) normative reference: ref. 'TKARCH' -- Obsolete informational reference (is this intentional?): RFC 2338 (Obsoleted by RFC 3768) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VRRP S. Nadas 3 Internet-Draft Ericsson 4 Intended status: Standards Track October 17, 2007 5 Expires: April 19, 2008 7 Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6 8 draft-nadas-vrrp-unified-spec-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 19, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo defines the Virtual Router Redundancy Protocol (VRRP) for 42 IPv4 and IPv6. It is version three (3) of the protocol and it is 43 based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on 44 draft-ieft-vrrp-ipv6-spec-08.txt. VRRP specifies an election 45 protocol that dynamically assigns responsibility for a virtual router 46 to one of the VRRP routers on a LAN. The VRRP router controlling the 47 IPv4 or IPv6 address(es) associated with a virtual router is called 48 the Master, and forwards packets sent to these IPv4 or IPv6 49 addresses. VRRP Master routers are configured with virtual IPv4 or 50 IPv6 addresses and VRRP Backup routers infer the address family of 51 the virtual addresses being carried based on the transport protocol. 52 Within a VRRP router the virtual routers in each of the IPv4 and IPv6 53 address families are a domain unto themselves and do not overlap. 54 The election process provides dynamic fail over in the forwarding 55 responsibility should the Master become unavailable. For IPv4, the 56 advantage gained from using VRRP is a higher availability default 57 path without requiring configuration of dynamic routing or router 58 discovery protocols on every end-host. For IPv6, the advantage 59 gained from using VRRP for IPv6 is a quicker switch over to back up 60 routers than can be obtained with standard IPv6 Neighbor Discover 61 (RFC 2461) mechanisms. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.1. A Note on Terminology . . . . . . . . . . . . . . . . . . 5 67 1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.3. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 70 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 72 2. Required Features . . . . . . . . . . . . . . . . . . . . . . 8 73 2.1. IPvX Address Backup . . . . . . . . . . . . . . . . . . . 8 74 2.2. Preferred Path Indication . . . . . . . . . . . . . . . . 9 75 2.3. Minimization of Unnecessary Service Disruptions . . . . . 9 76 2.4. Efficient Operation over Extended LANs . . . . . . . . . . 9 77 2.5. Sub-second Operation for IPv4 and IPv6 . . . . . . . . . . 10 78 3. VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4. Sample Configurations . . . . . . . . . . . . . . . . . . . . 11 80 4.1. Sample Configuration 1 . . . . . . . . . . . . . . . . . . 11 81 4.2. Sample Configuration 2 . . . . . . . . . . . . . . . . . . 13 82 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.1. VRRP Packet Format . . . . . . . . . . . . . . . . . . . . 15 84 5.1.1. IPv4 Field Descriptions . . . . . . . . . . . . . . . 15 85 5.1.1.1. Source Address . . . . . . . . . . . . . . . . . . 15 86 5.1.1.2. Destination Address . . . . . . . . . . . . . . . 16 87 5.1.1.3. TTL . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.1.1.4. Protocol . . . . . . . . . . . . . . . . . . . . . 16 89 5.1.2. IPv6 Field Descriptions . . . . . . . . . . . . . . . 16 90 5.1.2.1. Source Address . . . . . . . . . . . . . . . . . . 16 91 5.1.2.2. Destination Address . . . . . . . . . . . . . . . 16 92 5.1.2.3. Hop Limit . . . . . . . . . . . . . . . . . . . . 16 93 5.1.2.4. Next Header . . . . . . . . . . . . . . . . . . . 16 94 5.2. VRRP Field Descriptions . . . . . . . . . . . . . . . . . 17 95 5.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 17 96 5.2.2. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 5.2.3. Virtual Rtr ID (VRID) . . . . . . . . . . . . . . . . 17 98 5.2.4. Priority . . . . . . . . . . . . . . . . . . . . . . . 17 99 5.2.5. Count IPvX Addr . . . . . . . . . . . . . . . . . . . 17 100 5.2.6. Rsvd . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 5.2.7. Maximum Advertisement Interval (Max Adver Int) . . . . 18 102 5.2.8. Checksum . . . . . . . . . . . . . . . . . . . . . . . 18 103 5.2.9. IPvX Address(es) . . . . . . . . . . . . . . . . . . . 18 104 6. Protocol State Machine . . . . . . . . . . . . . . . . . . . . 18 105 6.1. Parameters per Virtual Router . . . . . . . . . . . . . . 19 106 6.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 6.3. State Transition Diagram . . . . . . . . . . . . . . . . . 20 108 6.4. State Descriptions . . . . . . . . . . . . . . . . . . . . 21 109 6.4.1. Initialize . . . . . . . . . . . . . . . . . . . . . . 21 110 6.4.2. Backup . . . . . . . . . . . . . . . . . . . . . . . . 22 111 6.4.3. Master . . . . . . . . . . . . . . . . . . . . . . . . 24 112 7. Sending and Receiving VRRP Packets . . . . . . . . . . . . . . 27 113 7.1. Receiving VRRP Packets . . . . . . . . . . . . . . . . . . 27 114 7.2. Transmitting VRRP Packets . . . . . . . . . . . . . . . . 28 115 7.3. Virtual Router MAC Address . . . . . . . . . . . . . . . . 28 116 7.4. IPv6 Interface Identifiers . . . . . . . . . . . . . . . . 29 117 8. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 29 118 8.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 119 8.1.1. ICMP Redirects . . . . . . . . . . . . . . . . . . . . 29 120 8.1.2. Host ARP Requests . . . . . . . . . . . . . . . . . . 30 121 8.1.3. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . 30 122 8.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 123 8.2.1. ICMPv6 Redirects . . . . . . . . . . . . . . . . . . . 30 124 8.2.2. ND Neighbor Solicitation . . . . . . . . . . . . . . . 31 125 8.2.3. Router Advertisements . . . . . . . . . . . . . . . . 31 126 8.3. IPvX . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 127 8.3.1. Potential Forwarding Loop . . . . . . . . . . . . . . 32 128 8.3.2. Recommendations regarding setting priority values . . 32 129 9. Operation over FDDI, Token Ring, and ATM LANE . . . . . . . . 32 130 9.1. Operation over FDDI . . . . . . . . . . . . . . . . . . . 32 131 9.2. Operation over Token Ring . . . . . . . . . . . . . . . . 33 132 9.3. Operation over ATM LANE . . . . . . . . . . . . . . . . . 35 133 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 134 11. Intellectual Property Rights Claimed . . . . . . . . . . . . . 36 135 12. Contributors & Acknowledgments . . . . . . . . . . . . . . . . 36 136 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 137 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 138 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 139 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 140 Appendix A. VRRPv3 and VRRPv2 Interoperation . . . . . . . . . . 39 141 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 39 142 A.2. VRRPv3 support of VRRPv2 . . . . . . . . . . . . . . . . . 39 143 A.3. VRRPv3 support of VRRPv2 Considerations . . . . . . . . . 39 144 A.3.1. Slow, High-Priority Masters . . . . . . . . . . . . . 39 145 A.3.2. Overwhelming VRRPv2 Backups . . . . . . . . . . . . . 40 146 Appendix B. Changes from [I-D.ietf-vrrp-ipv6-spec] and 147 [RFC3768] . . . . . . . . . . . . . . . . . . . . . . 40 148 Appendix C. TBDs . . . . . . . . . . . . . . . . . . . . . . . . 41 149 Appendix D. Changes from -00 version . . . . . . . . . . . . . . 41 150 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 151 Intellectual Property and Copyright Statements . . . . . . . . . . 43 153 1. Introduction 155 This memo defines the Virtual Router Redundancy Protocol (VRRP) for 156 IPv4 and IPv6. It is version three (3) of the protocol. It is based 157 on VRRP (version 2) for IPv4 that is defined in [RFC3768] and on 158 [I-D.ietf-vrrp-ipv6-spec]. VRRP specifies an election protocol that 159 dynamically assigns responsibility for a virtual router to one of the 160 VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 161 address(es) associated with a virtual router is called the Master, 162 and forwards packets sent to these IPv4 or IPv6 addresses. VRRP 163 Master routers are configured with virtual IPv4 or IPv6 addresses and 164 VRRP Backup routers infer the address family of the virtual addresses 165 being carried based on the transport protocol. Within a VRRP router 166 the virtual routers in each of the IPv4 and IPv6 address families are 167 a domain unto themselves and do not overlap. The election process 168 provides dynamic fail over in the forwarding responsibility should 169 the Master become unavailable. 171 Comments are solicited and should be addressed to the working group's 172 mailing list at vrrp@ietf.org and/or the author(s). 174 VRRP provides a function similar to the proprietary protocols "Hot 175 Standby Router Protocol (HSRP)" [RFC2281] and "IP Standby Protocol" 176 [IPSTB]. 178 1.1. A Note on Terminology 180 This draft discusses both IPv4 and IPv6 operation and with respect to 181 the VRRP protocol, many of the descriptions and procedures are 182 common. In this draft, it would be less verbose to be able refer to 183 "IP" to mean either "IPv4 or IPv6". However, historically, the term 184 "IP" usually refers to IPv4. For this reason, in this specification, 185 the term "IPvX" (where X is 4 or 6) is introduced to mean either 186 "IPv4 or IPv6", in text where the IP version matters, the appropriate 187 term is used and the use of the term "IP" is avoided. 189 1.2. IPv4 191 There are a number of methods that an IPv4 end-host can use to 192 determine its first hop router towards a particular IPv4 destination. 193 These include running (or snooping) a dynamic routing protocol such 194 as Routing Information Protocol [RFC2453] or OSPF version 2 195 [RFC2328], running an ICMP router discovery client [RFC1256] or using 196 a statically configured default route. 198 Running a dynamic routing protocol on every end-host may be 199 infeasible for a number of reasons, including administrative 200 overhead, processing overhead, security issues, or lack of a protocol 201 implementation for some platforms. Neighbor or router discovery 202 protocols may require active participation by all hosts on a network, 203 leading to large timer values to reduce protocol overhead in the face 204 of large numbers of hosts. This can result in a significant delay in 205 the detection of a lost (i.e., dead) neighbor, that may introduce 206 unacceptably long "black hole" periods. 208 The use of a statically configured default route is quite popular; it 209 minimizes configuration and processing overhead on the end-host and 210 is supported by virtually every IPv4 implementation. This mode of 211 operation is likely to persist as dynamic host configuration 212 protocols [RFC2131] are deployed, which typically provide 213 configuration for an end-host IPv4 address and default gateway. 214 However, this creates a single point of failure. Loss of the default 215 router results in a catastrophic event, isolating all end-hosts that 216 are unable to detect any alternate path that may be available. 218 The Virtual Router Redundancy Protocol (VRRP) is designed to 219 eliminate the single point of failure inherent in the static default 220 routed environment. VRRP specifies an election protocol that 221 dynamically assigns responsibility for a virtual router to one of the 222 VRRP routers on a LAN. The VRRP router controlling the IPv4 223 address(es) associated with a virtual router is called the Master, 224 and forwards packets sent to these IPv4 addresses. The election 225 process provides dynamic fail-over in the forwarding responsibility 226 should the Master become unavailable. Any of the virtual router's 227 IPv4 addresses on a LAN can then be used as the default first hop 228 router by end-hosts. The advantage gained from using VRRP is a 229 higher availability default path without requiring configuration of 230 dynamic routing or router discovery protocols on every end-host. 232 1.3. IPv6 234 IPv6 hosts on a LAN will usually learn about one or more default 235 routers by receiving Router Advertisements sent using the IPv6 236 Neighbor Discovery protocol [RFC2461]. The Router Advertisements are 237 multicast periodically at a rate that the hosts will learn about the 238 default routers in a few minutes. They are not sent frequently 239 enough to rely on the absence of the router advertisement to detect 240 router failures. 242 Neighbor Discovery (ND) includes a mechanism called Neighbor 243 Unreachability Detection to detect the failure of a neighbor node 244 (router or host) or the forwarding path to a neighbor. This is done 245 by sending unicast ND Neighbor Solicitation messages to the neighbor 246 node. To reduce the overhead of sending Neighbor Solicitations, they 247 are only sent to neighbors to which the node is actively sending 248 traffic and only after there has been no positive indication that the 249 router is up for a period of time. Using the default parameters in 250 ND, it will take a host about 38 seconds to learn that a router is 251 unreachable before it will switch to another default router. This 252 delay would be very noticeable to users and cause some transport 253 protocol implementations to timeout. 255 While the ND unreachability detection could be speeded up by changing 256 the parameters to be more aggressive (note that the current lower 257 limit for this is 5 seconds), this would have the downside of 258 significantly increasing the overhead of ND traffic. Especially when 259 there are many hosts all trying to determine the reachability of a 260 one of more routers. 262 The Virtual Router Redundancy Protocol for IPv6 provides a much 263 faster switch over to an alternate default router than can be 264 obtained using standard ND procedures. Using VRRP a backup router 265 can take over for a failed default router in around three seconds 266 (using VRRP default parameters). This is done with out any 267 interaction with the hosts and a minimum amount of VRRP traffic. 269 1.4. Requirements Language 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119]. 275 1.5. Scope 277 The remainder of this document describes the features, design goals, 278 and theory of operation of VRRP. The message formats, protocol 279 processing rules and state machine that guarantee convergence to a 280 single Virtual Router Master are presented. Finally, operational 281 issues related to MAC address mapping, handling of ARP requests, 282 generation of ICMP redirect messages, and security issues are 283 addressed. 285 1.6. Definitions 287 VRRP Router A router running the Virtual Router 288 Redundancy Protocol. It may participate in 289 one or more virtual routers. 291 Virtual Router An abstract object managed by VRRP that acts 292 as a default router for hosts on a shared 293 LAN. It consists of a Virtual Router 294 Identifier and either a set of associated 295 IPv4 addresses or a set of associated IPv6 296 addresses across a common LAN. A VRRP Router 297 may backup one or more virtual routers. 299 IP Address Owner The VRRP router that has the virtual router's 300 IPvX address(es) as real interface 301 address(es). This is the router that, when 302 up, will respond to packets addressed to one 303 of these IPvX addresses for ICMP pings, TCP 304 connections, etc. 306 Primary IP Address In IPv4, an IPv4 address selected from the 307 set of real interface addresses. One 308 possible selection algorithm is to always 309 select the first address. In IPv4 mode, VRRP 310 advertisements are always sent using the 311 primary IPv4 address as the source of the 312 IPv4 packet. In IPv6, the link-local 313 addresses of the interface over which the 314 packet is transmitted is used. 316 Virtual Router Master The VRRP router that is assuming the 317 responsibility of forwarding packets sent to 318 the IPvX address(es) associated with the 319 virtual router, and answering ARP requests 320 for these IPv4 address(es) or and answering 321 ND requests for these IPv6 address(es). Note 322 that if the IPvX address owner is available, 323 then it will always become the Master. 325 Virtual Router Backup The set of VRRP routers available to assume 326 forwarding responsibility for a virtual 327 router should the current Master fail. 329 2. Required Features 331 This section outlines the set of features that were considered 332 mandatory and that guided the design of VRRP. 334 2.1. IPvX Address Backup 336 Backup of an IPvX address(es) is the primary function of the Virtual 337 Router Redundancy Protocol. While providing election of a Virtual 338 Router Master and the additional functionality described below, the 339 protocol should strive to: 341 o Minimize the duration of black holes. 343 o Minimize the steady state bandwidth overhead and processing 344 complexity. 346 o Function over a wide variety of multiaccess LAN technologies 347 capable of supporting IPvX traffic. 349 o Provide for election of multiple virtual routers on a network for 350 load balancing. 352 o Support of multiple logical IPvX subnets on a single LAN segment. 354 2.2. Preferred Path Indication 356 A simple model of Master election among a set of redundant routers is 357 to treat each router with equal preference and claim victory after 358 converging to any router as Master. However, there are likely to be 359 many environments where there is a distinct preference (or range of 360 preferences) among the set of redundant routers. For example, this 361 preference may be based upon access link cost or speed, router 362 performance or reliability, or other policy considerations. The 363 protocol should allow the expression of this relative path preference 364 in an intuitive manner, and guarantee Master convergence to the most 365 preferential router currently available. 367 2.3. Minimization of Unnecessary Service Disruptions 369 Once Master election has been performed then any unnecessary 370 transitions between Master and Backup routers can result in a 371 disruption in service. The protocol should ensure after Master 372 election that no state transition is triggered by any Backup router 373 of equal or lower preference as long as the Master continues to 374 function properly. 376 Some environments may find it beneficial to avoid the state 377 transition triggered when a router becomes available that is 378 preferred over the current Master. It may be useful to support an 379 override of the immediate convergence to the preferred path. 381 2.4. Efficient Operation over Extended LANs 383 Sending either IPvX packets on a multiaccess LAN requires mapping 384 from an IPvX address to a MAC address. The use of the virtual router 385 MAC address in an extended LAN employing learning bridges can have a 386 significant effect on the bandwidth overhead of packets sent to the 387 virtual router. If the virtual router MAC address is never used as 388 the source address in a link level frame then the station location is 389 never learned, resulting in flooding of all packets sent to the 390 virtual router. To improve the efficiency in this environment the 391 protocol should: 1) use the virtual router MAC as the source in a 392 packet sent by the Master to trigger station learning; 2) trigger a 393 message immediately after transitioning to Master to update the 394 station learning; and 3) trigger periodic messages from the Master to 395 maintain the station learning cache. 397 2.5. Sub-second Operation for IPv4 and IPv6 399 Sub-second detection of Master VRRP router failure is needed in both 400 IPv4 and IPv6 environments. In [I-D.ietf-vrrp-ipv6-spec], sub-second 401 operation was defined for IPv6; this specification extends that 402 support for IPv4. 404 3. VRRP Overview 406 VRRP specifies an election protocol to provide the virtual router 407 function described earlier. All protocol messaging is performed 408 using either IPv4 or IPv6 multicast datagrams, thus the protocol can 409 operate over a variety of multiaccess LAN technologies supporting 410 IPvX multicast. Each VRRP virtual router has a single well-known MAC 411 address allocated to it. This document currently only details the 412 mapping to networks using the IEEE 802 48-bit MAC address. The 413 virtual router MAC address is used as the source in all periodic VRRP 414 messages sent by the Master router to enable bridge learning in an 415 extended LAN. 417 A virtual router is defined by its virtual router identifier (VRID) 418 and a set of either IPv4 or IPv6 address(es). A VRRP router may 419 associate a virtual router with its real address on an interface, and 420 may also be configured with additional virtual router mappings and 421 priority for virtual routers it is willing to backup. The mapping 422 between VRID and its IPvX address(es) must be coordinated among all 423 VRRP routers on a LAN. However, there is no restriction against 424 reusing a VRID with a different address mapping on different LANs. 425 The scope of each virtual router is restricted to a single LAN. Note 426 that there is no restriction against using the same group number for 427 a set of IPv4 addresses and a set of IPv6 addresses; however, these 428 are two different VRRP groups. 430 To minimize network traffic, only the Master for each virtual router 431 sends periodic VRRP Advertisement messages. A Backup router will not 432 attempt to preempt the Master unless it has higher priority. This 433 eliminates service disruption unless a more preferred path becomes 434 available. It's also possible to administratively prohibit all 435 preemption attempts. The only exception is that a VRRP router will 436 always become Master of any virtual router associated with addresses 437 it owns. If the Master becomes unavailable then the highest priority 438 Backup will transition to Master after a short delay, providing a 439 controlled transition of the virtual router responsibility with 440 minimal service interruption. 442 The VRRP protocol design provides rapid transition from Backup to 443 Master to minimize service interruption, and incorporates 444 optimizations that reduce protocol complexity while guaranteeing 445 controlled Master transition for typical operational scenarios. The 446 optimizations result in an election protocol with minimal runtime 447 state requirements, minimal active protocol states, and a single 448 message type and sender. The typical operational scenarios are 449 defined to be two redundant routers and/or distinct path preferences 450 among each router. A side effect when these assumptions are violated 451 (i.e., more than two redundant paths all with equal preference) is 452 that duplicate packets may be forwarded for a brief period during 453 Master election. However, the typical scenario assumptions are 454 likely to cover the vast majority of deployments, loss of the Master 455 router is infrequent, and the expected duration in Master election 456 convergence is quite small ( << 1 second ). Thus the VRRP 457 optimizations represent significant simplifications in the protocol 458 design while incurring an insignificant probability of brief network 459 degradation. 461 4. Sample Configurations 463 4.1. Sample Configuration 1 465 The following figure shows a simple network with two VRRP routers 466 implementing one virtual router. 468 +-----------+ +-----------+ 469 | Rtr1 | | Rtr2 | 470 |(MR VRID=1)| |(BR VRID=1)| 471 | | | | 472 VRID=1 +-----------+ +-----------+ 473 IPvX A--------->* *<---------IPvX B 474 | | 475 | | 476 ------------------+------------+-----+--------+--------+--------+-- 477 ^ ^ ^ ^ 478 | | | | 479 (IPvX A) (IPvX A) (IPvX A) (IPvX A) 480 | | | | 481 +--+--+ +--+--+ +--+--+ +--+--+ 482 | H1 | | H2 | | H3 | | H4 | 483 +-----+ +-----+ +--+--+ +--+--+ 484 Legend: 485 --+---+---+-- = Ethernet, Token Ring, or FDDI 486 H = Host computer 487 MR = Master Router 488 BR = Backup Router 489 * = IPvX Address, X is 4 everywhere in IPv4 case 490 X is 6 everywhere in IPv6 case 491 (IPvX) = default router for hosts 493 Eliminating all mention of VRRP (VRID=1) from the figure above leaves 494 it as a typical deployment. 496 In the IPv4 case (that is, IPvX is IPv4 everywhere in the figure), 497 each router is permanently assigned an IPv4 address on the LAN 498 interface (Rtr1 is assigned IPv4 A and Rtr2 is assigned IPv4 B), and 499 each host installs a static default route through one of the routers 500 (in this example they all use Rtr1's IPv4 A). 502 In the IPv6 case,(that is, IPvX is IPv6 everywhere in the figure), 503 each router has a link-local IPv6 address on the LAN interface (Rtr1 504 is assigned IPv6 Link-Local A and Rtr2 is assigned IPv6 Link-Local 505 B), and each host learns a default route from Router Advertisements 506 through one of the routers (in this example they all use Rtr1's IPv6 507 Link-Local A). 509 Moving to an IPv4 VRRP environment, each router has the exact same 510 permanently assigned IPv4 address. Rtr1 is said to be the IPv4 511 address owner of IPv4 A, and Rtr2 is the IP address owner of IPv4 B. 512 A virtual router is then defined by associating a unique identifier 513 (the virtual router ID) with the address owned by a router. 515 Moving to an IPv6 VRRP environment, each router has the exact same 516 Link-Local IPv6 address. Rtr1 is said to be the IPv6 address owner 517 of IPv6 A, and Rtr2 is the IPv6 address owner of IPv6 B. A virtual 518 router is then defined by associating a unique identifier (the 519 virtual router ID) with the address owned by a router. 521 Finally, in both the IPv4 and IPv6 cases, the VRRP protocol manages 522 virtual router fail over to a backup router. 524 The IPv4 example above shows a virtual router configured to cover the 525 IPv4 address owned by Rtr1 (VRID=1,IPv4_Address=A). When VRRP is 526 enabled on Rtr1 for VRID=1 it will assert itself as Master, with 527 priority=255, since it is the IP address owner for the virtual router 528 IP address. When VRRP is enabled on Rtr2 for VRID=1 it will 529 transition to Backup, with priority=100 (the default priority is 100) 530 since it is not the IPv4 address owner. If Rtr1 should fail then the 531 VRRP protocol will transition Rtr2 to Master, temporarily taking over 532 forwarding responsibility for IPv4 A to provide uninterrupted service 533 to the hosts. 535 The IPv6 example above shows a virtual router configured to cover the 536 IPv6 address owned by Rtr1 (VRID=1,IPv6_Address=A). When VRRP is 537 enabled on Rtr1 for VRID=1 it will assert itself as Master, with 538 priority=255, since it is the IPv6 address owner for the virtual 539 router IPv6 address. When VRRP is enabled on Rtr2 for VRID=1 it will 540 transition to Backup, with priority=100 (the default priority is 100) 541 since it is not the IPv6 address owner. If Rtr1 should fail then the 542 VRRP protocol will transition Rtr2 to Master, temporarily taking over 543 forwarding responsibility for IPv6 A to provide uninterrupted service 544 to the hosts. 546 Note that in both cases, in this example IPvX B is not backed up, it 547 is only used by Rtr2 as its interface address. In order to backup 548 IPvX B, a second virtual router must be configured. This is shown in 549 the next section. 551 4.2. Sample Configuration 2 553 The following figure shows a configuration with two virtual routers 554 with the hosts splitting their traffic between them. 556 +-----------+ +-----------+ 557 | Rtr1 | | Rtr2 | 558 |(MR VRID=1)| |(BR VRID=1)| 559 |(BR VRID=2)| |(MR VRID=2)| 560 VRID=1 +-----------+ +-----------+ VRID=2 561 IPvX A -------->* *<---------- IPvX B 562 | | 563 | | 564 ------------------+------------+-----+--------+--------+--------+-- 565 ^ ^ ^ ^ 566 | | | | 567 (IPvX A) (IPvX A) (IPvX B) (IPvX B) 568 | | | | 569 +--+--+ +--+--+ +--+--+ +--+--+ 570 | H1 | | H2 | | H3 | | H4 | 571 +-----+ +-----+ +--+--+ +--+--+ 572 Legend: 573 ---+---+---+-- = Ethernet, Token Ring, or FDDI 574 H = Host computer 575 MR = Master Router 576 BR = Backup Router 577 * = IPvX Address, X is 4 everywhere in IPv4 case 578 X is 6 everywhere in IPv6 case 579 (IPvX) = default router for hosts 581 In the IPv4 example above (that is, IPvX is IPv4 everywhere in the 582 figure), half of the hosts have configured a static route through 583 Rtr1's IPv4 A and half are using Rtr2's IPv4 B. The configuration of 584 virtual router VRID=1 is exactly the same as in the first example 585 (see section 4.1), and a second virtual router has been added to 586 cover the IPv4 address owned by Rtr2 (VRID=2, IPv4_Address=B). In 587 this case Rtr2 will assert itself as Master for VRID=2 while Rtr1 588 will act as a backup. This scenario demonstrates a deployment 589 providing load splitting when both routers are available while 590 providing full redundancy for robustness. 592 In the IPv6 example above (that is, IPvX is IPv6 everywhere in the 593 figure),, half of the hosts have learned a default route through 594 Rtr1's IPv6 A and half are using Rtr2's IPv6 B. The configuration of 595 virtual router VRID=1 is exactly the same as in the first example 596 (see section 4.1), and a second virtual router has been added to 597 cover the IPv6 address owned by Rtr2 (VRID=2, IPv6_Address=B). In 598 this case Rtr2 will assert itself as Master for VRID=2 while Rtr1 599 will act as a backup. This scenario demonstrates a deployment 600 providing load splitting when both routers are available while 601 providing full redundancy for robustness. 603 5. Protocol 605 The purpose of the VRRP packet is to communicate to all VRRP routers 606 the priority and the state of the Master router associated with the 607 Virtual Router ID. 609 When VRRP is protecting an IPv4 address, VRRP packets are sent 610 encapsulated in IP packets. They are sent to the IPv4 multicast 611 address assigned to VRRP. 613 When VRRP is protecting an IPv6 address, VRRP packets are sent 614 encapsulated in IPv6 packets. They are sent to the IPv6 multicast 615 address assigned to VRRP. 617 5.1. VRRP Packet Format 619 This section defines the format of the VRRP packet and the relevant 620 fields in the IP header. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 |(rsvd) | Max Adver Int | Checksum | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | | 630 + + 631 | IPvX Address(es) | 632 + + 633 + + 634 + + 635 + + 636 | | 637 + + 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 5.1.1. IPv4 Field Descriptions 643 5.1.1.1. Source Address 645 The primary IPv4 address of the interface the packet is being sent 646 from. 648 5.1.1.2. Destination Address 650 The IPv4 multicast address as assigned by the IANA for VRRP is: 652 224.0.0.18 654 This is a link local scope multicast address. Routers MUST NOT 655 forward a datagram with this destination address regardless of its 656 TTL. 658 5.1.1.3. TTL 660 The TTL MUST be set to 255. A VRRP router receiving a packet with 661 the TTL not equal to 255 MUST discard the packet. 663 5.1.1.4. Protocol 665 The IPv4 protocol number assigned by the IANA for VRRP is 112 666 (decimal). 668 5.1.2. IPv6 Field Descriptions 670 5.1.2.1. Source Address 672 The IPv6 link-local address of the interface the packet is being sent 673 from. 675 5.1.2.2. Destination Address 677 The IPv6 multicast address as assigned by the IANA for VRRP is: 679 FF02:0:0:0:0:0:XXXX:XXXX 681 This is a link-local scope multicast address. Routers MUST NOT 682 forward a datagram with this destination address regardless of its 683 Hop Limit. 685 5.1.2.3. Hop Limit 687 The Hop Limit MUST be set to 255. A VRRP router receiving a packet 688 with the Hop Limit not equal to 255 MUST discard the packet. 690 5.1.2.4. Next Header 692 The IPv6 Next Header protocol assigned by the IANA for VRRP is 112 693 (decimal). 695 5.2. VRRP Field Descriptions 697 5.2.1. Version 699 The version field specifies the VRRP protocol version of this packet. 700 This document defines version 3. 702 5.2.2. Type 704 The type field specifies the type of this VRRP packet. The only 705 packet type defined in this version of the protocol is: 707 1 ADVERTISEMENT 709 A packet with unknown type MUST be discarded. 711 5.2.3. Virtual Rtr ID (VRID) 713 The Virtual Router Identifier (VRID) field identifies the virtual 714 router this packet is reporting status for. 716 5.2.4. Priority 718 The priority field specifies the sending VRRP router's priority for 719 the virtual router. Higher values equal higher priority. This field 720 is an 8 bit unsigned integer field. 722 The priority value for the VRRP router that owns the IPvX address 723 associated with the virtual router MUST be 255 (decimal). 725 VRRP routers backing up a virtual router MUST use priority values 726 between 1-254 (decimal). The default priority value for VRRP routers 727 backing up a virtual router is 100 (decimal). 729 The priority value zero (0) has special meaning indicating that the 730 current Master has stopped participating in VRRP. This is used to 731 trigger Backup routers to quickly transition to Master without having 732 to wait for the current Master to timeout. 734 5.2.5. Count IPvX Addr 736 The number of either IPv4 addresses or IPv6 addresses contained in 737 this VRRP advertisement. The minimum value is 1. 739 5.2.6. Rsvd 741 This field MUST be set to zero on transmission and ignored on 742 reception. 744 5.2.7. Maximum Advertisement Interval (Max Adver Int) 746 The Maximum Advertisement Interval is a 12-bit field that indicates 747 the time interval (in centiseconds) between ADVERTISEMENTS. The 748 default is 100 centiseconds (1 second). 750 Note that higher priority Master routers with slower transmission 751 rates than their Backup routers are unstable. This is because low 752 priority nodes configured to faster rates could come online and 753 decide they should be masters before they have heard anything from 754 the higher priority master with a slower rate. 756 5.2.8. Checksum 758 The checksum field is used to detect data corruption in the VRRP 759 message. 761 The checksum is the 16-bit one's complement of the one's complement 762 sum of the entire VRRP message starting with the version field and a 763 "pseudo-header" as defined in section 8.1 of [RFC2460]. The next 764 header field in the "pseudo-header" should be set to 112 (decimal) 765 for VRRP. For computing the checksum, the checksum field is set to 766 zero. See RFC1071 for more detail [RFC1071]. 768 5.2.9. IPvX Address(es) 770 One or more IPvX addresses associated associated with the virtual 771 router. The number of addresses included is specified in the "Count 772 IP Addr" field. These fields are used for troubleshooting 773 misconfigured routers. If more than one address is sent it is 774 recommended that all routers be configured to send these addresses in 775 the same order to make it easier to do this comparison. 777 For IPv4 addresses, one or more IPv4 addresses that are associated 778 with the virtual router. 780 For IPv6, the first address must be the IPv6 link-local address 781 associated with the virtual router. 783 This field contains either one or more IPv4 addresses or one or more 784 IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in 785 one IPvX Address field. 787 6. Protocol State Machine 788 6.1. Parameters per Virtual Router 790 VRID Virtual Router Identifier. Configurable item 791 in the range 1-255 (decimal). There is no 792 default. 794 Priority Priority value to be used by this VRRP router 795 in Master election for this virtual router. 796 The value of 255 (decimal) is reserved for 797 the router that owns the IPvX address 798 associated with the virtual router. The 799 value of 0 (zero) is reserved for Master 800 router to indicate it is releasing 801 responsibility for the virtual router. The 802 range 1-254 (decimal) is available for VRRP 803 routers backing up the virtual router. The 804 default value is 100 (decimal). 806 IPv4_Addresses One or more IPv4 addresses associated with 807 this virtual router. Configured item. No 808 default 810 IPv6_Addresses One or more IPv6 addresses associated with 811 this virtual router. Configured item. No 812 default. The first address must be the Link- 813 Local address associated with the virtual 814 router. 816 Advertisement_Interval Time interval between ADVERTISEMENTS 817 (centiseconds). Default is 100 centiseconds 818 (1 second). 820 Master_Adver_Interval Advertisement interval contained in 821 ADVERTISEMENTS received from the Master 822 (centiseconds). This value is saved by 823 virtual routers in Backup state and used to 824 compute Skew_Time and Master_Down_Interval. 825 The initial value is same as 826 Advertisement_Interval. 828 Skew_Time Time to skew Master_Down_Interval in 829 centiseconds. Calculated as: 831 (((256 - priority) * Master_Adver_Interval) / 832 256). 834 Master_Down_Interval Time interval for Backup to declare Master 835 down (centiseconds). Calculated as: 837 (3 * Master_Adver_Interval) + Skew_time 839 Preempt_Mode Controls whether a (starting or restarting) 840 higher priority Backup router preempts a 841 lower priority Master router. Values are 842 True to allow preemption and False to 843 prohibit preemption. Default is True. 845 Note: Exception is that the router that owns 846 the IPvX address associated with the virtual 847 router always preempts independent of the 848 setting of this flag. 850 Accept_Mode Controls whether a virtual router in Master 851 state will accept packets addressed to the 852 address owner's IPvX address as its own if it 853 is not the IPvX address owner. Default is 854 False. 856 6.2. Timers 858 Master_Down_Timer Timer that fires when ADVERTISEMENT has not 859 been heard for Master_Down_Interval. 861 Adver_Timer Timer that fires to trigger sending of 862 ADVERTISEMENT based on 863 Advertisement_Interval. 865 6.3. State Transition Diagram 867 +---------------+ 868 +--------->| |<-------------+ 869 | | Initialize | | 870 | +------| |----------+ | 871 | | +---------------+ | | 872 | | | | 873 | V V | 874 +---------------+ +---------------+ 875 | |---------------------->| | 876 | Master | | Backup | 877 | |<----------------------| | 878 +---------------+ +---------------+ 880 6.4. State Descriptions 882 In the state descriptions below, the state names are identified by 883 {state-name}, and the packets are identified by all upper case 884 characters. 886 A VRRP router implements an instance of the state machine for each 887 virtual router election it is participating in. 889 6.4.1. Initialize 891 The purpose of this state is to wait for a Startup event. 893 If a Startup event is received, then: 895 - If the Priority = 255 (i.e., the router owns the IPvX address 896 associated with the virtual router) then: 898 + Send an ADVERTISEMENT 900 + If the protected IPvX address is an IPv4 address: 902 * Broadcast a gratuitous ARP request containing the virtual 903 router MAC address for each IP address associated with the 904 virtual router. 906 + else // IPv6 908 * Send an unsolicited ND Neighbor Advertisement with the 909 Router Flag (R) set, the Solicited Flag (S) unset, the 910 Override flag (O) set, the Target Address set to the IPv6 911 link-local address of the Virtual Router, and the Target 912 Link Layer address set to the virtual router MAC address. 914 +endif // was prot addr IPv4? 916 + Set the Adver_Timer to Advertisement_Interval 918 + Transition to the {Master} state 920 - else // rtr does not own virt addr 922 + Set Master_Adver_Interval to Advertisement_Interval 924 + Set the Master_Down_Timer to Master_Down_Interval 926 + Transition to the {Backup} state 928 -endif // pri was not 255 930 endif // startup event was recv 932 6.4.2. Backup 934 The purpose of the {Backup} state is to monitor the availability and 935 state of the Master Router. 937 While in this state, a VRRP router MUST do the following: 939 - If the protected IPvX address is an IPv4 address: 941 + MUST NOT respond to ARP requests for the IPv4 address(s) 942 associated with the virtual router. 944 - else // prot addr is v6 946 + MUST NOT respond to ND Neighbor Solicitation messages for the 947 IPv6 address(es) associated with the virtual router. 949 + MUST NOT send ND Router Advertisement messages for the 950 virtual router. 952 -endif // was prot v4? 954 - MUST discard packets with a destination link layer MAC address 955 equal to the virtual router MAC address. 957 - MUST NOT accept packets addressed to the IPvX address(es) 958 associated with the virtual router. 960 - If a Shutdown event is received, then: 962 + Cancel the Master_Down_Timer 964 + Transition to the {Initialize} state 966 -endif // shutdown recv 968 - If the Master_Down_Timer fires, then: 970 + Send an ADVERTISEMENT 972 + If the protected IPvX address is an IPv4 address: 974 * Broadcast a gratuitous ARP request containing the virtual 975 router MAC address for each IPv4 address associated with the 976 virtual router 978 + else // ipv6 980 * Compute and join the Solicited-Node multicast address 981 [RFC4291] for the IPv6 address(es) addresses associated with 982 the Virtual Router. 984 * Send an unsolicited ND Neighbor Advertisement with the 985 Router Flag (R) set, the Solicited Flag (S) unset, the 986 Override flag (O) set, the Target Address set to the IPv6 987 link-local address of the Virtual Router, and the Target 988 Link Layer address set to the virtual router MAC address. 990 +endif // was prot addr ipv4? 992 + Set the Adver_Timer to Advertisement_Interval 994 + Transition to the {Master} state 996 -endif // master down fired 998 - If an ADVERTISEMENT is received, then: 1000 + If the Priority in the ADVERTISEMENT is Zero, then: 1002 * Set the Master_Down_Timer to Skew_Time 1004 + else // pri non-zero 1006 * If Preempt_Mode is False, or If the Priority in the 1007 ADVERTISEMENT is greater than or equal to the local 1008 Priority, then: 1010 @ Set Master_Adver_Interval to Adver Interval contained 1011 in the ADVERTISEMENT. 1013 @ Recompute the Master_Down_Interval 1015 @ Reset the Master_Down_Timer to Master_Down_Interval 1017 * else // preempt was true or pri was less 1019 @ Discard the ADVERTISEMENT 1021 *endif // preempt test 1023 +endif // was pri zero? 1025 -endif // was adv recv? 1027 endwhile // backup state 1029 6.4.3. Master 1031 While in the {Master} state the router functions as the forwarding 1032 router for the IPvX address(es) associated with the virtual router. 1034 Note that in the Master state the Preempt_Mode Flag is not 1035 considered. 1037 While in this state, a VRRP router MUST do the following: 1039 - If the protected IPvX address is an IPv4 address: 1041 + MUST respond to ARP requests for the IPv4 address(es) 1042 associated with the virtual router. 1044 - else // ipv6 1046 + MUST be a member of the Solicited-Node multicast address for 1047 the IPv6 address(es) associated with the virtual router. 1049 + MUST respond to ND Neighbor Solicitation message for the IPv6 1050 address(es) associated with the virtual router. 1052 + MUST send ND Router Advertisements for the virtual router. 1054 -endif // ipv4? 1056 - MUST forward packets with a destination link layer MAC address 1057 equal to the virtual router MAC address. 1059 - MUST accept packets addressed to the IPvX address(es) associated 1060 with the virtual router if it is the IPvX address owner or if 1061 Accept_Mode is True. Otherwise, MUST NOT accept these packets. 1063 - If a Shutdown event is received, then: 1065 + Cancel the Adver_Timer 1067 + Send an ADVERTISEMENT with Priority = 0 1069 + Transition to the {Initialize} state 1071 -endif // shutdown recv 1073 - If the Adver_Timer fires, then: 1075 + Send an ADVERTISEMENT 1077 + Reset the Adver_Timer to Advertisement_Interval 1079 -endif // advert timer fired 1081 - If an ADVERTISEMENT is received, then: 1083 + If the Priority in the ADVERTISEMENT is Zero, then: 1085 * Send an ADVERTISEMENT 1087 * Reset the Adver_Timer to Advertisement_Interval 1089 + else // pri was nonzero 1091 * If the Priority in the ADVERTISEMENT is greater than the 1092 local Priority, 1094 * or 1096 * If the Priority in the ADVERTISEMENT is equal to the local 1097 Priority and the primary IPvX Address of the sender is 1098 greater than the local primary IPvX Address, then: 1100 @ Cancel Adver_Timer 1102 @ Recompute the Master_Down_Interval 1104 @ Set Master_Down_Timer to Master_Down_Interval 1106 @ Transition to the {Backup} state 1108 * else // new master logic 1110 @ Discard ADVERTISEMENT 1112 *endif // new master detected 1114 +endif // was pri zero? 1116 -endif // advert recvd 1118 endwhile // in master 1120 7. Sending and Receiving VRRP Packets 1122 7.1. Receiving VRRP Packets 1124 Performed the following functions when a VRRP packet is received: 1126 - If the received packet is an IPv4 packet: 1128 + MUST verify that the IPv4 TTL is 255. 1130 - else // ipv6 recv 1132 + MUST verify that the IPv6 Hop Limit is 255. 1134 - endif 1136 - MUST verify the VRRP version is 3 1138 - MUST verify that the received packet contains the complete VRRP 1139 packet (including fixed fields, and IPvX Address. 1141 - MUST verify the VRRP checksum 1143 - MUST verify that the VRID is configured on the receiving 1144 interface and the local router is not the IPvX Address owner 1145 (Priority equals 255 (decimal)). 1147 If any one of the above checks fails, the receiver MUST discard the 1148 packet, SHOULD log the event and MAY indicate via network management 1149 that an error occurred. 1151 - MAY verify that "Count IPvX Addrs" and the list of IPvX Address 1152 matches the IPvX Address(es) configured for the VRID 1154 If the above check fails, the receiver SHOULD log the event and MAY 1155 indicate via network management that a misconfiguration was detected. 1156 If the packet was not generated by the address owner (Priority does 1157 not equal 255 (decimal)), the receiver MUST drop the packet, 1158 otherwise continue processing. 1160 7.2. Transmitting VRRP Packets 1162 The following operations MUST be performed when transmitting a VRRP 1163 packet. 1165 - Fill in the VRRP packet fields with the appropriate virtual 1166 router configuration state 1168 - Compute the VRRP checksum 1170 - If the protected address is an IPv4 address: 1172 + Set the source MAC address to Virtual Router MAC Address 1174 + Set the source IPv4 address to interface primary IPv4 address 1176 - else // ipv6 1178 + Set the source MAC address to Virtual Router MAC Address 1180 + Set the source IPv6 address to interface link-local IPv6 1181 address 1183 - endif 1185 - Set the IPvX protocol to VRRP 1187 - Send the VRRP packet to the VRRP IPvX multicast group 1189 Note: VRRP packets are transmitted with the virtual router MAC 1190 address as the source MAC address to ensure that learning bridges 1191 correctly determine the LAN segment the virtual router is attached 1192 to. 1194 7.3. Virtual Router MAC Address 1196 The virtual router MAC address associated with a virtual router is an 1197 IEEE 802 MAC Address in the following format: 1199 IPv4 case: 00-00-5E-00-01-{VRID} (in hex in internet standard bit- 1200 order) 1202 The first three octets are derived from the IANA's OUI. The next two 1203 octets (00-01) indicate the address block assigned to the VRRP for 1204 IPv4 protocol. {VRID} is the VRRP Virtual Router Identifier. This 1205 mapping provides for up to 255 IPv4 VRRP routers on a network. 1207 IPv6 case: 00-00-5E-00-02-{VRID} (in hex in internet standard bit- 1208 order) 1210 The first three octets are derived from the IANA's OUI. The next two 1211 octets (00-02) indicate the address block assigned to the VRRP for 1212 IPv6 protocol. {VRID} is the VRRP Virtual Router Identifier. This 1213 mapping provides for up to 255 IPv6 VRRP routers on a network. 1215 7.4. IPv6 Interface Identifiers 1217 IPv6 Routers running VRRP MUST create their Interface Identifiers in 1218 the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over 1219 Ethernet"). They MUST NOT use the Virtual Router MAC address to 1220 create the Modified EUI-64 identifiers. 1222 This VRRP specification describes how to advertise and resolve the 1223 VRRP routers IPv6 link local address and other associated IPv6 1224 addresses into the Virtual Router MAC address. 1226 8. Operational Issues 1228 8.1. IPv4 1230 8.1.1. ICMP Redirects 1232 ICMP Redirects may be used normally when VRRP is running between a 1233 group of routers. This allows VRRP to be used in environments where 1234 the topology is not symmetric. 1236 The IPv4 source address of an ICMP redirect should be the address the 1237 end host used when making its next hop routing decision. If a VRRP 1238 router is acting as Master for virtual router(s) containing addresses 1239 it does not own, then it must determine which virtual router the 1240 packet was sent to when selecting the redirect source address. One 1241 method to deduce the virtual router used is to examine the 1242 destination MAC address in the packet that triggered the redirect. 1244 It may be useful to disable Redirects for specific cases where VRRP 1245 is being used to load share traffic between a number of routers in a 1246 symmetric topology. 1248 8.1.2. Host ARP Requests 1250 When a host sends an ARP request for one of the virtual router IPv4 1251 addresses, the Master virtual router MUST respond to the ARP request 1252 with the virtual MAC address for the virtual router. The Master 1253 virtual router MUST NOT respond with its physical MAC address. This 1254 allows the client to always use the same MAC address regardless of 1255 the current Master router. 1257 When a VRRP router restarts or boots, it SHOULD not send any ARP 1258 messages with its physical MAC address for the IPv4 address it owns, 1259 it should only send ARP messages that include Virtual MAC addresses. 1260 This may entail: 1262 o When configuring an interface, VRRP routers should broadcast a 1263 gratuitous ARP request containing the virtual router MAC address 1264 for each IPv4 address on that interface. 1266 o At system boot, when initializing interfaces for VRRP operation; 1267 delay gratuitous ARP requests and ARP responses until both the 1268 IPv4 address and the virtual router MAC address are configured. 1270 8.1.3. Proxy ARP 1272 If Proxy ARP is to be used on a VRRP router, then the VRRP router 1273 must advertise the Virtual Router MAC address in the Proxy ARP 1274 message. Doing otherwise could cause hosts to learn the real MAC 1275 address of the VRRP router. 1277 8.2. IPv6 1279 8.2.1. ICMPv6 Redirects 1281 ICMPv6 Redirects may be used normally when VRRP is running between a 1282 group of routers [RFC4443]. This allows VRRP to be used in 1283 environments where the topology is not symmetric (e.g., the VRRP 1284 routers do not connect to the same destinations). 1286 The IPv6 source address of an ICMPv6 redirect should be the address 1287 the end host used when making its next hop routing decision. If a 1288 VRRP router is acting as Master for virtual router(s) containing 1289 addresses it does not own, then it must determine which virtual 1290 router the packet was sent to when selecting the redirect source 1291 address. A method to deduce the virtual router used is to examine 1292 the destination MAC address in the packet that triggered the 1293 redirect. 1295 8.2.2. ND Neighbor Solicitation 1297 When a host sends an ND Neighbor Solicitation message for the virtual 1298 router IPv6 address, the Master virtual router MUST respond to the ND 1299 Neighbor Solicitation message with the virtual MAC address for the 1300 virtual router. The Master virtual router MUST NOT respond with its 1301 physical MAC address. This allows the client to always use the same 1302 MAC address regardless of the current Master router. 1304 When a Master virtual router sends an ND Neighbor Solicitation 1305 message for a host's IPv6 address, the Master virtual router MUST 1306 include the virtual MAC address for the virtual router if it sends a 1307 source link-layer address option in the neighbor solicitation 1308 message. It MUST NOT use its physical MAC address in the source 1309 link-layer address option. 1311 When a VRRP router restarts or boots, it SHOULD not send any ND 1312 messages with its physical MAC address for the IPv6 address it owns, 1313 it should only send ND messages that include Virtual MAC addresses. 1314 This may entail: 1316 o When configuring an interface, VRRP routers should send an 1317 unsolicited ND Neighbor Advertisement message containing the 1318 virtual router MAC address for the IPv6 address on that interface. 1320 o At system boot, when initializing interfaces for VRRP operation; 1321 delay all ND Router and Neighbor Advertisements and Solicitation 1322 messages until both the IPv6 address and the virtual router MAC 1323 address are configured. 1325 Note that on a restarting Master router where the VRRP protected 1326 address is the interface address, (that is, priority 255) duplicate 1327 address detection (DAD) may fail, as the Backup router may answer 1328 that it owns the address. One solution is to not run DAD in this 1329 case.( 1331 8.2.3. Router Advertisements 1333 When a backup VRRP router has become Master for a virtual router, it 1334 is responsible for sending Router Advertisements for the virtual 1335 router as specified in section 6.4.3. The backup routers must be 1336 configured to send the same Router Advertisement options as the 1337 address owner. 1339 Router Advertisement options that advertise special services (e.g., 1340 Home Agent Information Option) that are present in the address owner, 1341 should not be sent by the address owner unless the backup routers are 1342 prepared to assume these services in full and have a complete and 1343 synchronized database for this service. 1345 8.3. IPvX 1347 8.3.1. Potential Forwarding Loop 1349 A VRRP router SHOULD not forward packets addressed to the IPvX 1350 Address it becomes Master for if it is not the owner. Forwarding 1351 these packets would result in unnecessary traffic. Also in the case 1352 of LANs that receive packets they transmit (e.g., token ring) this 1353 can result in a forwarding loop that is only terminated when the IPvX 1354 TTL expires. 1356 One such mechanism for VRRP routers is to add/delete a reject host 1357 route for each adopted IPvX address when transitioning to/from MASTER 1358 state. 1360 8.3.2. Recommendations regarding setting priority values 1362 A priority value of 255 designates a particular router as the "IPvX 1363 address owner". Care must be taken not to configure more than one 1364 router on the link in this way for a single VRID. 1366 Routers with priority 255 will, as soon as they start up, preempt all 1367 lower priority routers. Configure no more than one router on the 1368 link with priority 255, especially if preemption is set. If no 1369 router has this priority, and preemption is disabled, then no 1370 preemption will occur. 1372 When there are multiple Backup routers, their priority values should 1373 be uniformly distributed. For example, if one Backup routers has the 1374 default priority of 100 and another BR is added, a priority of 50 1375 would be a better choice for it than 99 or 100 to facilitate faster 1376 convergence. 1378 9. Operation over FDDI, Token Ring, and ATM LANE 1380 9.1. Operation over FDDI 1382 FDDI interfaces remove from the FDDI ring frames that have a source 1383 MAC address matching the device's hardware address. Under some 1384 conditions, such as router isolations, ring failures, protocol 1385 transitions, etc., VRRP may cause there to be more than one Master 1386 router. If a Master router installs the virtual router MAC address 1387 as the hardware address on a FDDI device, then other Masters' 1388 ADVERTISEMENTS will be removed from the ring during the Master 1389 convergence, and convergence will fail. 1391 To avoid this an implementation SHOULD configure the virtual router 1392 MAC address by adding a unicast MAC filter in the FDDI device, rather 1393 than changing its hardware MAC address. This will prevent a Master 1394 router from removing any ADVERTISEMENTS it did not originate. 1396 9.2. Operation over Token Ring 1398 Token ring has several characteristics that make running VRRP 1399 difficult. These include: 1401 o In order to switch to a new master located on a different bridge 1402 token ring segment from the previous master when using source 1403 route bridges, a mechanism is required to update cached source 1404 route information. 1406 o No general multicast mechanism supported across old and new token 1407 ring adapter implementations. While many newer token ring 1408 adapters support group addresses, token ring functional address 1409 support is the only generally available multicast mechanism. Due 1410 to the limited number of token ring functional addresses these may 1411 collide with other usage of the same token ring functional 1412 addresses. 1414 Due to these difficulties, the preferred mode of operation over token 1415 ring will be to use a token ring functional address for the VRID 1416 virtual MAC address. Token ring functional addresses have the two 1417 high order bits in the first MAC address octet set to B'1'. They 1418 range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format). 1419 However, unlike multicast addresses, there is only one unique 1420 functional address per bit position. The functional addresses 1421 addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by 1422 the Token Ring Architecture [TKARCH] for user-defined applications. 1423 However, since there are only 12 user-defined token ring functional 1424 addresses, there may be other non-IPvX protocols using the same 1425 functional address. Since the Novell IPX [IPX] protocol uses the 03- 1426 00-00-10-00-00 functional address, operation of VRRP over token ring 1427 will avoid use of this functional address. In general, token ring 1428 VRRP users will be responsible for resolution of other user-defined 1429 token ring functional address conflicts. 1431 VRIDs are mapped directly to token ring functional addresses. In 1432 order to decrease the likelihood of functional address conflicts, 1433 allocation will begin with the largest functional address. Most non- 1434 IPvX protocols use the first or first couple user-defined functional 1435 addresses and it is expected that VRRP users will choose VRIDs 1436 sequentially starting with 1. 1438 VRID Token Ring Functional Address 1439 ---- ----------------------------- 1440 1 03-00-02-00-00-00 1441 2 03-00-04-00-00-00 1442 3 03-00-08-00-00-00 1443 4 03-00-10-00-00-00 1444 5 03-00-20-00-00-00 1445 6 03-00-40-00-00-00 1446 7 03-00-80-00-00-00 1447 8 03-00-00-01-00-00 1448 9 03-00-00-02-00-00 1449 10 03-00-00-04-00-00 1450 11 03-00-00-08-00-00 1452 Or more succinctly, octets 3 and 4 of the functional address are 1453 equal to (0x4000 >> (VRID - 1)) in non-canonical format. 1455 Since a functional address cannot be used as a MAC level source 1456 address, the real MAC address is used as the MAC source address in 1457 VRRP advertisements. This is not a problem for bridges since packets 1458 addressed to functional addresses will be sent on the spanning-tree 1459 explorer path [ISO.10038.1993]. 1461 The functional address mode of operation MUST be implemented by 1462 routers supporting VRRP on token ring. 1464 Additionally, routers MAY support unicast mode of operation to take 1465 advantage of newer token ring adapter implementations that support 1466 non-promiscuous reception for multiple unicast MAC addresses and to 1467 avoid both the multicast traffic and usage conflicts associated with 1468 the use of token ring functional addresses. Unicast mode uses the 1469 same mapping of VRIDs to virtual MAC addresses as Ethernet. However, 1470 one important difference exists. ND request/reply packets contain 1471 the virtual MAC address as the source MAC address. The reason for 1472 this is that some token ring driver implementations keep a cache of 1473 MAC address/source routing information independent of the ND cache. 1474 Hence, these implementations need have to receive a packet with the 1475 virtual MAC address as the source address in order to transmit to 1476 that MAC address in a source-route bridged network. 1478 Unicast mode on token ring has one limitation that should be 1479 considered. If there are VRID routers on different source-route 1480 bridge segments and there are host implementations that keep their 1481 source-route information in the ND cache and do not listen to 1482 gratuitous NDs, these hosts will not update their ND source-route 1483 information correctly when a switch-over occurs. The only possible 1484 solution is to put all routers with the same VRID on the same source- 1485 bridge segment and use techniques to prevent that bridge segment from 1486 being a single point of failure. These techniques are beyond the 1487 scope this document. 1489 For both the multicast and unicast mode of operation, VRRP 1490 advertisements sent to 224.0.0.18 should be encapsulated as described 1491 in [RFC1469]. 1493 9.3. Operation over ATM LANE 1495 Operation of VRRP over ATM LANE on routers with ATM LANE interfaces 1496 and/or routers behind proxy LEC's are beyond the scope of this 1497 document. 1499 10. Security Considerations 1501 VRRP for IPvX does not currently include any type of authentication. 1502 Earlier versions of the VRRP (for IPv4) specification included 1503 several types of authentication ranging from none to strong. 1504 Operational experience and further analysis determined that these did 1505 not provide sufficient security to overcome the vulnerability of 1506 misconfigured secrets causing multiple masters to be elected. Due to 1507 the nature of the VRRP protocol, even if VRRP messages are 1508 cryptographically protected, it does not prevent hostile routers from 1509 behaving as if they are a VRRP master, creating multiple masters. 1510 Authentication of VRRP messages could have prevented a hostile router 1511 from causing all properly functioning routers from going into backup 1512 state. However, having multiple masters can cause as much disruption 1513 as no routers, which authentication cannot prevent. Also, even if a 1514 hostile router could not disrupt VRRP, it can disrupt ARP and create 1515 the same effect as having all routers go into backup. 1517 It should be noted that these attacks are not worse and are a subset 1518 of the attacks that any node attached to a LAN can do independently 1519 of VRRP. The kind of attacks a malicious node on a LAN can do 1520 include promiscuously receiving packets for any router's MAC address, 1521 sending packets with the router's MAC address as the source MAC 1522 addresses in the L2 header to tell the L2 switches to send packets 1523 addressed to the router to the malicious node instead of the router, 1524 send redirects to tell the hosts to send their traffic somewhere 1525 else, send unsolicited ND replies, answer ND requests, etc., etc. 1526 All of this can be done independently of implementing VRRP. VRRP 1527 does not add to these vulnerabilities. 1529 Independent of any authentication type VRRP includes a mechanism 1530 (setting TTL=255, checking on receipt) that protects against VRRP 1531 packets being injected from another remote network. This limits most 1532 vulnerabilities to local attacks. 1534 VRRP does not provide any confidentiality. Confidentiality is not 1535 necessary for the correct operation of VRRP and there is no 1536 information in the VRRP messages that must be kept secret from other 1537 nodes on the LAN. 1539 In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) 1540 [RFC3791] is deployed, VRRP authentication could be usefully added, 1541 because misconfiguration of secrets will not be an issue. Routers 1542 with different secrets will have different IPv6 addresses, and 1543 therefore there will be no issue with multiple masters with the same 1544 IPv6 (and MAC) addresses. Also, SEND will prevent malicious routers 1545 from sending misleading ND messages. 1547 11. Intellectual Property Rights Claimed 1549 The IETF has been notified of intellectual property rights claimed in 1550 regard to some or all of the specification contained in this 1551 document. For more information consult the online list of claimed 1552 rights. 1554 12. Contributors & Acknowledgments 1556 The author would like to thank V. Ullanatt for his review of an early 1557 version. This draft consists of very little new material (there is 1558 some new text in appendix A) and was created by merging and "xml- 1559 izing" the [I-D.ietf-vrrp-ipv6-spec] and [RFC3768] and then adding in 1560 the changes discussed recently on the mailing list. R. Hinden is the 1561 author and J. Cruz is the editor of the former. The contributors for 1562 the latter appear below. 1564 The IPv6 text in this specification is based on [RFC2338]. The 1565 authors of RFC2338 are S. Knight, D. Weaver, D. Whipple, R. Hinden, 1566 D. Mitzel, P. Hunt, P. Higginson, M. Shand, and A. Lindem. 1568 The author of [I-D.ietf-vrrp-ipv6-spec] would also like to thank Erik 1569 Nordmark, Thomas Narten, Steve Deering, Radia Perlman, Danny Mitzel, 1570 Mukesh Gupta, Don Provan, Mark Hollinger, John Cruz, and Melissa 1571 Johnson for their helpful suggestions. 1573 The IPv4 text in this specification is based on RFC3768. The authors 1574 of that specification would like to thank Glen Zorn, and Michael 1575 Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel 1576 Halpern, Steve Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, 1577 Radia Perlman, Russ Housley, Harald Alvestrand, Steve Bellovin, Ned 1578 Freed, Ted Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex 1579 Zinin for their comments and suggestions. 1581 13. IANA Considerations 1583 VRRP for IPv6 needs an IPv6 link-local scope multicast address 1584 assigned by the IANA for this specification. The IPv6 multicast 1585 address should be of the following form: 1587 FF02:0:0:0:0:0:XXXX:XXXX 1589 The values assigned address should be entered into section 5.1.2.2. 1591 A convenient assignment of this link-local scope multicast would be: 1593 FF02:0:0:0:0:0:0:12 1595 as this would be consistent with the IPv4 assignment for VRRP. 1597 The IANA should also reserve a block of IANA Ethernet unicast 1598 addresses from: 1600 00-00-5E-00-02-00 to 00-00-5E-00-02-FF in hex 1602 for VRRP for IPv6. Similar assignments are documented in: 1604 http://www.iana.org/assignments/ethernet-numbers 1606 14. References 1608 14.1. Normative References 1610 [IPX] Novell Incorporated, "IPX Router Specification Version 1611 1.10", October 1992. 1613 [ISO.10038.1993] 1614 International Organization for Standardization, 1615 "Information technology - Telecommunications and 1616 information exchange between systems - Local area networks 1617 - Media access control (MAC) bridges", ISO Standard 10038, 1618 1993. 1620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1621 Requirement Levels", BCP 14, RFC 2119, March 1997. 1623 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1624 (IPv6) Specification", RFC 2460, December 1998. 1626 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1627 Discovery for IP Version 6 (IPv6)", RFC 2461, 1628 December 1998. 1630 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1631 RFC 3768, April 2004. 1633 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1634 Architecture", RFC 4291, February 2006. 1636 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1637 Message Protocol (ICMPv6) for the Internet Protocol 1638 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1640 [TKARCH] IBM Incorporated, "IBM Token-Ring Network, Architecture 1641 Specificaton, Publication SC30-3374-02, Third Edition", 1642 September 1989. 1644 14.2. Informative References 1646 [I-D.ietf-vrrp-ipv6-spec] 1647 Hinden, R. and J. Cruz, "Virtual Router Redundancy 1648 Protocol for IPv6", draft-ietf-vrrp-ipv6-spec-08 (work in 1649 progress), March 2007. 1651 [IPSTB] Higginson, P. and M. Shand, "Development of Router 1652 Clusters to Provide Fast Failover in IP Networks", Digital 1653 Technology Journal, Volume 9 Number 3, Winter 1997. 1655 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1656 "Computing the Internet checksum", RFC 1071, 1657 September 1988. 1659 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1660 September 1991. 1662 [RFC1469] Pusateri, T., "IP Multicast over Token-Ring Local Area 1663 Networks", RFC 1469, June 1993. 1665 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1666 RFC 2131, March 1997. 1668 [RFC2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot 1669 Standby Router Protocol (HSRP)", RFC 2281, March 1998. 1671 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1673 [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, 1674 D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, 1675 "Virtual Router Redundancy Protocol", RFC 2338, 1676 April 1998. 1678 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1679 November 1998. 1681 [RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in 1682 Currently Deployed IETF Routing Area Standards Track and 1683 Experimental Documents", RFC 3791, June 2004. 1685 Appendix A. VRRPv3 and VRRPv2 Interoperation 1687 A.1. Assumptions 1689 1. VRRPv2 and VRRPv3 interoperation is optional. 1691 2. Mixing VRRPv2 and VRRPv3 should only be done when > transitioning 1692 from VRRPv2 to VRRPv3. Mixing the two versions should > not be 1693 considered a permanent solution. 1695 A.2. VRRPv3 support of VRRPv2 1697 As mentioned above, this support is intended for upgrade scenarions 1698 and NOT recommended for permanent deployments. 1700 An implementation MAY implement a configuration flag that tells it to 1701 listen for and send both VRRPv2 and VRRPv3 advertisements. 1703 When configured this way and the Master, it MUST send both types at 1704 the configured rate, even if sub-second. 1706 When configured this way and the Backup, it should time out based on 1707 the rate advertised by the master; in the case of a VRRPv2 master 1708 this means it must translate the timeout value it receives (in 1709 seconds) into centi-seconds. Also, a backup should ignore VRRPv2 1710 advertisements from the current master if it is also receiving VRRPv3 1711 packets from it. It MAY report when a v3 master is *not* sending v2 1712 packets: that suggests they don't agree on whether they're supporting 1713 v2 routers. 1715 A.3. VRRPv3 support of VRRPv2 Considerations 1717 A.3.1. Slow, High-Priority Masters 1719 See also discussion at "Maximum Advertisement Interval (Max Adver 1720 Int)" 1722 The VRRPv2 Master router interacting with a sub-second VRRPv3 Backup 1723 router is the most important example of this. 1725 A VRRPv2 implementation should not be given a higher priority than a 1726 VRRPv2/VRRPv3 implementation it is interacting with if the VRRPv2/ 1727 VRRPv3 rate is subsecond. 1729 A.3.2. Overwhelming VRRPv2 Backups 1731 It seems possible that an VRRPv3 Master router sending at centi-sec 1732 rates could potentially overwhelm a VRRPv2 Backup router with 1733 potentially unclear results. 1735 In this upgrade case, a deployment should initially run the VRRPv3 1736 Master routers with lower frequencies (e.g., 100 centi-sec) until the 1737 VRRPv2 rtrs are upgraded. Then, once the deployment has convinced 1738 itself that VRRPv3 is working properly, the VRRPv2 support may be 1739 unconfigured then the desired sub-second rates configured. 1741 Appendix B. Changes from [I-D.ietf-vrrp-ipv6-spec] and [RFC3768] 1743 o This doc was based on [I-D.ietf-vrrp-ipv6-spec] with material from 1744 [RFC3768] added in for the IPv4 parts. In this process it was 1745 also moved to xml. 1747 o Rework Abstract, Intro paragraphs to describe unified approach and 1748 add editor's note. 1750 o Use "IPvX" when talking about both IPv4 and IPv6 (all over the 1751 doc). 1753 o Pull IPv4 Intro material into intro IPv4 section and make IPv6 1754 section 1756 o Add sub-second operation in required features 1758 o Modify sample configurations to refer to "IPvX" 1760 o Rename "Adver Int" to "Min Adver Int" in VRRP Packet format and 1761 use "IPvX" term 1763 o Add separate IPv4 and IPv6 field description sections 1765 o In state descriptions and sending and receiving VRRP packets 1766 sections, add pseudo code test for IPv4, then add actions from 1767 [RFC3768] and arrange the else branch to be the IPv6 actions. 1769 o Include both IPv4 and IPv6 VR MAC addrs 1771 o In operational issues, create IPv4, IPv6 and IPvX sections 1773 o rework contributors and acks section. 1775 o add appendix A to discuss optional VRRPv2 and VRRpv3 interop 1777 o add appendix B to track changes made 1779 o add a paragraph to the IPv6 operational issues to mention DAD when 1780 master owns IPv6 address (this was issue 1 in the some comments on 1781 -08 thread) 1783 o in various places, change IPv6 language to mention not only link- 1784 locals but any other IPv6 protected addresses as well. (this was 1785 issue 4 in the some comments on -08 thread) 1787 o add appendix C to track remaining todos 1789 Appendix C. TBDs 1791 o issue 2 in the some comments on -08 thread: whether IPv6 router 1792 advertisements alone are enough to balance the host load. 1794 o issue 3 in the some comments on -08 thread: in IPv6 case, whether 1795 this should describe a mechanism to derive VRRP link local addrs 1796 (say using VRRP MAC) 1798 Appendix D. Changes from -00 version 1800 o idnits - 3791 inform not norm 1802 o idnits no xref of 2338 1804 o Steve Bates: (1) reword text in intro and abstract to remove "vrrp 1805 groups" language. 1807 o Steve Bates: (2) in 6.4.1 fix bad merge (from 3768 not -08 1809 o Steve Bates: (3) in 6.4.2 & 6.4.3 add bullet re recompute 1810 Master_Down_Interval 1812 o Steve Bates: (4) in section 7.1, remove check regard Advert 1813 Interval == local cfg'ed value 1815 o Steve Bates: (5) caught typo to vrrpv4 in Appendix 1 1817 o Steve Bates: 5.2.6 caught typo s/rvsd/rsvd/ 1819 o Don Provan: 4.1 & 4.2 remove sentences about "not expected to 1820 occur"[SJN6] 1822 o Don Provan: 5.2.7 s/Minimin/Maximum/ This also hits section 5.1 1823 [SJN4] 1825 o Don Provan: 8.1.1 s/One/A/ bcos there may be other methods tho 1826 none have come to mind as yet... [SJN7] 1828 o Don Provan: A.1 remove weak upgrade rationale [SJN8] 1830 o Don Provan: Move para describing slow master unstability to 1831 section "Maximim Advertisement Interval (Max Adver Int)" [SJN2] 1833 o Don Provan: add para to master to mention that Preempt_Mode Flag 1834 is not considered and in defn of "Preempt_Mode": clarified that it 1835 applies to backup router.[SJN5] 1837 Author's Address 1839 Stephen Nadas 1840 Ericsson 1841 920 Main Campus Dr., Suite 500 1842 Raleigh, NC 27606 1843 USA 1845 Phone: +1 919 472 9935 1846 Email: stephen.nadas@ericsson.com 1848 Full Copyright Statement 1850 Copyright (C) The IETF Trust (2007). 1852 This document is subject to the rights, licenses and restrictions 1853 contained in BCP 78, and except as set forth therein, the authors 1854 retain all their rights. 1856 This document and the information contained herein are provided on an 1857 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1858 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1859 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1860 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1861 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1862 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1864 Intellectual Property 1866 The IETF takes no position regarding the validity or scope of any 1867 Intellectual Property Rights or other rights that might be claimed to 1868 pertain to the implementation or use of the technology described in 1869 this document or the extent to which any license under such rights 1870 might or might not be available; nor does it represent that it has 1871 made any independent effort to identify any such rights. Information 1872 on the procedures with respect to rights in RFC documents can be 1873 found in BCP 78 and BCP 79. 1875 Copies of IPR disclosures made to the IETF Secretariat and any 1876 assurances of licenses to be made available, or the result of an 1877 attempt made to obtain a general license or permission for the use of 1878 such proprietary rights by implementers or users of this 1879 specification can be obtained from the IETF on-line IPR repository at 1880 http://www.ietf.org/ipr. 1882 The IETF invites any interested party to bring to its attention any 1883 copyrights, patents or patent applications, or other proprietary 1884 rights that may cover technology that may be required to implement 1885 this standard. Please address the information to the IETF at 1886 ietf-ipr@ietf.org. 1888 Acknowledgment 1890 Funding for the RFC Editor function is provided by the IETF 1891 Administrative Support Activity (IASA).