--- 1/draft-ietf-vrrp-ipv6-spec-03.txt 2006-02-05 02:09:32.000000000 +0100 +++ 2/draft-ietf-vrrp-ipv6-spec-04.txt 2006-02-05 02:09:32.000000000 +0100 @@ -1,37 +1,37 @@ INTERNET-DRAFT R. Hinden/Nokia -December 5, 2002 +May 20, 2003 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. - This internet draft expires on June 5, 2003. + This internet draft expires on November 20, 2003. 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 @@ -42,52 +42,49 @@ The advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discovery [ND] mechanisms. Table of Contents 1. Introduction................................................3 2. Required Features...........................................5 3. VRRP Overview...............................................6 4. Sample Configurations.......................................8 - 5. Protocol...................................................11 - 5.1 VRRP Packet Format....................................11 - 5.2 IP Field Descriptions.................................11 - 5.3 VRRP Field Descriptions...............................12 - 6. Protocol State Machine....................................15 - 6.1 Parameters per Virtual Router.........................15 - 6.2 Timers................................................16 - 6.3 State Transition Diagram..............................16 - 6.4 State Descriptions....................................16 - 7. Sending and Receiving VRRP Packets........................21 - 7.1 Receiving VRRP Packets................................21 - 7.2 Transmitting Packets..................................21 - 7.3 Virtual MAC Address...................................22 - 7.4 IPv6 Interface Identifiers............................22 - 8. Operational Issues........................................23 - 8.1 ICMPv6 Redirects......................................23 - 8.2 ND Neighbor Solicitation..............................23 - 8.3 Potential Forwarding Loop.............................24 - 9. Operation over FDDI, Token Ring, and ATM LANE.............24 - 9.1 Operation over FDDI...................................24 - 9.2 Operation over Token Ring.............................24 - 9.3 Operation over ATM LANE...............................25 - 10. Security Considerations...................................26 - 10.1 No Authentication....................................27 - 10.2 Simple Text Password.................................27 - 10.3 IP Authentication Header.............................28 - 11. Intellectual Property.....................................28 - 12. Acknowledgments...........................................29 - 13. IANA Considerations.......................................29 - 14. References................................................29 - 15. Authors' Address..........................................31 - 16. Changes from RFC2338......................................31 + 5. Protocol...................................................10 + 5.1 VRRP Packet Format....................................10 + 5.2 IP Field Descriptions.................................10 + 5.3 VRRP Field Descriptions...............................11 + 6. Protocol State Machine....................................13 + 6.1 Parameters per Virtual Router.........................13 + 6.2 Timers................................................14 + 6.3 State Transition Diagram..............................14 + 6.4 State Descriptions....................................14 + 7. Sending and Receiving VRRP Packets........................18 + 7.1 Receiving VRRP Packets................................18 + 7.2 Transmitting Packets..................................18 + 7.3 Virtual MAC Address...................................19 + 7.4 IPv6 Interface Identifiers............................19 + 8. Operational Issues........................................20 + 8.1 ICMPv6 Redirects......................................20 + 8.2 ND Neighbor Solicitation..............................20 + 8.3 Potential Forwarding Loop.............................21 + 9. Operation over FDDI, Token Ring, and ATM LANE.............21 + 9.1 Operation over FDDI...................................21 + 9.2 Operation over Token Ring.............................21 + 9.3 Operation over ATM LANE...............................23 + 10. Security Considerations...................................24 + 11. Acknowledgments...........................................24 + 12. IANA Considerations.......................................24 + 13. Normative References......................................25 + 14. Informative References....................................26 + 15. Authors' Address..........................................26 + 16. Changes from RFC2338......................................26 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. @@ -226,30 +223,21 @@ disruption in service. The protocol should ensure after Master election that no state transition is triggered by any Backup router of equal or lower preference as long as the Master continues to function properly. Some environments may find it beneficial to avoid the state transition triggered when a router becomes available that is more preferential than the current Master. It may be useful to support an override of the immediate convergence to the preferred path. -2.4 Extensible Security - - 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 +2.4 Efficient Operation over Extended LANs Sending IPv6 packets on a multiaccess LAN requires mapping from an IPv6 address to a MAC address. The use of the virtual router MAC address in an extended LAN employing learning bridges can have a significant effect on the bandwidth overhead of packets sent to the 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 never learned, resulting in flooding of all packets sent to the virtual router. To improve the efficiency in this environment the protocol should: 1) use the virtual router MAC as the source in a @@ -286,30 +273,20 @@ attempt to preempt the Master unless it has higher priority. This eliminates service disruption unless a more preferred path becomes available. It's also possible to administratively prohibit all preemption attempts. The only exception is that a VRRP router will always become Master of any virtual router associated with address it owns. If the Master becomes unavailable then the highest priority Backup will transition to Master after a short delay, providing a controlled transition of the virtual router responsibility with 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 Master to minimize service interruption, and incorporates optimizations that reduce protocol complexity while guaranteeing controlled Master transition for typical operational scenarios. The optimizations result in an election protocol with minimal runtime state requirements, minimal active protocol states, and a single message type and sender. The typical operational scenarios are defined to be two redundant routers and/or distinct path preferences among each router. A side effect when these assumptions are violated (i.e., more than two redundant paths all with equal preference) is @@ -437,34 +414,30 @@ 5.1 VRRP Packet Format This section defines the format of the VRRP packet and the relevant fields in the IPv6 header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| Priority | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Auth Type | Adver Int | Checksum | + | (reserved) | Adver Int | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Authentication Data (1) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Authentication Data (2) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2 IPv6 Field Descriptions 5.2.1 Source Address The IPv6 link-local address of the interface the packet is being sent from. 5.2.2 Destination Address @@ -522,104 +496,47 @@ The priority value zero (0) has special meaning indicating that the current Master has stopped participating in VRRP. This is used to trigger Backup routers to quickly transition to Master without having to wait for the current Master to timeout. 5.3.5 Reserved This field MUST be set to zero on transmission and ignored on reception. -5.3.6 Authentication Type - - 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 +5.3.5 Reserved - The use of this authentication type means that VRRP protocol - exchanges are not authenticated. The contents of the Authentication - Data field should be set to zero on transmission and ignored on + This field MUST be set to zero on transmission and ignored on reception. -5.3.6.2 Simple Text Password - - 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) +5.3.6 Advertisement Interval (Adver Int) The Advertisement interval indicates the time interval (in seconds) between ADVERTISEMENTS. The default is 1 second. This field is used for troubleshooting misconfigured routers. -5.3.8 Checksum +5.3.7 Checksum The checksum field is used to detect data corruption in the VRRP message. 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 "pseudo-header" as defined in section 8.1 of RFC2460 [IPv6]. The next header field in the "pseudo-header" should be set to 112 (decimal) for VRRP. For computing the checksum, the checksum field 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. -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.1 Parameters per Virtual Router VRID Virtual Router Identifier. Configured item in the range 1-255 (decimal). There is no default. Priority Priority value to be used by this VRRP router in Master election for this virtual @@ -654,26 +571,20 @@ 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 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 Master_Down_Timer Timer that fires when ADVERTISEMENT has not been heard for Master_Down_Interval. Adver_Timer Timer that fires to trigger sending of ADVERTISEMENT based on Advertisement_Interval. 6.3 State Transition Diagram @@ -858,29 +771,25 @@ 7. Sending and Receiving VRRP Packets 7.1 Receiving VRRP Packets Performed the following functions when a VRRP packet is received: - MUST verify that the IPv6 Hop Limit is 255. - MUST verify the VRRP version is 3 - MUST verify that the received packet contains the complete VRRP - packet (including fixed fields, IPv6 Address, and Authentication - Data). + packet (including fixed fields, and IPv6 Address. - MUST verify the VRRP checksum - MUST verify that the VRID is configured on the receiving interface and the local router is not the IPv6 Address owner (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 packet, SHOULD log the event and MAY indicate via network management that an error occurred. - MAY verify that the IPv6 Address matches the IPv6_Address configured for the VRID. If the above check fails, the receiver SHOULD log the event and MAY indicate via network management that a misconfiguration was detected. @@ -1116,90 +1024,47 @@ in [RFC1469]. 9.3 Operation over ATM LANE 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 is designed for a range of internetworking environments that may - employ different security policies. The protocol includes several - authentication methods ranging from no authentication, simple clear - 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 + VRRP for IPv6 does not include any type of authentication. Earlier + versions of VRRP for IPv4 specification included several types of + authentication ranging from none to strong [VRRP-V4]. - 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]. This provides strong protection against - configuration errors, replay attacks, and packet - corruption/modification. + Operational experience and further analysis determined that these did + not provide any real measure of security and do to the nature of the + VRRP protocol they did not prevent incorrectly configured or hostile + routers from becoming VRRP masters. In general on LANs any device on + the LAN has the ability to disrupt all communication. For example + 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 - control over the administration of nodes on a LAN. While this type - of authentication does protect the operation of VRRP, there are other - 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. + 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. - 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. + 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. 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. @@ -1203,97 +1068,97 @@ The author of this document would also like to thank Erik Nordmark, Thomas Narten, and Steve Deering for their his helpful suggestions. 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. -13. References +13. 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", Internet Draft, , October 2002. - [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, - November 1998. - [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the 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) for the Internet Protocol Version 6 (IPv6)", 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) 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. - [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 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. [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. -14. Author's Address +14. Informative References - Robert Hinden Phone: +1 650 625-2004 - Nokia EMail: hinden@iprg.nokia.com + [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. + +15. Author's Address + + Robert Hinden + Nokia 313 Fairchild Drive Mountain View, CA 94043 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 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. o Changed state machine actions to use Neighbor Discovery @@ -1310,12 +1176,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 + - Removed IPR section as no IPR claims have been made against this draft.