draft-ietf-vrrp-ipv6-spec-01.txt   draft-ietf-vrrp-ipv6-spec-02.txt 
INTERNET-DRAFT R. Hinden/Nokia INTERNET-DRAFT R. Hinden/Nokia
November 20, 2001 February 28, 2002
Virtual Router Redundancy Protocol for IPv6 Virtual Router Redundancy Protocol for IPv6
<draft-ietf-vrrp-ipv6-spec-01.txt> <draft-ietf-vrrp-ipv6-spec-02.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."
The list of current Internet-Drafts can be accessed at To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This internet draft expires on May 20, 2002. This internet draft expires on August 28, 2002.
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 23, line 35 skipping to change at page 23, line 35
8.2 ND Neighbor Solicitation 8.2 ND Neighbor Solicitation
When a host sends an ND Neighbor Solicitation message for the virtual When a host sends an ND Neighbor Solicitation message for the virtual
router IPv6 address, the Master virtual router MUST respond to the ND router IPv6 address, the Master virtual router MUST respond to the ND
Neighbor Solicitation message with the virtual MAC address for the Neighbor Solicitation message with the virtual MAC address for the
virtual router. The Master virtual router MUST NOT respond with its virtual router. The Master virtual router MUST NOT respond with its
physical MAC address. This allows the client to always use the same physical MAC address. This allows the client to always use the same
MAC address regardless of the current Master router. MAC address regardless of the current Master router.
When a Master virtual routers sends an ND Neighbor Solicitation
message for a hosts IPv6 address, the Master virtual router MUST
include the virtual MAC address for the virtual router if it sends a
source link-layer address option in the neighbor solicitation
message. It MUST NOT use its physical MAC address in the source
link-layer address option.
When a VRRP router restarts or boots, it SHOULD not send any ND When a VRRP router restarts or boots, it SHOULD not send any ND
messages with its physical MAC address for the IPv6 address it owns, messages with its physical MAC address for the IPv6 address it owns,
it should only send ND messages that include Virtual MAC addresses. it should only send ND messages that include Virtual MAC addresses.
This may entail: This may entail:
- 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;
skipping to change at page 28, line 29 skipping to change at page 28, line 30
are not protected. are not protected.
Specifically, although securing VRRP prevents unauthorized machines Specifically, although securing VRRP prevents unauthorized machines
from taking part in the election protocol, it does not protect hosts from taking part in the election protocol, it does not protect hosts
on the network from being deceived. For example, a gratuitous ND on the network from being deceived. For example, a gratuitous ND
reply from what purports to be the virtual router's IPv6 address can reply from what purports to be the virtual router's IPv6 address can
redirect traffic to an unauthorized machine. Similarly, individual redirect traffic to an unauthorized machine. Similarly, individual
connections can be diverted by means of forged ICMPv6 Redirect connections can be diverted by means of forged ICMPv6 Redirect
messages. messages.
11. Intellectual Property 11. Acknowledgments
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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, and Steve Deering for their his helpful suggestions. Thomas Narten, and Steve Deering for their his helpful suggestions.
13. 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.
14. References 13. 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", RFC2373, July 1988. Architecture", RFC2373, July 1988.
[AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402,
November 1998. November 1998.
skipping to change at page 31, line 5 skipping to change at page 30, line 20
[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.
15. Author's Address 14. Author's Address
Robert Hinden Phone: +1 650 625-2004 Robert Hinden Phone: +1 650 625-2004
Nokia EMail: hinden@iprg.nokia.com Nokia EMail: hinden@iprg.nokia.com
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
16. Changes from RFC2338 15. Changes from RFC2338
- 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.
skipping to change at line 1342 skipping to change at page 31, line 13
- 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
draft.
 End of changes. 

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