< draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt   draft-addogra-rtgwg-vrrp-rfc5798bis-07.txt >
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft A. Dogra Internet-Draft A. Dogra
Obsoletes: 5798 (if approved) Cisco Systems Obsoletes: 5798 (if approved) Cisco Systems
Intended status: Standards Track S. Nadas Intended status: Standards Track S. Nadas
Expires: 4 October 2022 Computer Science, Boston University Expires: 14 October 2022 Computer Science, Boston University
2 April 2022 12 April 2022
Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
draft-addogra-rtgwg-vrrp-rfc5798bis-06 draft-addogra-rtgwg-vrrp-rfc5798bis-07
Abstract Abstract
This document defines the Virtual Router Redundancy Protocol (VRRP) This document defines the Virtual Router Redundancy Protocol (VRRP)
for IPv4 and IPv6. It is version three (3) of the protocol, and it for IPv4 and IPv6. It is version three (3) of the protocol, and it
is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and
in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an
election protocol that dynamically assigns responsibility for a election protocol that dynamically assigns responsibility for a
virtual router to one of the VRRP routers on a LAN. The VRRP router virtual router to one of the VRRP routers on a LAN. The VRRP router
controlling the IPv4 or IPv6 address(es) associated with a virtual controlling the IPv4 or IPv6 address(es) associated with a virtual
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 October 2022. This Internet-Draft will expire on 14 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. A Note on Terminology . . . . . . . . . . . . . . . . . . . . 4 1.1. RFC 5798 Differences . . . . . . . . . . . . . . . . . . 4
2. A Note on Terminology . . . . . . . . . . . . . . . . . . . . 5
3. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 5. Requirements Language . . . . . . . . . . . . . . . . . . . . 7
6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Required Features . . . . . . . . . . . . . . . . . . . . . . 8 8. Required Features . . . . . . . . . . . . . . . . . . . . . . 8
8.1. IPvX Address Backup . . . . . . . . . . . . . . . . . . . 8 8.1. IPvX Address Backup . . . . . . . . . . . . . . . . . . . 8
8.2. Preferred Path Indication . . . . . . . . . . . . . . . . 8 8.2. Preferred Path Indication . . . . . . . . . . . . . . . . 8
8.3. Minimization of Unnecessary Service Disruptions . . . . . 9 8.3. Minimization of Unnecessary Service Disruptions . . . . . 9
8.4. Efficient Operation over Extended LANs . . . . . . . . . 9 8.4. Efficient Operation over Extended LANs . . . . . . . . . 9
8.5. Sub-Second Operation for IPv4 and IPv6 . . . . . . . . . 9 8.5. Sub-Second Operation for IPv4 and IPv6 . . . . . . . . . 9
9. VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 9. VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Sample Configurations . . . . . . . . . . . . . . . . . . . . 11 10. Sample Configurations . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 51 skipping to change at page 4, line 4
13.4.1. Assumptions . . . . . . . . . . . . . . . . . . . . 32 13.4.1. Assumptions . . . . . . . . . . . . . . . . . . . . 32
13.4.2. VRRPv3 Support of VRRPv2 . . . . . . . . . . . . . . 33 13.4.2. VRRPv3 Support of VRRPv2 . . . . . . . . . . . . . . 33
13.4.3. VRRPv3 Support of VRRPv2 Considerations . . . . . . 33 13.4.3. VRRPv3 Support of VRRPv2 Considerations . . . . . . 33
13.4.3.1. Slow, High-Priority Active Routers . . . . . . . 33 13.4.3.1. Slow, High-Priority Active Routers . . . . . . . 33
13.4.3.2. Overwhelming VRRPv2 Backups . . . . . . . . . . 33 13.4.3.2. Overwhelming VRRPv2 Backups . . . . . . . . . . 33
14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34
15. Contributors and Acknowledgments . . . . . . . . . . . . . . 35 15. Contributors and Acknowledgments . . . . . . . . . . . . . . 35
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
17. Normative References . . . . . . . . . . . . . . . . . . . . 36 17. Normative References . . . . . . . . . . . . . . . . . . . . 36
18. Informative References . . . . . . . . . . . . . . . . . . . 36 18. Informative References . . . . . . . . . . . . . . . . . . . 36
Appendix A. Operation over FDDI, Token Ring, and ATM LANE . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
A.1. Operation over FDDI . . . . . . . . . . . . . . . . . . . 37
A.2. Operation over Token Ring . . . . . . . . . . . . . . . . 38
A.3. Operation over ATM LANE . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document defines the Virtual Router Redundancy Protocol (VRRP) This document defines the Virtual Router Redundancy Protocol (VRRP)
for IPv4 and IPv6. It is version three (3) of the protocol. It is for IPv4 and IPv6. It is version three (3) of the protocol. It is
based on VRRP (version 2) for IPv4 that is defined in [RFC3768] and based on VRRP (version 2) for IPv4 that is defined in [RFC3768] and
in [VRRP-IPv6]. VRRP specifies an election protocol that dynamically in [VRRP-IPv6]. VRRP specifies an election protocol that dynamically
assigns responsibility for a virtual router to one of the VRRP assigns responsibility for a virtual router to one of the VRRP
routers on a LAN. The VRRP router controlling the IPv4 or IPv6 routers on a LAN. The VRRP router controlling the IPv4 or IPv6
address(es) associated with a virtual router is called the VRRP address(es) associated with a virtual router is called the VRRP
skipping to change at page 4, line 36 skipping to change at page 4, line 33
unavailable. unavailable.
The VRRP terminology has been updated conform to inclusive language The VRRP terminology has been updated conform to inclusive language
guidelines for IETF technologies. This document obsoletes VRRP guidelines for IETF technologies. This document obsoletes VRRP
Version 3 [RFC5798]. Version 3 [RFC5798].
VRRP provides a function similar to the proprietary protocols "Hot VRRP provides a function similar to the proprietary protocols "Hot
Standby Router Protocol (HSRP)" [RFC2281] and "IP Standby Protocol" Standby Router Protocol (HSRP)" [RFC2281] and "IP Standby Protocol"
[IPSTB]. [IPSTB].
1.1. RFC 5798 Differences
The following changes have been made from RFC 5798:
1. The term for the VRRP router assuming forwarding responsibility
has been changed to "Active Router" to be consistent with IETF
inclusive terminology. Additionally, inconsistencies in RFC 5798
terminology for both "Active Router" and "Backup Router" were
corrected.
2. Errata pertaining to the state machines in Section 12 were
corrected.
3. Appendicies describing operation over legacy technologies (FDDI,
Token Ring, and ATM LAN Emulation) were removed.
4. Miscellaneous editorial changes were made for readability.
2. A Note on Terminology 2. A Note on Terminology
This document discusses both IPv4 and IPv6 operations, and with This document discusses both IPv4 and IPv6 operations, and with
respect to the VRRP protocol, many of the descriptions and procedures respect to the VRRP protocol, many of the descriptions and procedures
are common. In this document, it would be less verbose to be able to are common. In this document, it would be less verbose to be able to
refer to "IP" to mean either "IPv4 or IPv6". However, historically, refer to "IP" to mean either "IPv4 or IPv6". However, historically,
the term "IP" usually refers to IPv4. For this reason, in this the term "IP" usually refers to IPv4. For this reason, in this
specification, the term "IPvX" (where X is 4 or 6) is introduced to specification, the term "IPvX" (where X is 4 or 6) is introduced to
mean either "IPv4" or "IPv6". In this text, where the IP version mean either "IPv4" or "IPv6". In this text, where the IP version
matters, the appropriate term is used and the use of the term "IP" is matters, the appropriate term is used and the use of the term "IP" is
skipping to change at page 35, line 44 skipping to change at page 35, line 44
The IPv4 text in this specification is based on [RFC3768]. The The IPv4 text in this specification is based on [RFC3768]. The
authors of that specification would like to thank Glen Zorn, Michael authors of that specification would like to thank Glen Zorn, Michael
Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel
Halpern, Steve Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Halpern, Steve Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun,
Radia Perlman, Russ Housley, Harald Alvestrand, Steve Bellovin, Ned Radia Perlman, Russ Housley, Harald Alvestrand, Steve Bellovin, Ned
Freed, Ted Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex Freed, Ted Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex
Zinin for their comments and suggestions. Zinin for their comments and suggestions.
Thanks to Stewart Bryant and Sasha Vainshtein for comments on the Thanks to Stewart Bryant and Sasha Vainshtein for comments on the
current document (RFC 5798 BIS). current document (RFC 5798 BIS). Thanks to Gyan Mishra, Paul
Congdon, and Jon Rosen for discussions related to the removal of
legacy technology appendicies.
16. IANA Considerations 16. IANA Considerations
IANA has assigned the IPv4 multicast address 224.0.0.18 for VRRP. IANA has assigned the IPv4 multicast address 224.0.0.18 for VRRP.
IANA has assigned an IPv6 link-local scope multicast address for VRRP IANA has assigned an IPv6 link-local scope multicast address for VRRP
for IPv6. The IPv6 multicast address is FF02:0:0:0:0:0:0:12. for IPv6. The IPv6 multicast address is FF02:0:0:0:0:0:0:12.
IANA has reserved a block of IANA Ethernet unicast addresses for VRRP IANA has reserved a block of IANA Ethernet unicast addresses for VRRP
for IPv6 in the range 00-00-5E-00-02-00 to 00-00-5E-00-02-FF (in for IPv6 in the range 00-00-5E-00-02-00 to 00-00-5E-00-02-FF (in
hex). hex).
17. Normative References 17. Normative References
[ISO.10038.1993]
International Organization for Standardization,
"Information technology - Telecommunications and
information exchange between systems - Local area networks
- Media ac control (MAC) bridges", ISO Standard 10038,
1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", 1997. Requirement Levels", 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", 1998. (IPv6) Specification", 1998.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol", 2004. [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol", 2004.
[RFC4291] Deering, S. and R. Hinden, "IP Version 6 Addressing [RFC4291] Deering, S. and R. Hinden, "IP Version 6 Addressing
Architecture", 2006. Architecture", 2006.
skipping to change at page 36, line 48 skipping to change at page 36, line 44
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", May 2017. 2119 Key Words", May 2017.
18. Informative References 18. Informative References
[IPSTB] Higginson, P. and M. Shand, "Development of Router [IPSTB] Higginson, P. and M. Shand, "Development of Router
Clusters to Provide Fast Failover in IP Networks", Digital Clusters to Provide Fast Failover in IP Networks", Digital
Technical Journal, Volume 9 Number 3", 1997. Technical Journal, Volume 9 Number 3", 1997.
[IPX] Novell Incorporated, "IPX Router Specification Version
1.10", October 1992.
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet Checksum", September 1988. Internet Checksum", September 1988.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", September [RFC1256] Deering, S., "ICMP Router Discovery Messages", September
1991. 1991.
[RFC1469] Pusateri, T., "IP Multicast over Token-Ring Local Area
Networks", June 1993.
[RFC2131] Droms, T., "Dynamic Host Configuration Protocol", March [RFC2131] Droms, T., "Dynamic Host Configuration Protocol", March
1997. 1997.
[RFC2281] Li, T., Cole, B., Morton, P., and D. Lo, "Cisco Hot [RFC2281] Li, T., Cole, B., Morton, P., and D. Lo, "Cisco Hot
Standby Router Protocol (HSRP)", March 1998. Standby Router Protocol (HSRP)", March 1998.
[RFC2328] Moy, J., "OSPF Version 2", April 1998. [RFC2328] Moy, J., "OSPF Version 2", April 1998.
[RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel,
D., Hunt, P., Higginson, P., Shand, M., Lindem, A., and G. D., Hunt, P., Higginson, P., Shand, M., Lindem, A., and G.
Malkin, "Virtual Router Redundancy Protocol", April 1998. Malkin, "Virtual Router Redundancy Protocol", April 1998.
[RFC2453] Malkin, G., "RIP Version 2", November 1998. [RFC2453] Malkin, G., "RIP Version 2", November 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", December 1998. Networks", December 1998.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", March 2005. Neighbor Discovery (SEND)", March 2005.
[TKARCH] IBM Incorporated, "IBM Token-Ring Network, Architecture
Specification, Publication SC30-3374-02, Third Edition",
September 1989.
[VRRP-IPv6] [VRRP-IPv6]
Hinden, R. and J. Cruz, "Virtual Router Redundancy Hinden, R. and J. Cruz, "Virtual Router Redundancy
Protocol for IPv6", Work in Progress, March 2007. Protocol for IPv6", Work in Progress, March 2007.
Appendix A. Operation over FDDI, Token Ring, and ATM LANE
A.1. Operation over FDDI
FDDI interfaces remove from the FDDI ring frames that have a source
MAC address matching the device's hardware address. Under some
conditions, such as router isolations, ring failures, protocol
transitions, etc., VRRP may cause there to be more than one Active
Router. If an Active Router installs the virtual router MAC address
as the hardware address on an FDDI device, then other Active Routers'
ADVERTISEMENTS will be removed from the ring during the Active Router
convergence, and convergence will fail.
To avoid this, an implementation SHOULD configure the virtual router
MAC address by adding a unicast MAC filter in the FDDI device, rather
than changing its hardware MAC address. This will prevent an Active
Router from removing any ADVERTISEMENTS it did not originate.
A.2. Operation over Token Ring
Token Ring has several characteristics that make running VRRP
difficult. These include the following:
* In order to switch to a new Active Router located on a different
bridge Token-Ring segment from the previous Active Router when
using source-route bridges, a mechanism is required to update
cached source-route information.
* No general multicast mechanism is supported across old and new
Token-Ring adapter implementations. While many newer Token-Ring
adapters support group addresses, Token-Ring functional-address
support is the only generally available multicast mechanism. Due
to the limited number of Token-Ring functional addresses, these
may collide with other usage of the same Token-Ring functional
addresses.
Due to these difficulties, the preferred mode of operation over Token
Ring will be to use a Token-Ring functional address for the VRID
virtual MAC address. Token-Ring functional addresses have the two
high-order bits in the first MAC address octet set to B'1'. They
range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format).
However, unlike multicast addresses, there is only one unique
functional address per bit position. The functional addresses
03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by the
Token-Ring Architecture [TKARCH] for user-defined applications.
However, since there are only 12 user-defined Token-Ring functional
addresses, there may be other non-IPvX protocols using the same
functional address. Since the Novell IPX [IPX] protocol uses the
03-00-00-10-00-00 functional address, operation of VRRP over Token
Ring will avoid using this functional address. In general, Token-
Ring VRRP users will be responsible for resolution of other user-
defined Token-Ring functional address conflicts.
VRIDs are mapped directly to Token-Ring functional addresses. In
order to decrease the likelihood of functional-address conflicts,
allocation will begin with the largest functional address. Most non-
IPvX protocols use the first or first couple user-defined functional
addresses, and it is expected that VRRP users will choose VRIDs
sequentially, starting with 1.
VRID Token-Ring Functional Address
---- -----------------------------
1 03-00-02-00-00-00
2 03-00-04-00-00-00
3 03-00-08-00-00-00
4 03-00-10-00-00-00
5 03-00-20-00-00-00
6 03-00-40-00-00-00
7 03-00-80-00-00-00
8 03-00-00-01-00-00
9 03-00-00-02-00-00
10 03-00-00-04-00-00
11 03-00-00-08-00-00
Or, more succinctly, octets 3 and 4 of the functional address are
equal to (0x4000 >> (VRID - 1)) in non-canonical format.
Since a functional address cannot be used as a MAC-level source
address, the real MAC address is used as the MAC source address in
VRRP advertisements. This is not a problem for bridges, since
packets addressed to functional addresses will be sent on the
spanning-tree explorer path [ISO.10038.1993].
The functional-address mode of operation MUST be implemented by
routers supporting VRRP on Token Ring.
Additionally, VRRP routers MAY support the unicast mode of operation
to take advantage of newer Token-Ring adapter implementations that
support non-promiscuous reception for multiple unicast MAC addresses
and to avoid both the multicast traffic and usage conflicts
associated with the use of Token-Ring functional addresses. Unicast
mode uses the same mapping of VRIDs to virtual MAC addresses as
Ethernet. However, one important difference exists. ND request/
reply packets contain the virtual MAC address as the source MAC
address. The reason for this is that some Token-Ring driver
implementations keep a cache of MAC address/source-routing
information independent of the ND cache.
Hence, these implementations have to receive a packet with the
virtual MAC address as the source address in order to transmit to
that MAC address on a source-route-bridged network.
Unicast mode on Token Ring has one limitation that should be
considered. If there are VRID routers on different source-route-
bridged segments, and there are host implementations that keep their
source-route information in the ND cache and do not listen to
gratuitous NDs, these hosts will not update their ND source-route
information correctly when a switchover occurs. The only possible
solution is to put all routers with the same VRID on the same source-
route-bridged segment and use techniques to prevent that bridge
segment from being a single point of failure. These techniques are
beyond the scope of this document.
For both the multicast and unicast mode of operation, VRRP
advertisements sent to 224.0.0.18 should be encapsulated as described
in [RFC1469].
A.3. Operation over ATM LANE
Operation of VRRP over ATM LANE on routers with ATM LANE interfaces
and/or routers behind proxy LAN Emulation Clients (LECs) are beyond
the scope of this document.
Authors' Addresses Authors' Addresses
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
United States of America United States of America
Email: acee@cisco.com Email: acee@cisco.com
Aditya Dogra Aditya Dogra
 End of changes. 13 change blocks. 
152 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/