draft-ietf-vrrp-ipv6-spec-03.txt   draft-ietf-vrrp-ipv6-spec-04.txt 
INTERNET-DRAFT R. Hinden/Nokia INTERNET-DRAFT R. Hinden/Nokia
December 5, 2002 May 20, 2003
Virtual Router Redundancy Protocol for IPv6 Virtual Router Redundancy Protocol for IPv6
<draft-ietf-vrrp-ipv6-spec-03.txt> <draft-ietf-vrrp-ipv6-spec-04.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 June 5, 2003. This internet draft expires on November 20, 2003.
Abstract Abstract
This memo defines the Virtual Router Redundancy Protocol (VRRP) for This memo defines the Virtual Router Redundancy Protocol (VRRP) for
IPv6. It is version three (3) of the protocol. It is based on the IPv6. It is version three (3) of the protocol. It is based on the
original version of VRRP (version 2) for IPv4 that is defined in original version of VRRP (version 2) for IPv4 that is defined in
RFC2338. RFC2338.
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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
The advantage gained from using VRRP for IPv6 is a quicker switch The advantage gained from using VRRP for IPv6 is a quicker switch
over to back up routers than can be obtained with standard IPv6 over to back up routers than can be obtained with standard IPv6
Neighbor Discovery [ND] mechanisms. Neighbor Discovery [ND] mechanisms.
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction................................................3
2. Required Features...........................................5 2. Required Features...........................................5
3. VRRP Overview...............................................6 3. VRRP Overview...............................................6
4. Sample Configurations.......................................8 4. Sample Configurations.......................................8
5. Protocol...................................................11 5. Protocol...................................................10
5.1 VRRP Packet Format....................................11 5.1 VRRP Packet Format....................................10
5.2 IP Field Descriptions.................................11 5.2 IP Field Descriptions.................................10
5.3 VRRP Field Descriptions...............................12 5.3 VRRP Field Descriptions...............................11
6. Protocol State Machine....................................15 6. Protocol State Machine....................................13
6.1 Parameters per Virtual Router.........................15 6.1 Parameters per Virtual Router.........................13
6.2 Timers................................................16 6.2 Timers................................................14
6.3 State Transition Diagram..............................16 6.3 State Transition Diagram..............................14
6.4 State Descriptions....................................16 6.4 State Descriptions....................................14
7. Sending and Receiving VRRP Packets........................21 7. Sending and Receiving VRRP Packets........................18
7.1 Receiving VRRP Packets................................21 7.1 Receiving VRRP Packets................................18
7.2 Transmitting Packets..................................21 7.2 Transmitting Packets..................................18
7.3 Virtual MAC Address...................................22 7.3 Virtual MAC Address...................................19
7.4 IPv6 Interface Identifiers............................22 7.4 IPv6 Interface Identifiers............................19
8. Operational Issues........................................23 8. Operational Issues........................................20
8.1 ICMPv6 Redirects......................................23 8.1 ICMPv6 Redirects......................................20
8.2 ND Neighbor Solicitation..............................23 8.2 ND Neighbor Solicitation..............................20
8.3 Potential Forwarding Loop.............................24 8.3 Potential Forwarding Loop.............................21
9. Operation over FDDI, Token Ring, and ATM LANE.............24 9. Operation over FDDI, Token Ring, and ATM LANE.............21
9.1 Operation over FDDI...................................24 9.1 Operation over FDDI...................................21
9.2 Operation over Token Ring.............................24 9.2 Operation over Token Ring.............................21
9.3 Operation over ATM LANE...............................25 9.3 Operation over ATM LANE...............................23
10. Security Considerations...................................26 10. Security Considerations...................................24
10.1 No Authentication....................................27 11. Acknowledgments...........................................24
10.2 Simple Text Password.................................27 12. IANA Considerations.......................................24
10.3 IP Authentication Header.............................28 13. Normative References......................................25
11. Intellectual Property.....................................28 14. Informative References....................................26
12. Acknowledgments...........................................29 15. Authors' Address..........................................26
13. IANA Considerations.......................................29 16. Changes from RFC2338......................................26
14. References................................................29
15. Authors' Address..........................................31
16. Changes from RFC2338......................................31
1. Introduction 1. Introduction
IPv6 hosts on a LAN will usually learn about one or more default IPv6 hosts on a LAN will usually learn about one or more default
routers by receiving Router Advertisements sent using the IPv6 routers by receiving Router Advertisements sent using the IPv6
Neighbor Discovery protocol [ND]. The Router Advertisements are Neighbor Discovery protocol [ND]. The Router Advertisements are
multicast periodically at a rate that the hosts will learn about the multicast periodically at a rate that the hosts will learn about the
default routers in a few minutes. They are not sent frequently enough default routers in a few minutes. They are not sent frequently enough
to rely on the absence of the router advertisement to detect router to rely on the absence of the router advertisement to detect router
failures. failures.
skipping to change at page 6, line 19 skipping to change at page 6, line 19
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 IPv6 packets on a multiaccess LAN requires mapping from an Sending IPv6 packets on a multiaccess LAN requires mapping from an
IPv6 address to a MAC address. The use of the virtual router MAC IPv6 address to a MAC address. The use of the virtual router MAC
address in an extended LAN employing learning bridges can have a address in an extended LAN employing learning bridges can have a
significant effect on the bandwidth overhead of packets sent to the significant effect on the bandwidth overhead of packets sent to the
virtual router. If the virtual router MAC address is never used as virtual router. If the virtual router MAC address is never used as
the source address in a link level frame then the station location is the 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 33 skipping to change at page 7, line 22
attempt to preempt the Master unless it has higher priority. This attempt to preempt 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 available. It's also possible to administratively prohibit all
preemption attempts. The only exception is that a VRRP router will preemption attempts. The only exception is that a VRRP router will
always become Master of any virtual router associated with address it always become Master of any virtual router associated with address it
owns. If the Master becomes unavailable then the highest priority 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 11, line 24 skipping to change at page 10, line 31
5.1 VRRP Packet Format 5.1 VRRP Packet Format
This section defines the format of the VRRP packet and the relevant This section defines the format of the VRRP packet and the relevant
fields in the IPv6 header. fields in the IPv6 header.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority | (reserved) | |Version| Type | Virtual Rtr ID| Priority | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Adver Int | Checksum | | (reserved) | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ IPv6 Address + + IPv6 Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 IPv6 Field Descriptions 5.2 IPv6 Field Descriptions
5.2.1 Source Address 5.2.1 Source Address
The IPv6 link-local address of the interface the packet is being sent The IPv6 link-local address of the interface the packet is being sent
from. from.
5.2.2 Destination Address 5.2.2 Destination Address
skipping to change at page 13, line 15 skipping to change at page 12, line 22
The priority value zero (0) has special meaning indicating that the The priority value zero (0) has special meaning indicating that the
current Master has stopped participating in VRRP. This is used to current Master has stopped participating in VRRP. This is used to
trigger Backup routers to quickly transition to Master without having trigger Backup routers to quickly transition to Master without having
to wait for the current Master to timeout. to wait for the current Master to timeout.
5.3.5 Reserved 5.3.5 Reserved
This field MUST be set to zero on transmission and ignored on This field MUST be set to zero on transmission and ignored on
reception. reception.
5.3.6 Authentication Type 5.3.5 Reserved
The authentication type field identifies the authentication method
being utilized. Authentication type is unique on a Virtual Router
basis. The authentication type field is an 8 bit unsigned integer.
A packet with unknown authentication type or that does not match the
locally configured authentication method MUST be discarded.
The authentication methods currently defined are:
0 - No Authentication
1 - Simple Text Password
2 - IP Authentication Header
5.3.6.1 No Authentication
The use of this authentication type means that VRRP protocol This field MUST be set to zero on transmission and ignored on
exchanges are not authenticated. The contents of the Authentication
Data field should be set to zero on transmission and ignored on
reception. reception.
5.3.6.2 Simple Text Password 5.3.6 Advertisement Interval (Adver Int)
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
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]. Keys may be either configured manually or via a key
distribution protocol.
If a packet is received that does not pass the authentication check
due to a missing authentication header or incorrect message digest,
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)
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.7 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
message. message.
The checksum is the 16-bit one's complement of the one's complement The checksum is the 16-bit one's complement of the one's complement
sum of the entire VRRP message starting with the version field and a sum of the entire VRRP message starting with the version field and a
"pseudo-header" as defined in section 8.1 of RFC2460 [IPv6]. The "pseudo-header" as defined in section 8.1 of RFC2460 [IPv6]. The
next header field in the "pseudo-header" should be set to 112 next header field in the "pseudo-header" should be set to 112
(decimal) for VRRP. For computing the checksum, the checksum field (decimal) for VRRP. For computing the checksum, the checksum field
is set to zero. See RFC1071 for more detail [CKSM]. is set to zero. See RFC1071 for more detail [CKSM].
5.3.9 IPv6 Address 5.3.8 IPv6 Address
The IPv6 link-local address associated with the virtual router. The IPv6 link-local address associated with the virtual router.
5.3.10 Authentication Data
The authentication string is currently only utilized for simple text
authentication, similar to the simple text authentication found in
the Open Shortest Path First routing protocol [OSPF]. It is up to 8
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
router in Master election for this virtual router in Master election for this virtual
skipping to change at page 16, line 5 skipping to change at page 14, line 5
router preempts a lower priority Master. router preempts a lower priority Master.
Values are True to allow preemption and Values are True to allow preemption and
False to prohibit preemption. Default is False to prohibit preemption. Default is
True. True.
Note: Exception is that the router that owns Note: Exception is that the router that owns
the IPv6 address associated with the virtual the IPv6 address associated with the virtual
router always preempts independent of the router always preempts independent of the
setting of this flag. setting of this flag.
Authentication_Type Type of authentication being used. Values
are defined in section 5.3.6.
Authentication_Data Authentication data specific to the
Authentication_Type being used.
6.2 Timers 6.2 Timers
Master_Down_Timer Timer that fires when ADVERTISEMENT has not Master_Down_Timer Timer that fires when ADVERTISEMENT has not
been heard for Master_Down_Interval. been heard for Master_Down_Interval.
Adver_Timer Timer that fires to trigger sending of Adver_Timer Timer that fires to trigger sending of
ADVERTISEMENT based on ADVERTISEMENT based on
Advertisement_Interval. Advertisement_Interval.
6.3 State Transition Diagram 6.3 State Transition Diagram
skipping to change at page 21, line 14 skipping to change at page 18, line 14
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 IPv6 Hop Limit is 255. - MUST verify that the IPv6 Hop Limit is 255.
- MUST verify the VRRP version is 3 - MUST verify the VRRP version is 3
- MUST verify that the received packet contains the complete VRRP - MUST verify that the received packet contains the complete VRRP
packet (including fixed fields, IPv6 Address, and Authentication packet (including fixed fields, and IPv6 Address.
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 IPv6 Address owner interface and the local router is not the IPv6 Address owner
(Priority equals 255 (decimal)). (Priority equals 255 (decimal)).
- MUST verify that the Auth Type matches the locally configured
authentication method for the virtual router and perform that
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 the IPv6 Address matches the IPv6_Address - MAY verify that the IPv6 Address matches the IPv6_Address
configured for the VRID. 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 27, line 7 skipping to change at page 24, 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 for IPv6 does not include any type of authentication. Earlier
employ different security policies. The protocol includes several versions of VRRP for IPv4 specification included several types of
authentication methods ranging from no authentication, simple clear authentication ranging from none to strong [VRRP-V4].
text passwords, and strong authentication using IP Authentication
with MD5 HMAC. The details on each approach including possible
attacks and recommended environments follows.
Independent of any authentication type VRRP includes a mechanism
(setting TTL=255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits most
vulnerabilities to local attacks.
The security measures discussed in the following sections only
provide various kinds of authentication. No confidentiality is
provided. Confidentiality is not necessary for the correct operation
of VRRP and there is no information in the VRRP messages that must be
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 Operational experience and further analysis determined that these did
are authenticated using the mechanisms defined by the IP not provide any real measure of security and do to the nature of the
Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP VRRP protocol they did not prevent incorrectly configured or hostile
and AH", [HMAC]. This provides strong protection against routers from becoming VRRP masters. In general on LANs any device on
configuration errors, replay attacks, and packet the LAN has the ability to disrupt all communication. For example
corruption/modification. although securing VRRP prevents unauthorized machines from taking
part in the election protocol, it does not protect hosts on the
network from being deceived. A gratuitous ND reply from what
purports to be the virtual router's IPv6 address can redirect traffic
to an unauthorized machine. Similarly, individual connections can be
diverted by means of forged ICMPv6 Redirect messages. 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.
This type of authentication is RECOMMENDED when there is limited VRRP includes a mechanism (setting TTL=255, checking on receipt) that
control over the administration of nodes on a LAN. While this type protects against VRRP packets being injected from another remote
of authentication does protect the operation of VRRP, there are other network. This limits most vulnerabilities to local attacks.
types of attacks that may be employed on shared media links (e.g.,
generation of bogus ND replies) that are independent from VRRP and
are not protected.
Specifically, although securing VRRP prevents unauthorized machines VRRP does not provide any confidentiality. Confidentiality is not
from taking part in the election protocol, it does not protect hosts necessary for the correct operation of VRRP and there is no
on the network from being deceived. For example, a gratuitous ND information in the VRRP messages that must be kept secret from other
reply from what purports to be the virtual router's IPv6 address can nodes on the LAN.
redirect traffic to an unauthorized machine. Similarly, individual
connections can be diverted by means of forged ICMPv6 Redirect
messages.
11. Acknowledgments 11. Acknowledgments
This specification is based on RFC2238. The authors of RFC2238 are This specification is based on RFC2238. The authors of RFC2238 are
S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P.
Higginson, M. Shand, and A. Lindem. Higginson, M. Shand, and A. Lindem.
The author of this document would also like to thank Erik Nordmark, The author of this document would also like to thank Erik Nordmark,
Thomas Narten, and Steve Deering for their his helpful suggestions. Thomas Narten, and Steve Deering for their his helpful suggestions.
skipping to change at page 28, line 46 skipping to change at page 25, line 4
The author of this document would also like to thank Erik Nordmark, The author of this document would also like to thank Erik Nordmark,
Thomas Narten, and Steve Deering for their his helpful suggestions. Thomas Narten, and Steve Deering for their his helpful suggestions.
12. IANA Considerations 12. IANA Considerations
VRRP for IPv6 needs an IPv6 link-local scope multicast address VRRP for IPv6 needs an IPv6 link-local scope multicast address
assigned by the IANA for this specification. The IPv6 multicast assigned by the IANA for this specification. The IPv6 multicast
address should be of the following form: address should be of the following form:
FF02:0:0:0:0:0:XXXX:XXXX FF02:0:0:0:0:0:XXXX:XXXX
The values assigned address should be entered into section 5.2.2. The values assigned address should be entered into section 5.2.2.
A convenient assignment of this link-local scope multicast would be: A convenient assignment of this link-local scope multicast would be:
FF02:0:0:0:0:0:0:12 FF02:0:0:0:0:0:0:12
as this would be consistent with the IPv4 assignment for VRRP. as this would be consistent with the IPv4 assignment for VRRP.
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.
[ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing [ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing
Architecture", Internet Draft, <draft-ietf-ipngwg-addr- Architecture", Internet Draft, <draft-ietf-ipngwg-addr-
arch-v3-11.txt>, October 2002. arch-v3-11.txt>, October 2002.
[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.
[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
Router Protocol (HSRP)", RFC2281, March 1998.
[ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol [ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", (ICMPv6) for the Internet Protocol Version 6 (IPv6)",
RFC2463, December 1998. RFC2463, December 1998.
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
Provide Fast Failover in IP Networks", Digital Technical
Journal, Volume 9 Number 3, Winter 1997.
[IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998. (IPv6) Specification", RFC2460, December 1998.
[IPX] Novell Incorporated., "IPX Router Specification", Version [IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992. 1.10, October 1992.
[ND] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery [ND] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC2461, December 1998. for IP Version 6 (IPv6)", RFC2461, December 1998.
[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.
[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).
[VRRP-V4] Knight, S., et. al., "Virtual Router Redundancy Protocol", [VRRP-V4] Knight, S., et. al., "Virtual Router Redundancy Protocol",
RFC2338, April 1998. RFC2338, April 1998.
14. Author's Address 14. Informative References
Robert Hinden Phone: +1 650 625-2004 [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby
Nokia EMail: hinden@iprg.nokia.com Router Protocol (HSRP)", RFC2281, March 1998.
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
Provide Fast Failover in IP Networks", Digital Technical
Journal, Volume 9 Number 3, Winter 1997.
[OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998.
[RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November
1998.
15. Author's Address
Robert Hinden
Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
15. Changes from RFC2338 Phone: +1 650 625-2004
EMail: hinden@iprg.nokia.com
16. Changes from RFC2338
- Removed different authentication methods, header fields, and
updated the security considerations section.
- General rewrite to change protocol to provide virtual router - General rewrite to change protocol to provide virtual router
functionality from IPv4 to IPv6. Specific changes include: functionality from IPv4 to IPv6. Specific changes include:
o Increment VRRP version to 3. o Increment VRRP version to 3.
o Change packet format to support an 128-bit IPv6 address. o Change packet format to support an 128-bit IPv6 address.
o Change to only support one router address (instead of multiple o Change to only support one router address (instead of multiple
addresses). This included removing address count field from addresses). This included removing address count field from
header. header.
o Rewrote text to specify IPv6 Neighbor Discovery mechanisms o Rewrote text to specify IPv6 Neighbor Discovery mechanisms
instead of ARP. instead of ARP.
o Changed state machine actions to use Neighbor Discovery o Changed state machine actions to use Neighbor Discovery
skipping to change at page 31, line 15 skipping to change at page 27, line 18
- 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.
- Clarified text describing VRID verification check. - Clarified text describing VRID verification check.
- Added new subsection (8.4) describing need to not forward packets - Added new subsection (8.4) describing need to not forward packets
for adopted IPv6 addresses. for adopted IPv6 addresses.
- Added clarification to the security considerations section. - Added clarification to the security considerations section.
- Added reference for computing the internet checksum. - Added reference for computing the internet checksum.
- Updated references and author information. - Updated references and author information.
- Removed IPR section as no IPR claims have been made agains this - Removed IPR section as no IPR claims have been made against this
draft. draft.
 End of changes. 

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