--- 1/draft-ietf-vrrp-ipv6-spec-04.txt 2006-02-05 02:09:33.000000000 +0100 +++ 2/draft-ietf-vrrp-ipv6-spec-05.txt 2006-02-05 02:09:33.000000000 +0100 @@ -1,37 +1,37 @@ INTERNET-DRAFT R. Hinden/Nokia -May 20, 2003 +June 29, 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 November 20, 2003. + This internet draft expires on January 4, 2004. 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 @@ -255,21 +255,21 @@ Each VRRP virtual router has a single well-known MAC address allocated to it. This document currently only details the mapping to networks using the IEEE 802 48-bit MAC address. The virtual router MAC address is used as the source in all periodic VRRP messages sent by the Master router to enable bridge learning in an extended LAN. A virtual router is defined by its virtual router identifier (VRID) and an IPv6 address. A VRRP router may associate a virtual router with its real address on an interface, and may also be configured with additional virtual router mappings and priority for virtual - routers it is willing to backup. The mapping between VRID and it's + routers it is willing to backup. The mapping between VRID and its IPv6 address must be coordinated among all VRRP routers on a LAN. However, there is no restriction against reusing a VRID with a different address mapping on different LANs. The scope of each virtual router is restricted to a single LAN. To minimize network traffic, only the Master for each virtual router sends periodic VRRP Advertisement messages. A Backup router will not 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 @@ -358,21 +358,21 @@ hosts. Note that in this example IPv6 B is not backed up, it is only used by Rtr2 as its interface address. In order to backup IPv6 B, a second virtual router must be configured. This is shown in the next section. 4.2 Sample Configuration 2 The following figure shows a configuration with two virtual routers - with the hosts spitting their traffic between them. This example is + with the hosts splitting their traffic between them. This example is expected to be common in actual practice. +-----------+ +-----------+ | Rtr1 | | Rtr2 | |(MR VRID=1)| |(BR VRID=1)| |(BR VRID=2)| |(MR VRID=2)| VRID=1 +-----------+ +-----------+ VRID=2 IPv6 A -------->* *<---------- IPv6 B | | | | @@ -778,38 +778,38 @@ - 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, 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)). 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. + packet, SHOULD log the event and SHOULD 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. - 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. + If the above check fails, the receiver SHOULD log the event and + 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 MUST discard the packet, - SHOULD log the event and MAY indicate via network management that a - misconfiguration was detected. + SHOULD log the event and SHOULD indicate via network management that + a misconfiguration was detected. 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 @@ -819,70 +819,67 @@ Note: VRRP packets are transmitted with the virtual router MAC address as the source MAC address to ensure that learning bridges correctly determine the LAN segment the virtual router is attached to. 7.3 Virtual Router MAC Address The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format: - 00-00-5E-00-01-{VRID} (in hex in internet standard bit-order) + 00-00-5E-00-02-{VRID} (in hex in internet standard bit-order) The first three octets are derived from the IANA's OUI. The next two - octets (00-01) indicate the address block assigned to the VRRP - protocol. {VRID} is the VRRP Virtual Router Identifier. This + octets (00-02) indicate the address block assigned to the VRRP for + IPv6 protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping provides for up to 255 VRRP routers on a network. 7.4 IPv6 Interface Identifiers IPv6 Routers running VRRP MUST create their Interface Identifiers in the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over Ethernet"). They MUST NOT use the Virtual Router MAC address to create the Modified EUI-64 identifiers. This VRRP specification describes how to advertise and resolve the VRRP routers IPv6 link local address into the Virtual Router MAC address. 8. Operational Issues 8.1 ICMPv6 Redirects ICMPv6 Redirects may be used normally when VRRP is running between a group of routers [ICMPv6]. This allows VRRP to be used in - environments where the topology is not symmetric. + environments where the topology is not symmetric (e.g., the VRRP + routers do not connect to the same destinations). The IPv6 source address of an ICMPv6 redirect should be the address the end host used when making its next hop routing decision. If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. One method to deduce the virtual router used is to examine the destination MAC address in the packet that triggered the redirect. - It may be useful to disable Redirects for specific cases where VRRP - is being used to load share traffic between a number of routers in a - symmetric topology. - 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 + When a Master virtual router sends an ND Neighbor Solicitation + message for a host's 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: @@ -1059,45 +1056,55 @@ 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. + Thomas Narten, Steve Deering, Radia Perlman, and Danny Mitzel for + their 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. + The IANA should also reserve a block of IANA Ethernet unicast + addresses from: + + 00-00-5E-00-02-00 to 00-00-5E-00-02-FF in hex + + for VRRP for IPv6. Similar assignments are documented in: + + http://www.iana.org/assignments/ethernet-numbers + 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. + Architecture", RFC3513, April 2003. [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the Internet Checksum", RFC1071, September 1988. [ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC2463, December 1998. [IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. @@ -1143,20 +1150,22 @@ Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 650 625-2004 EMail: hinden@iprg.nokia.com 16. Changes from RFC2338 + - Changed VMAC assignements to a separate block of IANA Ethernet + addresses and added this to the IANA considerations section. - 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