draft-ietf-vrrp-ipv6-spec-06.txt   draft-ietf-vrrp-ipv6-spec-07.txt 
INTERNET-DRAFT R. Hinden/Nokia INTERNET-DRAFT R. Hinden/Nokia
February 13, 2004 September 28, 2004
Virtual Router Redundancy Protocol for IPv6 Virtual Router Redundancy Protocol for IPv6
<draft-ietf-vrrp-ipv6-spec-06.txt> <draft-ietf-vrrp-ipv6-spec-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 subject to all provisions
all provisions of Section 10 of [RFC2026]. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
Drafts. Internet-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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This internet draft expires on August 18, 2004. This internet draft expires on April 3, 2005.
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 28 skipping to change at page 3, line 28
6.3 State Transition Diagram..............................15 6.3 State Transition Diagram..............................15
6.4 State Descriptions....................................15 6.4 State Descriptions....................................15
7. Sending and Receiving VRRP Packets........................19 7. Sending and Receiving VRRP Packets........................19
7.1 Receiving VRRP Packets................................19 7.1 Receiving VRRP Packets................................19
7.2 Transmitting Packets..................................19 7.2 Transmitting Packets..................................19
7.3 Virtual MAC Address...................................20 7.3 Virtual MAC Address...................................20
7.4 IPv6 Interface Identifiers............................20 7.4 IPv6 Interface Identifiers............................20
8. Operational Issues........................................21 8. Operational Issues........................................21
8.1 ICMPv6 Redirects......................................21 8.1 ICMPv6 Redirects......................................21
8.2 ND Neighbor Solicitation..............................21 8.2 ND Neighbor Solicitation..............................21
8.3 Potential Forwarding Loop.............................22 8.3 Router Advertisements.................................21
8.4 Recommendations regarding setting priority values.....22 8.4 Potential Forwarding Loop.............................22
8.5 Recommendations regarding setting priority values.....22
9. Operation over FDDI, Token Ring, and ATM LANE.............22 9. Operation over FDDI, Token Ring, and ATM LANE.............22
9.1 Operation over FDDI...................................22 9.1 Operation over FDDI...................................22
9.2 Operation over Token Ring.............................22 9.2 Operation over Token Ring.............................22
9.3 Operation over ATM LANE...............................25 9.3 Operation over ATM LANE...............................25
10. Security Considerations...................................25 10. Security Considerations...................................25
11. Intellectual Property.....................................26 11. Intellectual Property.....................................26
12. Acknowledgments...........................................26 12. Acknowledgments...........................................26
13. IANA Considerations.......................................27 13. IANA Considerations.......................................27
14. Normative References......................................27 14. Normative References......................................27
15. Informative References....................................28 15. Informative References....................................28
16. Authors' Address..........................................28 16. Authors' Address..........................................28
17. Changes from RFC2338......................................29 17. Changes from RFC2338......................................29
18. Disclaimer of Validity....................................31
19. Copyright Statement.......................................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 13, line 11 skipping to change at page 14, line 11
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.8 IPv6 Address(es) 5.3.8 IPv6 Address(es)
One or more IPv6 addresses associated associated with the virtual One or more IPv6 addresses associated associated with the virtual
router. The number of addresses included is specified in the "Count router. The number of addresses included is specified in the "Count
IP Addr" field. The first address must be the IPv6 link-local IP Addr" field. The first address must be the IPv6 link-local
address associated with the virtual router. These fields are used address associated with the virtual router. These fields are used
for troubleshooting misconfigured routers. for troubleshooting misconfigured routers. If more than one address
is sent it is recommended that all routers be configured to send
these addresses in the same order to make it easier to do this
comparison.
6. Protocol State Machine 6. Protocol State Machine
6.1 Parameters per Virtual Router 6.1 Parameters per Virtual Router
VRID Virtual Router Identifier. Configurable VRID Virtual Router Identifier. Configurable
item in the range 1-255 (decimal). There is item in the range 1-255 (decimal). There is
no default. no default.
Priority Priority value to be used by this VRRP Priority Priority value to be used by this VRRP
skipping to change at page 13, line 46 skipping to change at page 14, line 49
Link-Local address associated with the Link-Local address associated with the
virtual router. virtual router.
Advertisement_Interval Time interval between ADVERTISEMENTS Advertisement_Interval Time interval between ADVERTISEMENTS
(centiseconds). Default is 100 centiseconds (centiseconds). Default is 100 centiseconds
(1 second). (1 second).
Skew_Time Time to skew Master_Down_Interval in Skew_Time Time to skew Master_Down_Interval in
centiseconds. Calculated as: centiseconds. Calculated as:
(((256 - Priority) / 256) * (((256 - priority) *
Advertisement_Interval) Advertisement_Interval) / 256).
Master_Down_Interval Time interval for Backup to declare Master Master_Down_Interval Time interval for Backup to declare Master
down (centiseconds). Calculated as: down (centiseconds). Calculated as:
(3 * Advertisement_Interval) + Skew_time (3 * Advertisement_Interval) + Skew_time
Preempt_Mode Controls whether a higher priority Backup Preempt_Mode Controls whether a higher priority Backup
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.
skipping to change at page 22, line 5 skipping to change at page 23, line 5
- When configuring an interface, VRRP routers should send an - When configuring an interface, VRRP routers should send an
unsolicitated ND Neighbor Advertisement message containing the unsolicitated ND Neighbor Advertisement message containing the
virtual router MAC address for the IPv6 address on that interface. virtual router MAC address for the IPv6 address on that interface.
- At system boot, when initializing interfaces for VRRP operation; - At system boot, when initializing interfaces for VRRP operation;
delay all ND Router and Neighbor Advertisements and Solicitation delay all ND Router and Neighbor Advertisements and Solicitation
messages until both the IPv6 address and the virtual router MAC messages until both the IPv6 address and the virtual router MAC
address are configured. address are configured.
8.3 Potential Forwarding Loop 8.3 Router Advertisements
When a backup VRRP router has become Master for a virtual router, it
is responsible for sending Router Advertisements for the virtual
router as specified in section 6.4.3. The backup routers must be
configured to send the same Router Advertisement options as the
address owner.
Router Advertisement options that advertise special services (e.g.,
Home Agent Information Option) that are present in the address owner,
should not be sent by the address owner unless the backup routers are
prepared to assume these services in full and have a complete and
synchronized database for this service.
8.4 Potential Forwarding Loop
A VRRP router SHOULD not forward packets addressed to the IPv6 A VRRP router SHOULD not forward packets addressed to the IPv6
Address it becomes Master for if it is not the owner. Forwarding Address it becomes Master for if it is not the owner. Forwarding
these packets would result in unnecessary traffic. Also in the case these packets would result in unnecessary traffic. Also in the case
of LANs that receive packets they transmit (e.g., token ring) this of LANs that receive packets they transmit (e.g., token ring) this
can result in a forwarding loop that is only terminated when the IPv6 can result in a forwarding loop that is only terminated when the IPv6
TTL expires. TTL expires.
One such mechanism for VRRP routers is to add/delete a reject host One such mechanism for VRRP routers is to add/delete a reject host
route for each adopted IPv6 address when transitioning to/from MASTER route for each adopted IPv6 address when transitioning to/from MASTER
state. state.
8.4 Recommendations regarding setting priority values 8.5 Recommendations regarding setting priority values
A priority value of 255 designates a particular router as the "IPv6 A priority value of 255 designates a particular router as the "IPv6
address owner". Care must be taken not to configure more than one address owner". Care must be taken not to configure more than one
router on the link in this way for a single VRID. router on the link in this way for a single VRID.
Routers with priority 255 will, as soon as they start up, preempt all Routers with priority 255 will, as soon as they start up, preempt all
lower priority routers. Configure no more than one router on the lower priority routers. Configure no more than one router on the
link with priority 255, especially if preemption is set. If no link with priority 255, especially if preemption is set. If no
router has this priority, and preemption is disabled, then no router has this priority, and preemption is disabled, then no
preemption will occur. preemption will occur.
skipping to change at page 26, line 13 skipping to change at page 27, line 26
vulnerabilities to local attacks. vulnerabilities to local attacks.
VRRP does not provide any confidentiality. Confidentiality is not VRRP does not provide any confidentiality. Confidentiality is not
necessary for the correct operation of VRRP and there is no necessary for the correct operation of VRRP and there is no
information in the VRRP messages that must be kept secret from other information in the VRRP messages that must be kept secret from other
nodes on the LAN. nodes on the LAN.
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 Rights 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; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. See the IETF IPR web page at such proprietary rights by implementers or users of this
http://www.ietf.org/ipr.html for additional information. specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
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
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, Steve Deering, Radia Perlman, Danny Mitzel, Mukesh Thomas Narten, Steve Deering, Radia Perlman, Danny Mitzel, Mukesh
Gupta, Don Provan, and Mark Hollinger for their helpful suggestions. Gupta, Don Provan, Mark Hollinger, John Cruz, and Melissa Johnson for
their helpful suggestions.
13. IANA Considerations 13. 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.
skipping to change at page 29, line 7 skipping to change at page 30, line 18
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Phone: +1 650 625-2004 Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com EMail: bob.hinden@nokia.com
17. Changes from RFC2338 17. Changes from RFC2338
- Added new subsection (8.4) with recommendations about setting - Added new subsection (8.3) that provided more detail on sending ND
Router Advertisements.
- Added new subsection (8.5) with recommendations about setting
priority values and it's relationship to the preempt flag. priority values and it's relationship to the preempt flag.
- Changed rules for receiving VRRP packets to not drop the packet if - Changed rules for receiving VRRP packets to not drop the packet if
the Adver Interval is not consistent with the local configuration the Adver Interval is not consistent with the local configuration
for the virtual router. Only log and notify network management. for the virtual router. Only log and notify network management.
- Reduced granularity of the Advertisement_Interval to centiseconds - Reduced granularity of the Advertisement_Interval to centiseconds
(i.e., 1/100 of a second). Changes include: (i.e., 1/100 of a second). Changes include:
o Made Adver Int field in the header 12-bits to allow range from o Made Adver Int field in the header 12-bits to allow range from
1 to 4096 centiseconds. 1 to 4096 centiseconds.
o Change Skew_Timer calculation to skew over one o Change Skew_Timer calculation to skew over one
Advertisement_Interval. Advertisement_Interval.
skipping to change at line 1270 skipping to change at page 32, line 4
- 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.3) describing need to not forward packets - Added new subsection (8.3) 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.
18. Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
19. Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
 End of changes. 

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