idnits 2.17.1 draft-ietf-vrrp-ipv6-spec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ND]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == 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: ---------------------------------------------------------------------------- == 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 IPv6 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 IPv6 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 (December 5, 2002) is 7806 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: 'RFC 2119' is mentioned on line 137, but not defined == Unused Reference: 'RIP' is defined on line 1264, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1273, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADD-ARH' ** Obsolete normative reference: RFC 2402 (ref. 'AUTH') (Obsoleted by RFC 4302, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 1071 (ref. 'CKSM') ** Downref: Normative reference to an Informational RFC: RFC 2281 (ref. 'HSRP') ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSTB' ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPX' ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Historic RFC: RFC 1469 -- Possible downref: Non-RFC (?) normative reference: ref. 'TKARCH' ** Obsolete normative reference: RFC 2338 (ref. 'VRRP-V4') (Obsoleted by RFC 3768) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden/Nokia 3 December 5, 2002 5 Virtual Router Redundancy Protocol for IPv6 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 This internet draft expires on June 5, 2003. 29 Abstract 31 This memo defines the Virtual Router Redundancy Protocol (VRRP) for 32 IPv6. It is version three (3) of the protocol. It is based on the 33 original version of VRRP (version 2) for IPv4 that is defined in 34 RFC2338. 36 VRRP specifies an election protocol that dynamically assigns 37 responsibility for a virtual router to one of the VRRP routers on a 38 LAN. The VRRP router controlling the IP address associated with a 39 virtual router is called the Master, and forwards packets sent to 40 this IP address. The election process provides dynamic fail over in 41 the forwarding responsibility should the Master become unavailable. 42 The advantage gained from using VRRP for IPv6 is a quicker switch 43 over to back up routers than can be obtained with standard IPv6 44 Neighbor Discovery [ND] mechanisms. 46 Table of Contents 48 1. Introduction................................................3 49 2. Required Features...........................................5 50 3. VRRP Overview...............................................6 51 4. Sample Configurations.......................................8 52 5. Protocol...................................................11 53 5.1 VRRP Packet Format....................................11 54 5.2 IP Field Descriptions.................................11 55 5.3 VRRP Field Descriptions...............................12 56 6. Protocol State Machine....................................15 57 6.1 Parameters per Virtual Router.........................15 58 6.2 Timers................................................16 59 6.3 State Transition Diagram..............................16 60 6.4 State Descriptions....................................16 61 7. Sending and Receiving VRRP Packets........................21 62 7.1 Receiving VRRP Packets................................21 63 7.2 Transmitting Packets..................................21 64 7.3 Virtual MAC Address...................................22 65 7.4 IPv6 Interface Identifiers............................22 66 8. Operational Issues........................................23 67 8.1 ICMPv6 Redirects......................................23 68 8.2 ND Neighbor Solicitation..............................23 69 8.3 Potential Forwarding Loop.............................24 70 9. Operation over FDDI, Token Ring, and ATM LANE.............24 71 9.1 Operation over FDDI...................................24 72 9.2 Operation over Token Ring.............................24 73 9.3 Operation over ATM LANE...............................25 74 10. Security Considerations...................................26 75 10.1 No Authentication....................................27 76 10.2 Simple Text Password.................................27 77 10.3 IP Authentication Header.............................28 78 11. Intellectual Property.....................................28 79 12. Acknowledgments...........................................29 80 13. IANA Considerations.......................................29 81 14. References................................................29 82 15. Authors' Address..........................................31 83 16. Changes from RFC2338......................................31 85 1. Introduction 87 IPv6 hosts on a LAN will usually learn about one or more default 88 routers by receiving Router Advertisements sent using the IPv6 89 Neighbor Discovery protocol [ND]. The Router Advertisements are 90 multicast periodically at a rate that the hosts will learn about the 91 default routers in a few minutes. They are not sent frequently enough 92 to rely on the absence of the router advertisement to detect router 93 failures. 95 Neighbor Discovery (ND) includes a mechanism called Neighbor 96 Unreachability Detection to detect the failure of a neighbor node 97 (router or host) or the forwarding path to a neighbor. This is done 98 by sending unicast ND Neighbor Solicitation messages to the neighbor 99 node. To reduce the overhead of sending Neighbor Solicitations, they 100 are only sent to neighbors to which the node is actively sending 101 traffic and only after there has been no positive indication that the 102 router is up for a period of time. Using the default parameters in 103 ND, it will take a host about 38 seconds to learn that a router is 104 unreachable before it will switch to another default router. This 105 delay would be very noticeable to users and cause some transport 106 protocol implementations to timeout. 108 While the ND unreachability detection could be speeded up by changing 109 the parameters to be more aggressive (note that the current lower 110 limit for this is 5 seconds), this would have the downside of 111 significantly increasing the overhead of ND traffic. Especially when 112 there are many hosts all trying to determine the reachability of a 113 one of more routers. 115 The Virtual Router Redundancy Protocol for IPv6 provides a much 116 faster switch over to an alternate default router than can be 117 obtained using standard ND procedures. Using VRRP a backup router 118 can take over for a failed default router in around three seconds 119 (using VRRP default parameters). This is done with out any 120 interaction with the hosts and a minimum amount of VRRP traffic. 122 VRRP specifies an election protocol that dynamically assigns 123 responsibility for a virtual router to one of the VRRP routers on a 124 LAN. The VRRP router controlling the IP address associated with a 125 virtual router is called the Master, and forwards packets sent to 126 this IP address. The election process provides dynamic fail over in 127 the forwarding responsibility should the Master become unavailable. 129 VRRP provides a function similar to a Cisco Systems, Inc. proprietary 130 protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a 131 Digital Equipment Corporation, Inc. proprietary protocol named IP 132 Standby Protocol [IPSTB]. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC 2119]. 138 The IESG/IETF take no position regarding the validity or scope of any 139 intellectual property right or other rights that might be claimed to 140 pertain to the implementation or use of the technology, or the extent 141 to which any license under such rights might or might not be 142 available. See the IETF IPR web page at http://www.ietf.org/ipr.html 143 for additional information. 145 1.1 Scope 147 The remainder of this document describes the features, design goals, 148 and theory of operation of VRRP for IPv6. The message formats, 149 protocol processing rules and state machine that guarantee 150 convergence to a single Virtual Router Master are presented. 151 Finally, operational issues related to MAC address mapping, handling 152 of Neighbor Discovery requests, generation of ICMPv6 redirect 153 messages, and security issues are addressed. 155 This protocol is intended for use with IPv6 routers only. VRRP for 156 IPv4 is defined in [VRRP-V4]. 158 1.2 Definitions 160 VRRP Router A router running the Virtual Router Redundancy 161 Protocol. It may participate in one or more 162 virtual routers. 164 Virtual Router An abstract object managed by VRRP that acts 165 as a default router for hosts on a shared LAN. 166 It consists of a Virtual Router Identifier and 167 an IPv6 address across a common LAN. A VRRP 168 Router may backup one or more virtual routers. 170 IPv6 Address Owner The VRRP router that has the virtual router's 171 IPv6 address as real interface address. This 172 is the router that, when up, will respond to 173 packets addressed to the IPv6 addresses for 174 ICMPv6 pings, TCP connections, etc. 176 Virtual Router Master The VRRP router that is assuming the 177 responsibility of forwarding packets sent to 178 the IPv6 address associated with the virtual 179 router, and answering ND requests for this 180 IPv6 address. Note that if the IPv6 address 181 owner is available, then it will always become 182 the Master. 184 Virtual Router Backup The set of VRRP routers available to assume 185 forwarding responsibility for a virtual router 186 should the current Master fail. 188 2.0 Required Features 190 This section outlines the set of features that were considered 191 mandatory and that guided the design of VRRP. 193 2.1 IPv6 Address Backup 195 Backup of an IPv6 address is the primary function of the Virtual 196 Router Redundancy Protocol. While providing election of a Virtual 197 Router Master and the additional functionality described below, the 198 protocol should strive to: 200 - Minimize the duration of black holes. 201 - Minimize the steady state bandwidth overhead and processing 202 complexity. 203 - Function over a wide variety of multiaccess LAN technologies 204 capable of supporting IPv6 traffic. 205 - Provide for election of multiple virtual routers on a network for 206 load balancing 207 - Support of multiple logical IPv6 subnets on a single LAN segment. 209 2.2 Preferred Path Indication 211 A simple model of Master election among a set of redundant routers is 212 to treat each router with equal preference and claim victory after 213 converging to any router as Master. However, there are likely to be 214 many environments where there is a distinct preference (or range of 215 preferences) among the set of redundant routers. For example, this 216 preference may be based upon access link cost or speed, router 217 performance or reliability, or other policy considerations. The 218 protocol should allow the expression of this relative path preference 219 in an intuitive manner, and guarantee Master convergence to the most 220 preferential router currently available. 222 2.3 Minimization of Unnecessary Service Disruptions 224 Once Master election has been performed then any unnecessary 225 transitions between Master and Backup routers can result in a 226 disruption in service. The protocol should ensure after Master 227 election that no state transition is triggered by any Backup router 228 of equal or lower preference as long as the Master continues to 229 function properly. 231 Some environments may find it beneficial to avoid the state 232 transition triggered when a router becomes available that is more 233 preferential than the current Master. It may be useful to support an 234 override of the immediate convergence to the preferred path. 236 2.4 Extensible Security 238 The virtual router functionality is applicable to a wide range of 239 internetworking environments that may employ different security 240 policies. The protocol should require minimal configuration and 241 overhead in the insecure operation, provide for strong authentication 242 when increased security is required, and allow integration of new 243 security mechanisms without breaking backwards compatible operation. 245 2.5 Efficient Operation over Extended LANs 247 Sending IPv6 packets on a multiaccess LAN requires mapping from an 248 IPv6 address to a MAC address. The use of the virtual router MAC 249 address in an extended LAN employing learning bridges can have a 250 significant effect on the bandwidth overhead of packets sent to the 251 virtual router. If the virtual router MAC address is never used as 252 the source address in a link level frame then the station location is 253 never learned, resulting in flooding of all packets sent to the 254 virtual router. To improve the efficiency in this environment the 255 protocol should: 1) use the virtual router MAC as the source in a 256 packet sent by the Master to trigger station learning; 2) trigger a 257 message immediately after transitioning to Master to update the 258 station learning; and 3) trigger periodic messages from the Master to 259 maintain the station learning cache. 261 3.0 VRRP Overview 263 VRRP specifies an election protocol to provide the virtual router 264 function described earlier. All protocol messaging is performed 265 using IPv6 multicast datagrams, thus the protocol can operate over a 266 variety of multiaccess LAN technologies supporting IPv6 multicast. 268 Each VRRP virtual router has a single well-known MAC address 269 allocated to it. This document currently only details the mapping to 270 networks using the IEEE 802 48-bit MAC address. The virtual router 271 MAC address is used as the source in all periodic VRRP messages sent 272 by the Master router to enable bridge learning in an extended LAN. 274 A virtual router is defined by its virtual router identifier (VRID) 275 and an IPv6 address. A VRRP router may associate a virtual router 276 with its real address on an interface, and may also be configured 277 with additional virtual router mappings and priority for virtual 278 routers it is willing to backup. The mapping between VRID and it's 279 IPv6 address must be coordinated among all VRRP routers on a LAN. 280 However, there is no restriction against reusing a VRID with a 281 different address mapping on different LANs. The scope of each 282 virtual router is restricted to a single LAN. 284 To minimize network traffic, only the Master for each virtual router 285 sends periodic VRRP Advertisement messages. A Backup router will not 286 attempt to preempt the Master unless it has higher priority. This 287 eliminates service disruption unless a more preferred path becomes 288 available. It's also possible to administratively prohibit all 289 preemption attempts. The only exception is that a VRRP router will 290 always become Master of any virtual router associated with address it 291 owns. If the Master becomes unavailable then the highest priority 292 Backup will transition to Master after a short delay, providing a 293 controlled transition of the virtual router responsibility with 294 minimal service interruption. 296 VRRP defines three types of authentication providing simple 297 deployment in insecure environments, added protection against 298 misconfiguration, and strong sender authentication in security 299 conscious environments. Analysis of the protection provided and 300 vulnerability of each mechanism is deferred to Section 10.0 Security 301 Considerations. In addition new authentication types and data can be 302 defined in the future without affecting the format of the fixed 303 portion of the protocol packet, thus preserving backward compatible 304 operation. 306 The VRRP protocol design provides rapid transition from Backup to 307 Master to minimize service interruption, and incorporates 308 optimizations that reduce protocol complexity while guaranteeing 309 controlled Master transition for typical operational scenarios. The 310 optimizations result in an election protocol with minimal runtime 311 state requirements, minimal active protocol states, and a single 312 message type and sender. The typical operational scenarios are 313 defined to be two redundant routers and/or distinct path preferences 314 among each router. A side effect when these assumptions are violated 315 (i.e., more than two redundant paths all with equal preference) is 316 that duplicate packets may be forwarded for a brief period during 317 Master election. However, the typical scenario assumptions are 318 likely to cover the vast majority of deployments, loss of the Master 319 router is infrequent, and the expected duration in Master election 320 convergence is quite small ( << 1 second ). Thus the VRRP 321 optimizations represent significant simplifications in the protocol 322 design while incurring an insignificant probability of brief network 323 degradation. 325 4. Sample Configurations 327 4.1 Sample Configuration 1 329 The following figure shows a simple network with two VRRP routers 330 implementing one virtual router. Note that this example is provided 331 to help understand the protocol, but is not expected to occur in 332 actual practice. 334 +-----------+ +-----------+ 335 | Rtr1 | | Rtr2 | 336 |(MR VRID=1)| |(BR VRID=1)| 337 | | | | 338 VRID=1 +-----------+ +-----------+ 339 IPv6 A -------->* *<--------- IPv6 B 340 | | 341 | | 342 ------------------+------------+-----+--------+--------+--------+-- 343 ^ ^ ^ ^ 344 | | | | 345 (IPv6 A) (IPv6 A) (IPv6 A) (IPv6 A) 346 | | | | 347 +--+--+ +--+--+ +--+--+ +--+--+ 348 | H1 | | H2 | | H3 | | H4 | 349 +-----+ +-----+ +--+--+ +--+--+ 350 Legend: 351 ---+---+---+-- = Ethernet, Token Ring, or FDDI 352 H = Host computer 353 MR = Master Router 354 BR = Backup Router 355 * = IPv6 Address 356 (IPv6) = default router for hosts 358 Eliminating all mention of VRRP (VRID=1) from the figure above leaves 359 it as a typical IPv6 deployment. Each router has a link-local IPv6 360 address on the LAN interface (Rtr1 is assigned IPv6 Link-Local A and 361 Rtr2 is assigned IPv6 Link-Local B), and each host learns a default 362 route from Router Advertisements through one of the routers (in this 363 example they all use Rtr1's IPv6 Link-Local A). 365 Moving to the VRRP environment, each router has the exact same Link- 366 Local IPv6 address. Rtr1 is said to be the IPv6 address owner of 367 IPv6 A, and Rtr2 is the IPv6 address owner of IPv6 B. A virtual 368 router is then defined by associating a unique identifier (the 369 virtual router ID) with the address owned by a router. Finally, the 370 VRRP protocol manages virtual router fail over to a backup router. 372 The example above shows a virtual router configured to cover the IPv6 373 address owned by Rtr1 (VRID=1,IPv6_Address=A). When VRRP is enabled 374 on Rtr1 for VRID=1 it will assert itself as Master, with 375 priority=255, since it is the IPv6 address owner for the virtual 376 router IPv6 address. When VRRP is enabled on Rtr2 for VRID=1 it will 377 transition to Backup, with priority=100, since it is not the IPv6 378 address owner. If Rtr1 should fail then the VRRP protocol will 379 transition Rtr2 to Master, temporarily taking over forwarding 380 responsibility for IPv6 A to provide uninterrupted service to the 381 hosts. 383 Note that in this example IPv6 B is not backed up, it is only used by 384 Rtr2 as its interface address. In order to backup IPv6 B, a second 385 virtual router must be configured. This is shown in the next 386 section. 388 4.2 Sample Configuration 2 390 The following figure shows a configuration with two virtual routers 391 with the hosts spitting their traffic between them. This example is 392 expected to be common in actual practice. 394 +-----------+ +-----------+ 395 | Rtr1 | | Rtr2 | 396 |(MR VRID=1)| |(BR VRID=1)| 397 |(BR VRID=2)| |(MR VRID=2)| 398 VRID=1 +-----------+ +-----------+ VRID=2 399 IPv6 A -------->* *<---------- IPv6 B 400 | | 401 | | 402 ------------------+------------+-----+--------+--------+--------+-- 403 ^ ^ ^ ^ 404 | | | | 405 (IPv6 A) (IPv6 A) (IPv6 B) (IPv6 B) 406 | | | | 407 +--+--+ +--+--+ +--+--+ +--+--+ 408 | H1 | | H2 | | H3 | | H4 | 409 +-----+ +-----+ +--+--+ +--+--+ 410 Legend: 411 ---+---+---+-- = Ethernet, Token Ring, or FDDI 412 H = Host computer 413 MR = Master Router 414 BR = Backup Router 415 * = IPv6 Address 416 (IPv6) = default router for hosts 418 In the example above, half of the hosts have learned a default route 419 through Rtr1's IPv6 A and half are using Rtr2's IPv6 B. The 420 configuration of virtual router VRID=1 is exactly the same as in the 421 first example (see section 4.1), and a second virtual router has been 422 added to cover the IPv6 address owned by Rtr2 (VRID=2, 423 IPv6_Address=B). In this case Rtr2 will assert itself as Master for 424 VRID=2 while Rtr1 will act as a backup. This scenario demonstrates a 425 deployment providing load splitting when both routers are available 426 while providing full redundancy for robustness. 428 5.0 Protocol 430 The purpose of the VRRP packet is to communicate to all VRRP routers 431 the priority and the state of the Master router associated with the 432 Virtual Router ID. 434 VRRP packets are sent encapsulated in IPv6 packets. They are sent to 435 the IPv6 multicast address assigned to VRRP. 437 5.1 VRRP Packet Format 439 This section defines the format of the VRRP packet and the relevant 440 fields in the IPv6 header. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |Version| Type | Virtual Rtr ID| Priority | (reserved) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Auth Type | Adver Int | Checksum | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 + + 451 | | 452 + IPv6 Address + 453 | | 454 + + 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Authentication Data (1) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Authentication Data (2) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 5.2 IPv6 Field Descriptions 464 5.2.1 Source Address 466 The IPv6 link-local address of the interface the packet is being sent 467 from. 469 5.2.2 Destination Address 471 The IPv6 multicast address as assigned by the IANA for VRRP is: 473 FF02:0:0:0:0:0:XXXX:XXXX 475 This is a link-local scope multicast address. Routers MUST NOT 476 forward a datagram with this destination address regardless of its 477 Hop Limit. 479 5.2.3 Hop Limit 481 The Hop Limit MUST be set to 255. A VRRP router receiving a packet 482 with the Hop Limit not equal to 255 MUST discard the packet. 484 5.2.4 Next Header 486 The IPv6 Next Header protocol assigned by the IANA for VRRP is 112 487 (decimal). 489 5.3 VRRP Field Descriptions 491 5.3.1 Version 493 The version field specifies the VRRP protocol version of this packet. 494 This document defines version 3. 496 5.3.2 Type 498 The type field specifies the type of this VRRP packet. The only 499 packet type defined in this version of the protocol is: 501 1 ADVERTISEMENT 503 A packet with unknown type MUST be discarded. 505 5.3.3 Virtual Rtr ID (VRID) 507 The Virtual Router Identifier (VRID) field identifies the virtual 508 router this packet is reporting status for. 510 5.3.4 Priority 512 The priority field specifies the sending VRRP router's priority for 513 the virtual router. Higher values equal higher priority. This field 514 is an 8 bit unsigned integer field. 516 The priority value for the VRRP router that owns the IPv6 address 517 associated with the virtual router MUST be 255 (decimal). 519 VRRP routers backing up a virtual router MUST use priority values 520 between 1-254 (decimal). The default priority value for VRRP routers 521 backing up a virtual router is 100 (decimal). 523 The priority value zero (0) has special meaning indicating that the 524 current Master has stopped participating in VRRP. This is used to 525 trigger Backup routers to quickly transition to Master without having 526 to wait for the current Master to timeout. 528 5.3.5 Reserved 530 This field MUST be set to zero on transmission and ignored on 531 reception. 533 5.3.6 Authentication Type 535 The authentication type field identifies the authentication method 536 being utilized. Authentication type is unique on a Virtual Router 537 basis. The authentication type field is an 8 bit unsigned integer. 538 A packet with unknown authentication type or that does not match the 539 locally configured authentication method MUST be discarded. 541 The authentication methods currently defined are: 543 0 - No Authentication 544 1 - Simple Text Password 545 2 - IP Authentication Header 547 5.3.6.1 No Authentication 549 The use of this authentication type means that VRRP protocol 550 exchanges are not authenticated. The contents of the Authentication 551 Data field should be set to zero on transmission and ignored on 552 reception. 554 5.3.6.2 Simple Text Password 556 The use of this authentication type means that VRRP protocol 557 exchanges are authenticated by a clear text password. The contents 558 of the Authentication Data field should be set to the locally 559 configured password on transmission. There is no default password. 560 The receiver MUST check that the Authentication Data in the packet 561 matches its configured authentication string. Packets that do not 562 match MUST be discarded. 564 Note that there are security implications to using Simple Text 565 password authentication, and one should see the Security 566 Consideration section of this document. 568 5.3.6.3 IP Authentication Header 570 The use of this authentication type means the VRRP protocol exchanges 571 are authenticated using the mechanisms defined by the IP 572 Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP 573 and AH" [HMAC]. Keys may be either configured manually or via a key 574 distribution protocol. 576 If a packet is received that does not pass the authentication check 577 due to a missing authentication header or incorrect message digest, 578 then the packet MUST be discarded. The contents of the 579 Authentication Data field should be set to zero on transmission and 580 ignored on reception. 582 5.3.7 Advertisement Interval (Adver Int) 584 The Advertisement interval indicates the time interval (in seconds) 585 between ADVERTISEMENTS. The default is 1 second. This field is used 586 for troubleshooting misconfigured routers. 588 5.3.8 Checksum 590 The checksum field is used to detect data corruption in the VRRP 591 message. 593 The checksum is the 16-bit one's complement of the one's complement 594 sum of the entire VRRP message starting with the version field and a 595 "pseudo-header" as defined in section 8.1 of RFC2460 [IPv6]. The 596 next header field in the "pseudo-header" should be set to 112 597 (decimal) for VRRP. For computing the checksum, the checksum field 598 is set to zero. See RFC1071 for more detail [CKSM]. 600 5.3.9 IPv6 Address 602 The IPv6 link-local address associated with the virtual router. 604 5.3.10 Authentication Data 606 The authentication string is currently only utilized for simple text 607 authentication, similar to the simple text authentication found in 608 the Open Shortest Path First routing protocol [OSPF]. It is up to 8 609 characters of plain text. If the configured authentication string is 610 shorter than 8 bytes, the remaining space MUST be zero-filled. Any 611 VRRP packet received with an authentication string that does not 612 match the locally configured authentication string MUST be discarded. 613 The authentication string is unique on a per interface basis. 615 There is no default value for this field. 617 6. Protocol State Machine 619 6.1 Parameters per Virtual Router 621 VRID Virtual Router Identifier. Configured item 622 in the range 1-255 (decimal). There is no 623 default. 625 Priority Priority value to be used by this VRRP 626 router in Master election for this virtual 627 router. The value of 255 (decimal) is 628 reserved for the router that owns the IPv6 629 address associated with the virtual router. 630 The value of 0 (zero) is reserved for Master 631 router to indicate it is releasing 632 responsibility for the virtual router. The 633 range 1-254 (decimal) is available for VRRP 634 routers backing up the virtual router. The 635 default value is 100 (decimal). 637 IPv6_Address The IPv6 link-local address associated with 638 this virtual router. Configured item. No 639 default. 641 Advertisement_Interval Time interval between ADVERTISEMENTS 642 (seconds). Default is 1 second. 644 Skew_Time Time to skew Master_Down_Interval in 645 seconds. Calculated as: 647 ( (256 - Priority) / 256 ) 649 Master_Down_Interval Time interval for Backup to declare Master 650 down (seconds). Calculated as: 652 (3 * Advertisement_Interval) + Skew_time 654 Preempt_Mode Controls whether a higher priority Backup 655 router preempts a lower priority Master. 656 Values are True to allow preemption and 657 False to prohibit preemption. Default is 658 True. 660 Note: Exception is that the router that owns 661 the IPv6 address associated with the virtual 662 router always preempts independent of the 663 setting of this flag. 665 Authentication_Type Type of authentication being used. Values 666 are defined in section 5.3.6. 668 Authentication_Data Authentication data specific to the 669 Authentication_Type being used. 671 6.2 Timers 673 Master_Down_Timer Timer that fires when ADVERTISEMENT has not 674 been heard for Master_Down_Interval. 676 Adver_Timer Timer that fires to trigger sending of 677 ADVERTISEMENT based on 678 Advertisement_Interval. 680 6.3 State Transition Diagram 682 +---------------+ 683 +--------->| |<-------------+ 684 | | Initialize | | 685 | +------| |----------+ | 686 | | +---------------+ | | 687 | | | | 688 | V V | 689 +---------------+ +---------------+ 690 | |---------------------->| | 691 | Master | | Backup | 692 | |<----------------------| | 693 +---------------+ +---------------+ 695 6.4 State Descriptions 697 In the state descriptions below, the state names are identified by 698 {state-name}, and the packets are identified by all upper case 699 characters. 701 A VRRP router implements an instance of the state machine for each 702 virtual router election it is participating in. 704 6.4.1 Initialize 706 The purpose of this state is to wait for a Startup event. If a 707 Startup event is received, then: 709 - If the Priority = 255 (i.e., the router owns the IPv6 address 710 associated with the virtual router) 712 o Send an ADVERTISEMENT 713 o Send an unsolicited ND Neighbor Advertisement with the Router 714 Flag (R) set, the Solicited Flag (S) unset, the Override flag 715 (O) set, the Target Address set to the IPv6 link-local address 716 of the Virtual Router, and the Target Link Layer address set to 717 the virtual router MAC address. 718 o Set the Adver_Timer to Advertisement_Interval 719 o Transition to the {Master} state 721 else 723 o Set the Master_Down_Timer to Master_Down_Interval 724 o Transition to the {Backup} state 726 endif 728 6.4.2 Backup 730 The purpose of the {Backup} state is to monitor the availability and 731 state of the Master Router. 733 While in this state, a VRRP router MUST do the following: 735 - MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 736 address associated with the virtual router. 738 - MUST NOT send ND Router Advertisement messages for the virtual 739 router. 741 - MUST discard packets with a destination link layer MAC address 742 equal to the virtual router MAC address. 744 - MUST NOT accept packets addressed to the IPv6 address associated 745 with the virtual router. 747 - If a Shutdown event is received, then: 749 o Cancel the Master_Down_Timer 750 o Transition to the {Initialize} state 752 endif 754 - If the Master_Down_Timer fires, then: 756 o Send an ADVERTISEMENT 757 o Compute and join the Solicited-Node multicast address [ADD-ARH] 758 for the link-local IPv6 address of the Virtual Router. 759 o Send an unsolicited ND Neighbor Advertisement with the Router 760 Flag (R) set, the Solicited Flag (S) unset, the Override flag 761 (O) set, the Target Address set to the IPv6 link-local address 762 of the Virtual Router, and the Target Link Layer address set to 763 the virtual router MAC address. 764 o Set the Adver_Timer to Advertisement_Interval 765 o Transition to the {Master} state 767 endif 769 - If an ADVERTISEMENT is received, then: 771 If the Priority in the ADVERTISEMENT is Zero, then: 773 o Set the Master_Down_Timer to Skew_Time 775 else: 777 If Preempt_Mode is False, or If the Priority in the 778 ADVERTISEMENT is greater than or equal to the local 779 Priority, then: 781 o Reset the Master_Down_Timer to Master_Down_Interval 783 else: 785 o Discard the ADVERTISEMENT 787 endif 788 endif 789 endif 791 6.4.3 Master 793 While in the {Master} state the router functions as the forwarding 794 router for the IPv6 address associated with the virtual router. 796 While in this state, a VRRP router MUST do the following: 798 - MUST be a member of the Solicited-Node multicast address for the 799 IPv6 link-local address associated with the virtual router. 801 - MUST respond to ND Neighbor Solicitation message for the IPv6 802 address associated with the virtual router. 804 - MUST send ND Router Advertisements for the virtual router. 806 - MUST respond to ND Router Solicitation message for the virtual 807 router. 809 - MUST forward packets with a destination link layer MAC address 810 equal to the virtual router MAC address. 812 - MUST NOT accept packets addressed to the IPv6 address associated 813 with the virtual router if it is not the IPv6 address owner. 815 - MUST accept packets addressed to the IPv6 address associated with 816 the virtual router if it is the IPv6 address owner. 818 - If a Shutdown event is received, then: 820 o Cancel the Adver_Timer 821 o Send an ADVERTISEMENT with Priority = 0 822 o Transition to the {Initialize} state 824 endif 826 - If the Adver_Timer fires, then: 828 o Send an ADVERTISEMENT 829 o Reset the Adver_Timer to Advertisement_Interval 831 endif 833 - If an ADVERTISEMENT is received, then: 835 If the Priority in the ADVERTISEMENT is Zero, then: 837 o Send an ADVERTISEMENT 838 o Reset the Adver_Timer to Advertisement_Interval 840 else: 842 If the Priority in the ADVERTISEMENT is greater than the 843 local Priority, 844 or 845 If the Priority in the ADVERTISEMENT is equal to the local 846 Priority and the IPv6 Address of the sender is greater than 847 the local IPv6 Address, then: 849 o Cancel Adver_Timer 850 o Set Master_Down_Timer to Master_Down_Interval 851 o Transition to the {Backup} state 853 else: 855 o Discard ADVERTISEMENT 857 endif 858 endif 859 endif 861 7. Sending and Receiving VRRP Packets 863 7.1 Receiving VRRP Packets 865 Performed the following functions when a VRRP packet is received: 867 - MUST verify that the IPv6 Hop Limit is 255. 868 - MUST verify the VRRP version is 3 869 - MUST verify that the received packet contains the complete VRRP 870 packet (including fixed fields, IPv6 Address, and Authentication 871 Data). 872 - MUST verify the VRRP checksum 873 - MUST verify that the VRID is configured on the receiving 874 interface and the local router is not the IPv6 Address owner 875 (Priority equals 255 (decimal)). 876 - MUST verify that the Auth Type matches the locally configured 877 authentication method for the virtual router and perform that 878 authentication method 880 If any one of the above checks fails, the receiver MUST discard the 881 packet, SHOULD log the event and MAY indicate via network management 882 that an error occurred. 884 - MAY verify that the IPv6 Address matches the IPv6_Address 885 configured for the VRID. 887 If the above check fails, the receiver SHOULD log the event and MAY 888 indicate via network management that a misconfiguration was detected. 889 If the packet was not generated by the address owner (Priority does 890 not equal 255 (decimal)), the receiver MUST drop the packet, 891 otherwise continue processing. 893 - MUST verify that the Adver Interval in the packet is the same as 894 the locally configured for this virtual router 896 If the above check fails, the receiver MUST discard the packet, 897 SHOULD log the event and MAY indicate via network management that a 898 misconfiguration was detected. 900 7.2 Transmitting VRRP Packets 902 The following operations MUST be performed when transmitting a VRRP 903 packet. 905 - Fill in the VRRP packet fields with the appropriate virtual 906 router configuration state 907 - Compute the VRRP checksum 908 - Set the source MAC address to Virtual Router MAC Address 909 - Set the source IPv6 address to interface link-local IPv6 address 910 - Set the IPv6 protocol to VRRP 911 - Send the VRRP packet to the VRRP IP multicast group 913 Note: VRRP packets are transmitted with the virtual router MAC 914 address as the source MAC address to ensure that learning bridges 915 correctly determine the LAN segment the virtual router is attached 916 to. 918 7.3 Virtual Router MAC Address 920 The virtual router MAC address associated with a virtual router is an 921 IEEE 802 MAC Address in the following format: 923 00-00-5E-00-01-{VRID} (in hex in internet standard bit-order) 925 The first three octets are derived from the IANA's OUI. The next two 926 octets (00-01) indicate the address block assigned to the VRRP 927 protocol. {VRID} is the VRRP Virtual Router Identifier. This 928 mapping provides for up to 255 VRRP routers on a network. 930 7.4 IPv6 Interface Identifiers 932 IPv6 Routers running VRRP MUST create their Interface Identifiers in 933 the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over 934 Ethernet"). They MUST NOT use the Virtual Router MAC address to 935 create the Modified EUI-64 identifiers. 937 This VRRP specification describes how to advertise and resolve the 938 VRRP routers IPv6 link local address into the Virtual Router MAC 939 address. 941 8. Operational Issues 943 8.1 ICMPv6 Redirects 945 ICMPv6 Redirects may be used normally when VRRP is running between a 946 group of routers [ICMPv6]. This allows VRRP to be used in 947 environments where the topology is not symmetric. 949 The IPv6 source address of an ICMPv6 redirect should be the address 950 the end host used when making its next hop routing decision. If a 951 VRRP router is acting as Master for virtual router(s) containing 952 addresses it does not own, then it must determine which virtual 953 router the packet was sent to when selecting the redirect source 954 address. One method to deduce the virtual router used is to examine 955 the destination MAC address in the packet that triggered the 956 redirect. 958 It may be useful to disable Redirects for specific cases where VRRP 959 is being used to load share traffic between a number of routers in a 960 symmetric topology. 962 8.2 ND Neighbor Solicitation 964 When a host sends an ND Neighbor Solicitation message for the virtual 965 router IPv6 address, the Master virtual router MUST respond to the ND 966 Neighbor Solicitation message with the virtual MAC address for the 967 virtual router. The Master virtual router MUST NOT respond with its 968 physical MAC address. This allows the client to always use the same 969 MAC address regardless of the current Master router. 971 When a Master virtual routers sends an ND Neighbor Solicitation 972 message for a hosts IPv6 address, the Master virtual router MUST 973 include the virtual MAC address for the virtual router if it sends a 974 source link-layer address option in the neighbor solicitation 975 message. It MUST NOT use its physical MAC address in the source 976 link-layer address option. 978 When a VRRP router restarts or boots, it SHOULD not send any ND 979 messages with its physical MAC address for the IPv6 address it owns, 980 it should only send ND messages that include Virtual MAC addresses. 981 This may entail: 983 - When configuring an interface, VRRP routers should send an 984 unsolicitated ND Neighbor Advertisement message containing the 985 virtual router MAC address for the IPv6 address on that interface. 987 - At system boot, when initializing interfaces for VRRP operation; 988 delay all ND Router and Neighbor Advertisements and Solicitation 989 messages until both the IPv6 address and the virtual router MAC 990 address are configured. 992 8.3 Potential Forwarding Loop 994 A VRRP router SHOULD not forward packets addressed to the IPv6 995 Address it becomes Master for if it is not the owner. Forwarding 996 these packets would result in unnecessary traffic. Also in the case 997 of LANs that receive packets they transmit (e.g., token ring) this 998 can result in a forwarding loop that is only terminated when the IPv6 999 TTL expires. 1001 One such mechanism for VRRP routers is to add/delete a reject host 1002 route for each adopted IPv6 address when transitioning to/from MASTER 1003 state. 1005 9. Operation over FDDI, Token Ring, and ATM LANE 1007 9.1 Operation over FDDI 1009 FDDI interfaces remove from the FDDI ring frames that have a source 1010 MAC address matching the device's hardware address. Under some 1011 conditions, such as router isolations, ring failures, protocol 1012 transitions, etc., VRRP may cause there to be more than one Master 1013 router. If a Master router installs the virtual router MAC address 1014 as the hardware address on a FDDI device, then other Masters' 1015 ADVERTISEMENTS will be removed from the ring during the Master 1016 convergence, and convergence will fail. 1018 To avoid this an implementation SHOULD configure the virtual router 1019 MAC address by adding a unicast MAC filter in the FDDI device, rather 1020 than changing its hardware MAC address. This will prevent a Master 1021 router from removing any ADVERTISEMENTS it did not originate. 1023 9.2 Operation over Token Ring 1025 Token ring has several characteristics that make running VRRP 1026 difficult. These include: 1028 - In order to switch to a new master located on a different bridge 1029 token ring segment from the previous master when using source 1030 route bridges, a mechanism is required to update cached source 1031 route information. 1033 - No general multicast mechanism supported across old and new token 1034 ring adapter implementations. While many newer token ring adapters 1035 support group addresses, token ring functional address support is 1036 the only generally available multicast mechanism. Due to the 1037 limited number of token ring functional addresses these may 1038 collide with other usage of the same token ring functional 1039 addresses. 1041 Due to these difficulties, the preferred mode of operation over token 1042 ring will be to use a token ring functional address for the VRID 1043 virtual MAC address. Token ring functional addresses have the two 1044 high order bits in the first MAC address octet set to B'1'. They 1045 range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format). 1046 However, unlike multicast addresses, there is only one unique 1047 functional address per bit position. The functional addresses 1048 addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved 1049 by the Token Ring Architecture [TKARCH] for user-defined 1050 applications. However, since there are only 12 user-defined token 1051 ring functional addresses, there may be other non-IP protocols using 1052 the same functional address. Since the Novell IPX [IPX] protocol uses 1053 the 03-00-00-10-00-00 functional address, operation of VRRP over 1054 token ring will avoid use of this functional address. In general, 1055 token ring VRRP users will be responsible for resolution of other 1056 user-defined token ring functional address conflicts. 1058 VRIDs are mapped directly to token ring functional addresses. In 1059 order to decrease the likelihood of functional address conflicts, 1060 allocation will begin with the largest functional address. Most non- 1061 IP protocols use the first or first couple user-defined functional 1062 addresses and it is expected that VRRP users will choose VRIDs 1063 sequentially starting with 1. 1065 VRID Token Ring Functional Address 1066 ---- ----------------------------- 1067 1 03-00-02-00-00-00 1068 2 03-00-04-00-00-00 1069 3 03-00-08-00-00-00 1070 4 03-00-10-00-00-00 1071 5 03-00-20-00-00-00 1072 6 03-00-40-00-00-00 1073 7 03-00-80-00-00-00 1074 8 03-00-00-01-00-00 1075 9 03-00-00-02-00-00 1076 10 03-00-00-04-00-00 1077 11 03-00-00-08-00-00 1079 Or more succinctly, octets 3 and 4 of the functional address are 1080 equal to (0x4000 >> (VRID - 1)) in non-canonical format. 1082 Since a functional address cannot be used used as a MAC level source 1083 address, the real MAC address is used as the MAC source address in 1084 VRRP advertisements. This is not a problem for bridges since packets 1085 addressed to functional addresses will be sent on the spanning-tree 1086 explorer path [802.1D]. 1088 The functional address mode of operation MUST be implemented by 1089 routers supporting VRRP on token ring. 1091 Additionally, routers MAY support unicast mode of operation to take 1092 advantage of newer token ring adapter implementations that support 1093 non-promiscuous reception for multiple unicast MAC addresses and to 1094 avoid both the multicast traffic and usage conflicts associated with 1095 the use of token ring functional addresses. Unicast mode uses the 1096 same mapping of VRIDs to virtual MAC addresses as Ethernet. However, 1097 one important difference exists. ND request/reply packets contain the 1098 virtual MAC address as the source MAC address. The reason for this is 1099 that some token ring driver implementations keep a cache of MAC 1100 address/source routing information independent of the ND cache. 1101 Hence, these implementations need have to receive a packet with the 1102 virtual MAC address as the source address in order to transmit to 1103 that MAC address in a source-route bridged network. 1105 Unicast mode on token ring has one limitation that should be 1106 considered. If there are VRID routers on different source-route 1107 bridge segments and there are host implementations that keep their 1108 source-route information in the ND cache and do not listen to 1109 gratuitous NDs, these hosts will not update their ND source-route 1110 information correctly when a switch-over occurs. The only possible 1111 solution is to put all routers with the same VRID on the same source- 1112 bridge segment and use techniques to prevent that bridge segment from 1113 being a single point of failure. These techniques are beyond the 1114 scope this document. 1116 For both the multicast and unicast mode of operation, VRRP 1117 advertisements sent to 224.0.0.18 should be encapsulated as described 1118 in [RFC1469]. 1120 9.3 Operation over ATM LANE 1122 Operation of VRRP over ATM LANE on routers with ATM LANE interfaces 1123 and/or routers behind proxy LEC's are beyond the scope of this 1124 document. 1126 10. Security Considerations 1128 VRRP is designed for a range of internetworking environments that may 1129 employ different security policies. The protocol includes several 1130 authentication methods ranging from no authentication, simple clear 1131 text passwords, and strong authentication using IP Authentication 1132 with MD5 HMAC. The details on each approach including possible 1133 attacks and recommended environments follows. 1135 Independent of any authentication type VRRP includes a mechanism 1136 (setting TTL=255, checking on receipt) that protects against VRRP 1137 packets being injected from another remote network. This limits most 1138 vulnerabilities to local attacks. 1140 The security measures discussed in the following sections only 1141 provide various kinds of authentication. No confidentiality is 1142 provided. Confidentiality is not necessary for the correct operation 1143 of VRRP and there is no information in the VRRP messages that must be 1144 kept secret from other nodes on the LAN. 1146 10.1 No Authentication 1148 The use of this authentication type means that VRRP protocol 1149 exchanges are not authenticated. This type of authentication SHOULD 1150 only be used in environments were there is minimal security risk and 1151 little chance for configuration errors (e.g., two VRRP routers on a 1152 LAN). 1154 10.2 Simple Text Password 1156 The use of this authentication type means that VRRP protocol 1157 exchanges are authenticated by a simple clear text password. 1159 This type of authentication is useful to protect against accidental 1160 misconfiguration of routers on a LAN. It protects against routers 1161 inadvertently backing up another router. A new router must first be 1162 configured with the correct password before it can run VRRP with 1163 another router. This type of authentication does not protect against 1164 hostile attacks where the password can be learned by a node snooping 1165 VRRP packets on the LAN. The Simple Text Authentication combined 1166 with the TTL check makes it difficult for a VRRP packet to be sent 1167 from another LAN to disrupt VRRP operation. 1169 This type of authentication is RECOMMENDED when there is minimal risk 1170 of nodes on a LAN actively disrupting VRRP operation. If this type 1171 of authentication is used the user should be aware that this clear 1172 text password is sent frequently, and therefore should not be the 1173 same as any security significant password. 1175 10.3 IP Authentication Header 1177 The use of this authentication type means the VRRP protocol exchanges 1178 are authenticated using the mechanisms defined by the IP 1179 Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP 1180 and AH", [HMAC]. This provides strong protection against 1181 configuration errors, replay attacks, and packet 1182 corruption/modification. 1184 This type of authentication is RECOMMENDED when there is limited 1185 control over the administration of nodes on a LAN. While this type 1186 of authentication does protect the operation of VRRP, there are other 1187 types of attacks that may be employed on shared media links (e.g., 1188 generation of bogus ND replies) that are independent from VRRP and 1189 are not protected. 1191 Specifically, although securing VRRP prevents unauthorized machines 1192 from taking part in the election protocol, it does not protect hosts 1193 on the network from being deceived. For example, a gratuitous ND 1194 reply from what purports to be the virtual router's IPv6 address can 1195 redirect traffic to an unauthorized machine. Similarly, individual 1196 connections can be diverted by means of forged ICMPv6 Redirect 1197 messages. 1199 11. Acknowledgments 1201 This specification is based on RFC2238. The authors of RFC2238 are 1202 S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. 1203 Higginson, M. Shand, and A. Lindem. 1205 The author of this document would also like to thank Erik Nordmark, 1206 Thomas Narten, and Steve Deering for their his helpful suggestions. 1208 12. IANA Considerations 1210 VRRP for IPv6 needs an IPv6 link-local scope multicast address 1211 assigned by the IANA for this specification. The IPv6 multicast 1212 address should be of the following form: 1214 FF02:0:0:0:0:0:XXXX:XXXX 1216 The values assigned address should be entered into section 5.2.2. 1218 A convenient assignment of this link-local scope multicast would be: 1220 FF02:0:0:0:0:0:0:12 1222 as this would be consistent with the IPv4 assignment for VRRP. 1224 13. References 1226 [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 1227 802.1D, 1993 edition. 1229 [ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing 1230 Architecture", Internet Draft, , October 2002. 1233 [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, 1234 November 1998. 1236 [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the 1237 Internet Checksum", RFC1071, September 1988. 1239 [HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1240 and AH", RFC2403, November 1998. 1242 [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby 1243 Router Protocol (HSRP)", RFC2281, March 1998. 1245 [ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol 1246 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", 1247 RFC2463, December 1998. 1249 [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to 1250 Provide Fast Failover in IP Networks", Digital Technical 1251 Journal, Volume 9 Number 3, Winter 1997. 1253 [IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6 1254 (IPv6) Specification", RFC2460, December 1998. 1256 [IPX] Novell Incorporated., "IPX Router Specification", Version 1257 1.10, October 1992. 1259 [ND] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery 1260 for IP Version 6 (IPv6)", RFC2461, December 1998. 1262 [OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998. 1264 [RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November 1265 1998. 1267 [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area 1268 Networks", RFC1469, June 1993. 1270 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1271 3", RFC2026, BCP00009, October 1996. 1273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1274 Requirement Levels", RFC2119, BCP0014, March 1997. 1276 [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication 1277 SC30-3374-02, Third Edition, (September, 1989). 1279 [VRRP-V4] Knight, S., et. al., "Virtual Router Redundancy Protocol", 1280 RFC2338, April 1998. 1282 14. Author's Address 1284 Robert Hinden Phone: +1 650 625-2004 1285 Nokia EMail: hinden@iprg.nokia.com 1286 313 Fairchild Drive 1287 Mountain View, CA 94043 1288 USA 1290 15. Changes from RFC2338 1292 - General rewrite to change protocol to provide virtual router 1293 functionality from IPv4 to IPv6. Specific changes include: 1294 o Increment VRRP version to 3. 1295 o Change packet format to support an 128-bit IPv6 address. 1296 o Change to only support one router address (instead of multiple 1297 addresses). This included removing address count field from 1298 header. 1299 o Rewrote text to specify IPv6 Neighbor Discovery mechanisms 1300 instead of ARP. 1301 o Changed state machine actions to use Neighbor Discovery 1302 mechanisms. This includes sending unsolicited Neighbor 1303 Advertisements, Receiving Neighbor Solicitations, joining the 1304 appropriate solicited node multicast group, sending Router 1305 Advertisements, and receiving Router Solicitations. 1306 - Revised the section 4 examples text with a clearer description of 1307 mapping of IPv6 address owner, priorities, etc. 1308 - Clarify the section 7.1 text describing address list validation. 1309 - Corrected text in Preempt_Mode definition. 1310 - Changed authentication to be per Virtual Router instead of per 1311 Interface. 1312 - Added new subsection (9.3) stating that VRRP over ATM LANE is 1313 beyond the scope of this document. 1314 - Clarified text describing received packet length check. 1315 - Clarified text describing received authentication check. 1316 - Clarified text describing VRID verification check. 1317 - Added new subsection (8.4) describing need to not forward packets 1318 for adopted IPv6 addresses. 1319 - Added clarification to the security considerations section. 1320 - Added reference for computing the internet checksum. 1321 - Updated references and author information. 1322 - Removed IPR section as no IPR claims have been made agains this 1323 draft.