--- 1/draft-ietf-vrrp-ipv6-spec-01.txt 2006-02-05 02:09:30.000000000 +0100 +++ 2/draft-ietf-vrrp-ipv6-spec-02.txt 2006-02-05 02:09:30.000000000 +0100 @@ -1,40 +1,37 @@ INTERNET-DRAFT R. Hinden/Nokia -November 20, 2001 +February 28, 2002 Virtual Router Redundancy Protocol for IPv6 - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. - This internet draft expires on May 20, 2002. + This internet draft expires on August 28, 2002. Abstract This memo defines the Virtual Router Redundancy Protocol (VRRP) for 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 RFC2338. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a @@ -962,20 +959,27 @@ 8.2 ND Neighbor Solicitation When a host sends an ND Neighbor Solicitation message for the virtual router IPv6 address, the Master virtual router MUST respond to the ND Neighbor Solicitation message with the virtual MAC address for the virtual router. The Master virtual router MUST NOT respond with its physical MAC address. This allows the client to always use the same 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 messages with its physical MAC address for the IPv6 address it owns, it should only send ND messages that include Virtual MAC addresses. This may entail: - When configuring an interface, VRRP routers should send an unsolicitated ND Neighbor Advertisement message containing the virtual router MAC address for the IPv6 address on that interface. - At system boot, when initializing interfaces for VRRP operation; @@ -1183,73 +1187,46 @@ 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 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. -11. Intellectual Property - - 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 +11. Acknowledgments This specification is based on RFC2238. The authors of RFC2238 are S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, and A. Lindem. The author of this document would also like to thank Erik Nordmark, 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 assigned by the IANA for this specification. The IPv6 multicast address should be of the following form: FF02:0:0:0:0:0:XXXX:XXXX The values assigned address should be entered into section 5.2.2. A convenient assignment of this link-local scope multicast would be: FF02:0:0:0:0:0:0:12 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, 1993 edition. [ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing Architecture", RFC2373, July 1988. [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, November 1998. @@ -1292,29 +1269,29 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP0014, March 1997. [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication SC30-3374-02, Third Edition, (September, 1989). [VRRP-V4] Knight, S., et. al., "Virtual Router Redundancy Protocol", RFC2338, April 1998. -15. Author's Address +14. Author's Address Robert Hinden Phone: +1 650 625-2004 Nokia EMail: hinden@iprg.nokia.com 313 Fairchild Drive Mountain View, CA 94043 USA -16. Changes from RFC2338 +15. Changes from RFC2338 - General rewrite to change protocol to provide virtual router functionality from IPv4 to IPv6. Specific changes include: o Increment VRRP version to 3. o Change packet format to support an 128-bit IPv6 address. o Change to only support one router address (instead of multiple addresses). This included removing address count field from header. o Rewrote text to specify IPv6 Neighbor Discovery mechanisms instead of ARP. @@ -1332,10 +1309,12 @@ - Added new subsection (9.3) stating that VRRP over ATM LANE is beyond the scope of this document. - Clarified text describing received packet length check. - Clarified text describing received authentication check. - Clarified text describing VRID verification check. - Added new subsection (8.4) describing need to not forward packets for adopted IPv6 addresses. - Added clarification to the security considerations section. - Added reference for computing the internet checksum. - Updated references and author information. + - Removed IPR section as no IPR claims have been made agains this + draft.