draft-ietf-vrrp-spec-v2-06.txt   draft-ietf-vrrp-spec-v2-07.txt 
INTERNET-DRAFT R. Hinden INTERNET-DRAFT R. Hinden
February 28, 2002 D. Mitzel May 20, 2003 P. Hunt
P. Hunt
Nokia Nokia
D. Mitzel
Tahoe
P. Higginson P. Higginson
M. Shand M. Shand
Digital Equipment Corp. Cisco
A. Lindem A. Lindem
IBM Corporation Redback
S. Knight S. Knight
Ascend
D. Weaver D. Weaver
Ascend Communications, Inc. PowerWAN
D. Whipple D. Whipple
Microsoft, Inc. Microsoft
Virtual Router Redundancy Protocol Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-v2-06.txt> <draft-ietf-vrrp-spec-v2-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This internet draft expires on August 28, 2002. This internet draft expires on November 20, 2003.
Abstract Abstract
This memo defines the Virtual Router Redundancy Protocol (VRRP). This memo defines the Virtual Router Redundancy Protocol (VRRP).
VRRP specifies an election protocol that dynamically assigns VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a responsibility for a virtual router to one of the VRRP routers on a
LAN. The VRRP router controlling the IP address(es) associated with LAN. The VRRP router controlling the IP address(es) associated with
a virtual router is called the Master, and forwards packets sent to a virtual router is called the Master, and forwards packets sent to
these IP addresses. The election process provides dynamic fail over these IP addresses. The election process provides dynamic fail over
in the forwarding responsibility should the Master become in the forwarding responsibility should the Master become
unavailable. This allows any of the virtual router IP addresses on unavailable. This allows any of the virtual router IP addresses on
the LAN to be used as the default first hop router by end-hosts. The the LAN to be used as the default first hop router by end-hosts. The
advantage gained from using VRRP is a higher availability default advantage gained from using VRRP is a higher availability default
path without requiring configuration of dynamic routing or router path without requiring configuration of dynamic routing or router
discovery protocols on every end-host. discovery protocols on every end-host.
This document replaces RFC2338 "Virtual Router Redundancy Protocol".
RFC2338 will become historic.
Table of Contents Table of Contents
1. Introduction...............................................3 1. Introduction...............................................4
2. Required Features..........................................5 2. Required Features..........................................6
3. VRRP Overview..............................................7 3. VRRP Overview..............................................7
4. Sample Configurations......................................8 4. Sample Configurations......................................9
5. Protocol..................................................11 5. Protocol..................................................11
5.1 VRRP Packet Format....................................11 5.1 VRRP Packet Format....................................11
5.2 IP Field Descriptions.................................11 5.2 IP Field Descriptions.................................12
5.3 VRRP Field Descriptions...............................12 5.3 VRRP Field Descriptions...............................12
6. Protocol State Machine....................................15 6. Protocol State Machine....................................14
6.1 Parameters per Virtual Router.........................15 6.1 Parameters per Virtual Router.........................14
6.2 Timers................................................16 6.2 Timers................................................16
6.3 State Transition Diagram..............................16 6.3 State Transition Diagram..............................16
6.4 State Descriptions....................................16 6.4 State Descriptions....................................16
7. Sending and Receiving VRRP Packets........................20 7. Sending and Receiving VRRP Packets........................20
7.1 Receiving VRRP Packets................................20 7.1 Receiving VRRP Packets................................20
7.2 Transmitting Packets..................................20 7.2 Transmitting Packets..................................20
7.3 Virtual MAC Address...................................21 7.3 Virtual MAC Address...................................21
8. Operational Issues........................................22 8. Operational Issues........................................22
8.1 ICMP Redirects........................................22 8.1 ICMP Redirects........................................22
8.2 Host ARP Requests.....................................22 8.2 Host ARP Requests.....................................22
8.3 Proxy ARP.............................................22 8.3 Proxy ARP.............................................22
8.4 Potential Forwarding Loop.............................23 8.4 Potential Forwarding Loop.............................23
9. Operation over FDDI, Token Ring, and ATM LANE.............23 9. Operation over FDDI, Token Ring, and ATM LANE.............23
9.1 Operation over FDDI...................................23 9.1 Operation over FDDI...................................23
9.2 Operation over Token Ring.............................23 9.2 Operation over Token Ring.............................23
9.3 Operation over ATM LANE...............................25 9.3 Operation over ATM LANE...............................25
10. Security Considerations...................................26 10. Security Considerations...................................26
10.1 No Authentication....................................26 11. Intellectual Property.....................................26
10.2 Simple Text Password.................................26 12. Acknowledgments...........................................27
10.3 IP Authentication Header.............................27 13. Normative References......................................27
11. Intellectual Property.....................................28 14. Informative References....................................28
12. Acknowledgments...........................................28 15. Authors' Addresses........................................28
13. References................................................28 16. Changes from RFC2338......................................31
14. Authors' Addresses........................................29
15. Changes from RFC2338......................................32
1. Introduction 1. Introduction
There are a number of methods that an end-host can use to determine There are a number of methods that an end-host can use to determine
its first hop router towards a particular IP destination. These its first hop router towards a particular IP destination. These
include running (or snooping) a dynamic routing protocol such as include running (or snooping) a dynamic routing protocol such as
Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running
an ICMP router discovery client [DISC] or using a statically an ICMP router discovery client [DISC] or using a statically
configured default route. configured default route.
skipping to change at page 6, line 25 skipping to change at page 7, line 25
disruption in service. The protocol should ensure after Master disruption in service. The protocol should ensure after Master
election that no state transition is triggered by any Backup router election that no state transition is triggered by any Backup router
of equal or lower preference as long as the Master continues to of equal or lower preference as long as the Master continues to
function properly. function properly.
Some environments may find it beneficial to avoid the state Some environments may find it beneficial to avoid the state
transition triggered when a router becomes available that is more transition triggered when a router becomes available that is more
preferential than the current Master. It may be useful to support an preferential than the current Master. It may be useful to support an
override of the immediate convergence to the preferred path. override of the immediate convergence to the preferred path.
2.4 Extensible Security 2.4 Efficient Operation over Extended LANs
The virtual router functionality is applicable to a wide range of
internetworking environments that may employ different security
policies. The protocol should require minimal configuration and
overhead in the insecure operation, provide for strong authentication
when increased security is required, and allow integration of new
security mechanisms without breaking backwards compatible operation.
2.5 Efficient Operation over Extended LANs
Sending IP packets on a multiaccess LAN requires mapping from an IP Sending IP packets on a multiaccess LAN requires mapping from an IP
address to a MAC address. The use of the virtual router MAC address address to a MAC address. The use of the virtual router MAC address
in an extended LAN employing learning bridges can have a significant in an extended LAN employing learning bridges can have a significant
effect on the bandwidth overhead of packets sent to the virtual effect on the bandwidth overhead of packets sent to the virtual
router. If the virtual router MAC address is never used as the router. If the virtual router MAC address is never used as the
source address in a link level frame then the station location is source address in a link level frame then the station location is
never learned, resulting in flooding of all packets sent to the never learned, resulting in flooding of all packets sent to the
virtual router. To improve the efficiency in this environment the virtual router. To improve the efficiency in this environment the
protocol should: 1) use the virtual router MAC as the source in a protocol should: 1) use the virtual router MAC as the source in a
skipping to change at page 7, line 39 skipping to change at page 8, line 30
attempt to pre-empt the Master unless it has higher priority. This attempt to pre-empt the Master unless it has higher priority. This
eliminates service disruption unless a more preferred path becomes eliminates service disruption unless a more preferred path becomes
available. It's also possible to administratively prohibit all pre- available. It's also possible to administratively prohibit all pre-
emption attempts. The only exception is that a VRRP router will emption attempts. The only exception is that a VRRP router will
always become Master of any virtual router associated with addresses always become Master of any virtual router associated with addresses
it owns. If the Master becomes unavailable then the highest priority it owns. If the Master becomes unavailable then the highest priority
Backup will transition to Master after a short delay, providing a Backup will transition to Master after a short delay, providing a
controlled transition of the virtual router responsibility with controlled transition of the virtual router responsibility with
minimal service interruption. minimal service interruption.
VRRP defines three types of authentication providing simple
deployment in insecure environments, added protection against
misconfiguration, and strong sender authentication in security
conscious environments. Analysis of the protection provided and
vulnerability of each mechanism is deferred to Section 10.0 Security
Considerations. In addition new authentication types and data can be
defined in the future without affecting the format of the fixed
portion of the protocol packet, thus preserving backward compatible
operation.
The VRRP protocol design provides rapid transition from Backup to The VRRP protocol design provides rapid transition from Backup to
Master to minimize service interruption, and incorporates Master to minimize service interruption, and incorporates
optimizations that reduce protocol complexity while guaranteeing optimizations that reduce protocol complexity while guaranteeing
controlled Master transition for typical operational scenarios. The controlled Master transition for typical operational scenarios. The
optimizations result in an election protocol with minimal runtime optimizations result in an election protocol with minimal runtime
state requirements, minimal active protocol states, and a single state requirements, minimal active protocol states, and a single
message type and sender. The typical operational scenarios are message type and sender. The typical operational scenarios are
defined to be two redundant routers and/or distinct path preferences defined to be two redundant routers and/or distinct path preferences
among each router. A side effect when these assumptions are violated among each router. A side effect when these assumptions are violated
(i.e., more than two redundant paths all with equal preference) is (i.e., more than two redundant paths all with equal preference) is
skipping to change at page 13, line 22 skipping to change at page 13, line 35
The number of IP addresses contained in this VRRP advertisement. The number of IP addresses contained in this VRRP advertisement.
5.3.6 Authentication Type 5.3.6 Authentication Type
The authentication type field identifies the authentication method The authentication type field identifies the authentication method
being utilized. Authentication type is unique on a Virtual Router being utilized. Authentication type is unique on a Virtual Router
basis. The authentication type field is an 8 bit unsigned integer. basis. The authentication type field is an 8 bit unsigned integer.
A packet with unknown authentication type or that does not match the A packet with unknown authentication type or that does not match the
locally configured authentication method MUST be discarded. locally configured authentication method MUST be discarded.
Note: Earlier version of the VRRP specification had several defined
authentication types [RFC2338]. These were removed in this
specification because operational experience showed that they did not
provide any real security and would only cause multiple masters to be
created.
The authentication methods currently defined are: The authentication methods currently defined are:
0 - No Authentication 0 - No Authentication
1 - Simple Text Password 1 - Reserved
2 - IP Authentication Header 2 - Reserved
5.3.6.1 No Authentication 5.3.6.1 Authentication Type 0 - No Authentication
The use of this authentication type means that VRRP protocol The use of this authentication type means that VRRP protocol
exchanges are not authenticated. The contents of the Authentication exchanges are not authenticated. The contents of the Authentication
Data field should be set to zero on transmission and ignored on Data field should be set to zero on transmission and ignored on
reception. reception.
5.3.6.2 Simple Text Password 5.3.6.2 Authentication Type 1 - Reserved
The use of this authentication type means that VRRP protocol
exchanges are authenticated by a clear text password. The contents
of the Authentication Data field should be set to the locally
configured password on transmission. There is no default password.
The receiver MUST check that the Authentication Data in the packet
matches its configured authentication string. Packets that do not
match MUST be discarded.
Note that there are security implications to using Simple Text
password authentication, and one should see the Security
Consideration section of this document.
5.3.6.3 IP Authentication Header This authentication type is reserved to maintain backwards
compatibility with RFC2338.
The use of this authentication type means the VRRP protocol exchanges 5.3.6.3 Authentication Type 2 - Reserved
are authenticated using the mechanisms defined by the IP
Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
and AH" [HMAC]. Keys may be either configured manually or via a key
distribution protocol.
If a packet is received that does not pass the authentication check This authentication type is reserved to maintain backwards
due to a missing authentication header or incorrect message digest, compatibility with RFC2338.
then the packet MUST be discarded. The contents of the
Authentication Data field should be set to zero on transmission and
ignored on reception.
5.3.7 Advertisement Interval (Adver Int) 5.3.7 Advertisement Interval (Adver Int)
The Advertisement interval indicates the time interval (in seconds) The Advertisement interval indicates the time interval (in seconds)
between ADVERTISEMENTS. The default is 1 second. This field is used between ADVERTISEMENTS. The default is 1 second. This field is used
for troubleshooting misconfigured routers. for troubleshooting misconfigured routers.
5.3.8 Checksum 5.3.8 Checksum
The checksum field is used to detect data corruption in the VRRP The checksum field is used to detect data corruption in the VRRP
skipping to change at page 14, line 39 skipping to change at page 14, line 40
5.3.9 IP Address(es) 5.3.9 IP Address(es)
One or more IP addresses that are associated with the virtual router. One or more IP addresses that are associated with the virtual router.
The number of addresses included is specified in the "Count IP Addrs" The number of addresses included is specified in the "Count IP Addrs"
field. These fields are used for troubleshooting misconfigured field. These fields are used for troubleshooting misconfigured
routers. routers.
5.3.10 Authentication Data 5.3.10 Authentication Data
The authentication string is currently only utilized for simple text The authentication string is currently only used to maintain
authentication, similar to the simple text authentication found in backwards compatibility with RFC2338. It SHOULD be set to zero on
the Open Shortest Path First routing protocol [OSPF]. It is up to 8 transmission and ignored on reception.
characters of plain text. If the configured authentication string is
shorter than 8 bytes, the remaining space MUST be zero-filled. Any
VRRP packet received with an authentication string that does not
match the locally configured authentication string MUST be discarded.
The authentication string is unique on a per interface basis.
There is no default value for this field.
6. Protocol State Machine 6. Protocol State Machine
6.1 Parameters per Virtual Router 6.1 Parameters per Virtual Router
VRID Virtual Router Identifier. Configured item VRID Virtual Router Identifier. Configured item
in the range 1-255 (decimal). There is no in the range 1-255 (decimal). There is no
default. default.
Priority Priority value to be used by this VRRP Priority Priority value to be used by this VRRP
skipping to change at page 20, line 12 skipping to change at page 20, line 12
endif endif
endif endif
7. Sending and Receiving VRRP Packets 7. Sending and Receiving VRRP Packets
7.1 Receiving VRRP Packets 7.1 Receiving VRRP Packets
Performed the following functions when a VRRP packet is received: Performed the following functions when a VRRP packet is received:
- MUST verify that the IP TTL is 255. - MUST verify that the IP TTL is 255.
- MUST verify the VRRP version is 2 - MUST verify the VRRP version is 2.
- MUST verify that the received packet contains the complete VRRP - MUST verify that the received packet contains the complete VRRP
packet (including fixed fields, IP Address(es), and packet (including fixed fields, IP Address(es), and
Authentication Data). Authentication Data).
- MUST verify the VRRP checksum - MUST verify the VRRP checksum.
- MUST verify that the VRID is configured on the receiving - MUST verify that the VRID is configured on the receiving
interface and the local router is not the IP Address owner interface and the local router is not the IP Address owner
(Priority equals 255 (decimal)). (Priority equals 255 (decimal)).
- MUST verify that the Auth Type matches the locally configured - MUST verify that the Auth Type matches the locally configured
authentication method for the virtual router and perform that authentication method for the virtual router and perform that
authentication method authentication method.
If any one of the above checks fails, the receiver MUST discard the If any one of the above checks fails, the receiver MUST discard the
packet, SHOULD log the event and MAY indicate via network management packet, SHOULD log the event and MAY indicate via network management
that an error occurred. that an error occurred.
- MAY verify that "Count IP Addrs" and the list of IP Address - MAY verify that "Count IP Addrs" and the list of IP Address
matches the IP_Addresses configured for the VRID matches the IP_Addresses configured for the VRID
If the above check fails, the receiver SHOULD log the event and MAY If the above check fails, the receiver SHOULD log the event and MAY
indicate via network management that a misconfiguration was detected. indicate via network management that a misconfiguration was detected.
skipping to change at page 26, line 7 skipping to change at page 26, line 7
in [RFC1469]. in [RFC1469].
9.3 Operation over ATM LANE 9.3 Operation over ATM LANE
Operation of VRRP over ATM LANE on routers with ATM LANE interfaces Operation of VRRP over ATM LANE on routers with ATM LANE interfaces
and/or routers behind proxy LEC's are beyond the scope of this and/or routers behind proxy LEC's are beyond the scope of this
document. document.
10. Security Considerations 10. Security Considerations
VRRP is designed for a range of internetworking environments that may VRRP does not currently include any type of authentication. Earlier
employ different security policies. The protocol includes several versions of the VRRP specification included several types of
authentication methods ranging from no authentication, simple clear authentication ranging from none to strong. Operational experience
text passwords, and strong authentication using IP Authentication and further analysis determined that these did not provide any real
with MD5 HMAC. The details on each approach including possible measure of security and do to the nature of the VRRP protocol they
attacks and recommended environments follows. did not prevent incorrectly configured or hostile routers from
becoming VRRP masters. In general do to the nature of LANs, any
device on the LAN has the ability to disrupt all communication.
Consequentially it was determined it was better to remove the
additional authentication methods in this specification of the VRRP
protocol as it did not provide the authentication originally
intended.
Independent of any authentication type VRRP includes a mechanism Independent of any authentication type VRRP includes a mechanism
(setting TTL=255, checking on receipt) that protects against VRRP (setting TTL=255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits most packets being injected from another remote network. This limits most
vulnerabilities to local attacks. vulnerabilities to local attacks.
The security measures discussed in the following sections only VRRP does not provide any confidentiality. Confidentiality is not
provide various kinds of authentication. No confidentiality is necessary for the correct operation of VRRP and there is no
provided. Confidentiality is not necessary for the correct operation information in the VRRP messages that must be kept secret from other
of VRRP and there is no information in the VRRP messages that must be nodes on the LAN.
kept secret from other nodes on the LAN.
10.1 No Authentication
The use of this authentication type means that VRRP protocol
exchanges are not authenticated. This type of authentication SHOULD
only be used in environments were there is minimal security risk and
little chance for configuration errors (e.g., two VRRP routers on a
LAN).
10.2 Simple Text Password
The use of this authentication type means that VRRP protocol
exchanges are authenticated by a simple clear text password.
This type of authentication is useful to protect against accidental
misconfiguration of routers on a LAN. It protects against routers
inadvertently backing up another router. A new router must first be
configured with the correct password before it can run VRRP with
another router. This type of authentication does not protect against
hostile attacks where the password can be learned by a node snooping
VRRP packets on the LAN. The Simple Text Authentication combined
with the TTL check makes it difficult for a VRRP packet to be sent
from another LAN to disrupt VRRP operation.
This type of authentication is RECOMMENDED when there is minimal risk
of nodes on a LAN actively disrupting VRRP operation. If this type
of authentication is used the user should be aware that this clear
text password is sent frequently, and therefore should not be the
same as any security significant password.
10.3 IP Authentication Header
The use of this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP
Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
and AH", [HMAC]. This provides strong protection against
configuration errors, replay attacks, and packet
corruption/modification.
This type of authentication is RECOMMENDED when there is limited
control over the administration of nodes on a LAN. While this type
of authentication does protect the operation of VRRP, there are other
types of attacks that may be employed on shared media links (e.g.,
generation of bogus ARP replies) that are independent from VRRP and
are not protected.
Specifically, although securing VRRP prevents unauthorized machines
from taking part in the election protocol, it does not protect hosts
on the network from being deceived. For example, a gratuitous ARP
reply from what purports to be the virtual router's IP address can
redirect traffic to an unauthorized machine. Similarly, individual
connections can be diverted by means of forged ICMP Redirect
messages.
11. Intellectual Property 11. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 28, line 39 skipping to change at page 27, line 17
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
12. Acknowledgments 12. Acknowledgments
The authors would like to thank Glen Zorn, and Michael Lane, Clark The authors would like to thank Glen Zorn, and Michael Lane, Clark
Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve
Bellovin, Thomas Narten, Rob Montgomery, and Rob Coltun for their Bellovin, Thomas Narten, Rob Montgomery, and Rob Coltun for their
comments and suggestions. comments and suggestions.
13. References 13. Normative References
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
802.1D, 1993 edition. 802.1D, 1993 edition.
[AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
[CKSM] Braden, R., D. Borman, C. Partridge, "Computing the [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC1071, September 1988. Internet Checksum", RFC1071, September 1988.
[DISC] Deering, S., "ICMP Router Discovery Messages", RFC1256,
September 1991.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC2131,
March 1997.
[HMAC] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH", RFC2403, November 1998.
[HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby
Router Protocol (HSRP)", RFC2281, March 1998. Router Protocol (HSRP)", RFC2281, March 1998.
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
Provide Fast Failover in IP Networks", Digital Technical Provide Fast Failover in IP Networks", Digital Technical
Journal, Volume 9 Number 3, Winter 1997. Journal, Volume 9 Number 3, Winter 1997.
[IPX] Novell Incorporated., "IPX Router Specification", Version [IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992. 1.10, October 1992.
[OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998.
[RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November
1998.
[RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area
Networks", RFC1469, June 1993. Networks", RFC1469, June 1993.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC2026, BCP00009, October 1996. 3", RFC2026, BCP00009, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP0014, March 1997. Requirement Levels", RFC2119, BCP0014, March 1997.
[RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol",
RFC2338, April 1998.
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
SC30-3374-02, Third Edition, (September, 1989). SC30-3374-02, Third Edition, (September, 1989).
14. Author's Addresses 14. Informative References
P. Higginson Phone: +44 118 920 6293 [DISC] Deering, S., "ICMP Router Discovery Messages", RFC1256,
Digital Equipment Corp. EMail: higginson@mail.dec.com September 1991.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC2131,
March 1997.
[OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998.
[RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November
1998.
15. Author's Addresses
P. Higginson
Digital Equipment Corp.
Digital Park Digital Park
Imperial Way Imperial Way
Reading Reading
Berkshire Berkshire
RG2 0TE RG2 0TE
UK UK
Robert Hinden Phone: +1 650 625-2004 Phone: +44 118 920 6293
Nokia EMail: hinden@iprg.nokia.com Email: higginson@mail.dec.com
Robert Hinden
Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA US
Phone: +1 650 625-2004
Email: hinden@iprg.nokia.com
Peter Hunt Phone: +1 650 625-2093 Peter Hunt
Nokia EMail: hunt@iprg.nokia.com Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA US
Phone: +1 650 625-2093
Steven Knight Phone: +1 612 943-8990 Email: hunt@iprg.nokia.com
Ascend Communications EMail: Steven.Knight@ascend.com Steven Knight
Ascend Communications
High Performance Network Division High Performance Network Division
10250 Valley View Road, Suite 113 10250 Valley View Road, Suite 113
Eden Prairie, MN USA 55344 Eden Prairie, MN USA 55344
USA US
Phone: +1 612 943-8990
Email: Steven.Knight@ascend.com
Acee Lindem Phone: 1-919-254-1805 Acee Lindem
IBM Corporation E-Mail: acee@raleigh.ibm.com Redback Networks
P.O. Box 12195 102 Carric Bend Court
Research Triangle Park, NC 27709 Apex, NC 27502 USA
USA US
Email: acee@redback.com
Danny Mitzel Phone: +1 650 625-2037 Danny J. Mitzel
Nokia EMail: mitzel@iprg.nokia.com Tahoe Networks
313 Fairchild Drive 3052 Orchard Drive
Mountain View, CA 94043 San Jose, CA 95134
USA US
Phone: +1 408 944 8611
Email: mitzel@tahoenetworks.com
M. Shand Phone: +44 118 920 4424 Mike Shand
Digital Equipment Corp. EMail: shand@mail.dec.com Cisco Systems
Digital Park Reading - Green Park 250
Imperial Way 250 Longwater Avenue
Reading Reading
Berkshire BERKSHIRE
RG2 0TE United Kingdom
UK RG2 6GB
Phone: +44 (0)20 8824-8690
Email: mshand@cisco.com
Douglas Weaver Phone: +1 612 943-8990 Douglas Weaver
Ascend Communications EMail: Doug.Weaver@ascend.com PowerWAN, Inc.
High Performance Network Division 6595 Edenvale Blvd, Suite 180
10250 Valley View Road, Suite 113 Eden Prairie, MN 55346
Eden Prairie, MN USA 55344 US
USA Phone: +1 952 937-0056
David Whipple Phone: +1 206 703-3876 Email: dweaver@powerwan.com
Microsoft Corporation EMail: dwhipple@microsoft.com David Whipple
Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA US
Phone: +1 206 703-3876
Email: dwhipple@microsoft.com
14. Changes from RFC2338 16. Changes from RFC2338
- Removed authentication methods from VRRP. Changes included:
o Removed the values for password and IPSEC based authentication.
The fields and values are retained to keep backwards
compatibility with RFC2338.
o Removed section on extensible security
o Updated security consideration section to remove discussion of
different authentication methods and added new text explaining
motivation for change.
- Revised the section 4 examples text with a clearer description of - Revised the section 4 examples text with a clearer description of
mapping of IP address owner, priorities, etc. mapping of IP address owner, priorities, etc.
- Clarify the section 7.1 text describing address list validation. - Clarify the section 7.1 text describing address list validation.
- Corrected text in Preempt_Mode definition. - Corrected text in Preempt_Mode definition.
- Changed authentication to be per Virtual Router instead of per - Changed authentication to be per Virtual Router instead of per
Interface. Interface.
- Added new subsection (9.3) stating that VRRP over ATM LANE is - Added new subsection (9.3) stating that VRRP over ATM LANE is
beyond the scope of this document. beyond the scope of this document.
- Clarified text describing received packet length check. - Clarified text describing received packet length check.
- Clarified text describing received authentication check. - Clarified text describing received authentication check.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/