--- 1/draft-ietf-vrrp-ipv6-spec-07.txt 2007-03-05 23:14:54.000000000 +0100 +++ 2/draft-ietf-vrrp-ipv6-spec-08.txt 2007-03-05 23:14:54.000000000 +0100 @@ -1,45 +1,50 @@ -INTERNET-DRAFT R. Hinden / Nokia -September 28, 2004 +Network Working Group R. Hinden +Internet-Draft Nokia +Expires: August 23, 2007 J.Cruz, Editor + Cisco Systems + February 23, 2007 Virtual Router Redundancy Protocol for IPv6 - + Status of this Memo - This document is an Internet-Draft and is subject to all provisions - 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. + 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 becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This internet draft expires on April 3, 2005. +Copyright Notice + + Copyright (C) The IETF Trust (2007). + 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 LAN. The VRRP router controlling the IP address(es) associated with @@ -79,24 +84,21 @@ 9. Operation over FDDI, Token Ring, and ATM LANE.............22 9.1 Operation over FDDI...................................22 9.2 Operation over Token Ring.............................22 9.3 Operation over ATM LANE...............................25 10. Security Considerations...................................25 11. Intellectual Property.....................................26 12. Acknowledgments...........................................26 13. IANA Considerations.......................................27 14. Normative References......................................27 15. Informative References....................................28 - 16. Authors' Address..........................................28 - 17. Changes from RFC2338......................................29 - 18. Disclaimer of Validity....................................31 - 19. Copyright Statement.......................................31 + 16. Changes from RFC2338......................................29 1. Introduction IPv6 hosts on a LAN will usually learn about one or more default routers by receiving Router Advertisements sent using the IPv6 Neighbor Discovery protocol [ND]. The Router Advertisements are multicast periodically at a rate that the hosts will learn about the default routers in a few minutes. They are not sent frequently enough to rely on the absence of the router advertisement to detect router failures. @@ -570,30 +572,38 @@ IPv6_Addresses One or more IPv6 addresses associated with this virtual router. Configured item. No default. The first address must be the Link-Local address associated with the virtual router. Advertisement_Interval Time interval between ADVERTISEMENTS (centiseconds). Default is 100 centiseconds (1 second). + Master_Adver_Interval Advertisement interval contained in + ADVERTISEMENTS received from the Master + (centiseconds). This value is saved by + virtual routers in Backup state and used to + compute Skew_Time and Master_Down_Interval. + The initial value is same as + Advertisement_Interval. + Skew_Time Time to skew Master_Down_Interval in centiseconds. Calculated as: (((256 - priority) * - Advertisement_Interval) / 256). + Master_Adver_Interval) / 256). Master_Down_Interval Time interval for Backup to declare Master down (centiseconds). Calculated as: - (3 * Advertisement_Interval) + Skew_time + (3 * Master_Adver_Interval) + Skew_time Preempt_Mode Controls whether a higher priority Backup router preempts a lower priority Master. Values are True to allow preemption and False to prohibit preemption. Default is True. Note: Exception is that the router that owns the IPv6 address associated with the virtual router always preempts independent of the @@ -650,23 +660,23 @@ o Send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) unset, the Override flag (O) set, the Target Address set to the IPv6 link-local address of the Virtual Router, and the Target Link Layer address set to the virtual router MAC address. o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state else + o Set Master_Adver_Interval to Advertisement_Interval o Set the Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state - endif 6.4.2 Backup The purpose of the {Backup} state is to monitor the availability and state of the Master Router. While in this state, a VRRP router MUST do the following: - MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 @@ -702,26 +712,29 @@ o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state endif - If an ADVERTISEMENT is received, then: If the Priority in the ADVERTISEMENT is Zero, then: o Set the Master_Down_Timer to Skew_Time + else: If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: + o Set Master_Adver_Interval to Adver Interval contained in + the ADVERTISEMENT. o Reset the Master_Down_Timer to Master_Down_Interval else: o Discard the ADVERTISEMENT endif endif endif @@ -774,20 +788,22 @@ else: If the Priority in the ADVERTISEMENT is greater than the local Priority, or If the Priority in the ADVERTISEMENT is equal to the local Priority and the IPv6 Address of the sender is greater than the local IPv6 Address, then: o Cancel Adver_Timer + o Set Master_Adver_Interval to Adver Interval contained in + the ADVERTISEMENT. o Set Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state else: o Discard ADVERTISEMENT endif endif endif @@ -818,21 +834,23 @@ SHOULD indicate via network management that a misconfiguration was detected. If the packet was not generated by the address owner (Priority does not equal 255 (decimal)), the receiver MUST drop the packet, otherwise continue processing. - MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router If the above check fails, the receiver SHOULD log the event and SHOULD indicate via network management that a misconfiguration was - detected. + detected. However, the packet is not discarded. If the virtual + router is in Backup state, it uses the received Adver Interval to re- + calculate its Master_Down_Interval. 7.2 Transmitting VRRP Packets The following operations MUST be performed when transmitting a VRRP packet. - Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum - Set the source MAC address to Virtual Router MAC Address @@ -1080,53 +1099,62 @@ 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 document. 10. Security Considerations VRRP for IPv6 does not currently include any type of authentication. Earlier versions of the VRRP (for IPv4) specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did - not provide any real measure of security. Due to the nature of the - VRRP protocol, even if VRRP messages are cryptographically protected, - it does not prevent hostile routers from behaving as if they are a - VRRP master, creating multiple masters. Authentication of VRRP - messages could have prevented a hostile router from causing all - properly functioning routers from going into backup state. However, - having multiple masters can cause as much disruption as no routers, - which authentication cannot prevent. Also, even if a hostile router - could not disrupt VRRP, it can disrupt ARP and create the same effect - as having all routers go into backup. + not provide sufficient security to overcome the vulnerability of + misconfigured secrets causing multiple masters to be elected. Due to + the nature of the VRRP protocol, even if VRRP messages are + cryptographically protected, it does not prevent hostile routers from + behaving as if they are a VRRP master, creating multiple masters. + Authentication of VRRP messages could have prevented a hostile router + from causing all properly functioning routers from going into backup + state. However, having multiple masters can cause as much disruption + as no routers, which authentication cannot prevent. Also, even if a + hostile router could not disrupt VRRP, it can disrupt ARP and create + the same effect as having all routers go into backup. It should be noted that these attacks are not worse and are a subset of the attacks that any node attached to a LAN can do independently of VRRP. The kind of attacks a malicious node on a LAN can do - include promiscuously receiving packets for any routers MAC address, - sending packets with the routers MAC address as the source MAC + include promiscuously receiving packets for any router's MAC address, + sending packets with the router's MAC address as the source MAC addresses in the L2 header to tell the L2 switches to send packets addressed to the router to the malicious node instead of the router, send redirects to tell the hosts to send their traffic somewhere else, send unsolicited ND replies, answer ND requests, etc., etc. All of this can be done independently of implementing VRRP. VRRP does not add to these vulnerabilities. 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. VRRP does not provide any confidentiality. 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. + If SEcure Neighbor Discovery (SEND) [SEND] is deployed, VRRP + authentication could be usefully added, because misconfiguration of + secrets will not be an issue. Routers with different secrets will + have different IP addresses, and therefore there will be no issue + with multiple masters with the same IP (and MAC) addresses. Also, + SEND will prevent malicious routers from sending misleading ND + messages. + 11. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -1184,87 +1212,74 @@ for VRRP for IPv6. Similar assignments are documented in: http://www.iana.org/assignments/ethernet-numbers 14. Normative 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", RFC3513, April 2003. - - [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the - Internet Checksum", RFC1071, September 1988. + Architecture", RFC4291, February 2006. - [ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol - (ICMPv6) for the Internet Protocol Version 6 (IPv6)", - RFC2463, December 1998. + [ICMPv6] Conta, A., S. Deering, M. Gupta, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC4443, March 2006. [IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [IPX] Novell Incorporated., "IPX Router Specification", Version 1.10, October 1992. [ND] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998. - [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area - Networks", RFC1469, June 1993. - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", RFC2026, BCP00009, October 1996. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP0014, March 1997. + [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. + Nikander, "SEcure Neighbor Discovery (SEND)", RFC3971, + March 2005. + [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. + [VRRP-V4] Hinder, R., "Virtual Router Redundancy Protocol (VRRP)", + RFC3768, April 2004. 15. Informative References [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby 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. - -16. Author's Address - - Robert Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - USA + [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the + Internet Checksum", RFC1071, September 1988. - Phone: +1 650 625-2004 - EMail: bob.hinden@nokia.com + [RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area + Networks", RFC1469, June 1993. -17. Changes from RFC2338 +16. Changes from RFC2338 - 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. - Changed rules for receiving VRRP packets to not drop the packet if the Adver Interval is not consistent with the local configuration for the virtual router. Only log and notify network management. + Moreover, use the Master's Adver Interval to compute + Master_Down_Interval and Skew_Time. - Reduced granularity of the Advertisement_Interval to centiseconds (i.e., 1/100 of a second). Changes include: o Made Adver Int field in the header 12-bits to allow range from 1 to 4096 centiseconds. o Change Skew_Timer calculation to skew over one Advertisement_Interval. - Added switch (Accept_Mode) to control whether a virtual router in Master state will accept packets addresses to the address owner's IPv6 address as its own if it is not the IPv6 address owner. - Changed VMAC assignments to a separate block of IANA Ethernet @@ -1278,41 +1293,62 @@ o Change packet format to support an 128-bit IPv6 address. o Rewrote text to specify IPv6 Neighbor Discovery mechanisms instead of ARP. o Changed state machine actions to use Neighbor Discovery mechanisms. This includes sending unsolicited Neighbor Advertisements, Receiving Neighbor Solicitations, joining the appropriate solicited node multicast group, sending Router Advertisements, and receiving Router Solicitations. - Revised the section 4 examples text with a clearer description of mapping of IPv6 address owner, priorities, etc. - - Clarify the section 7.1 text describing address list validation. - Corrected text in Preempt_Mode definition. - Changed authentication to be per Virtual Router instead of per Interface. - 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.3) describing need to not forward packets for adopted IPv6 addresses. - - Added clarification to the security considerations section. + - Added clarification to the security considerations section. Added + reference to SEND. - Added reference for computing the internet checksum. - Updated references and author information. -18. Disclaimer of Validity +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. 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 + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 +Authors' Addresses - 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. + Robert Hinden + Nokia, Inc. + 313 Fairchild Drive + Mountain View, CA 94043 + USA + + Phone: +1 650 625-2004 + EMail: bob.hinden@nokia.com + + John Cruz + Cisco Systems, Inc. + 3600 Cisco Way + San Jose, CA 95134 + USA + + Phone: +1 408 527 1034 + Email: johcruz@cisco.com