draft-ietf-vrrp-ipv6-spec-05.txt | draft-ietf-vrrp-ipv6-spec-06.txt | |||
---|---|---|---|---|
INTERNET-DRAFT R. Hinden/Nokia | INTERNET-DRAFT R. Hinden/Nokia | |||
June 29, 2003 | February 13, 2004 | |||
Virtual Router Redundancy Protocol for IPv6 | Virtual Router Redundancy Protocol for IPv6 | |||
<draft-ietf-vrrp-ipv6-spec-05.txt> | <draft-ietf-vrrp-ipv6-spec-06.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." | |||
To view the list Internet-Draft Shadow Directories, see | To view the list Internet-Draft Shadow Directories, see | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This internet draft expires on January 4, 2004. | This internet draft expires on August 18, 2004. | |||
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 | |||
LAN. The VRRP router controlling the IP address associated with a | LAN. The VRRP router controlling the IP address(es) associated with | |||
virtual router is called the Master, and forwards packets sent to | a virtual router is called the Master, and forwards packets sent to | |||
this IP address. The election process provides dynamic fail over in | these IP addresses. The election process provides dynamic fail over | |||
the forwarding responsibility should the Master become unavailable. | in the forwarding responsibility should the Master become | |||
The advantage gained from using VRRP for IPv6 is a quicker switch | unavailable. The advantage gained from using VRRP for IPv6 is a | |||
over to back up routers than can be obtained with standard IPv6 | quicker switch over to back up routers than can be obtained with | |||
Neighbor Discovery [ND] mechanisms. | standard IPv6 Neighbor Discovery [ND] mechanisms. | |||
Table of Contents | Table of Contents | |||
1. Introduction................................................3 | 1. Introduction................................................3 | |||
2. Required Features...........................................5 | 2. Required Features...........................................5 | |||
3. VRRP Overview...............................................6 | 3. VRRP Overview...............................................6 | |||
4. Sample Configurations.......................................8 | 4. Sample Configurations.......................................8 | |||
5. Protocol...................................................10 | 5. Protocol...................................................10 | |||
5.1 VRRP Packet Format....................................10 | 5.1 VRRP Packet Format....................................10 | |||
5.2 IP Field Descriptions.................................10 | 5.2 IP Field Descriptions.................................11 | |||
5.3 VRRP Field Descriptions...............................11 | 5.3 VRRP Field Descriptions...............................11 | |||
6. Protocol State Machine....................................13 | 6. Protocol State Machine....................................13 | |||
6.1 Parameters per Virtual Router.........................13 | 6.1 Parameters per Virtual Router.........................13 | |||
6.2 Timers................................................14 | 6.2 Timers................................................13 | |||
6.3 State Transition Diagram..............................14 | 6.3 State Transition Diagram..............................15 | |||
6.4 State Descriptions....................................14 | 6.4 State Descriptions....................................15 | |||
7. Sending and Receiving VRRP Packets........................18 | 7. Sending and Receiving VRRP Packets........................19 | |||
7.1 Receiving VRRP Packets................................18 | 7.1 Receiving VRRP Packets................................19 | |||
7.2 Transmitting Packets..................................18 | 7.2 Transmitting Packets..................................19 | |||
7.3 Virtual MAC Address...................................19 | 7.3 Virtual MAC Address...................................20 | |||
7.4 IPv6 Interface Identifiers............................19 | 7.4 IPv6 Interface Identifiers............................20 | |||
8. Operational Issues........................................20 | 8. Operational Issues........................................21 | |||
8.1 ICMPv6 Redirects......................................20 | 8.1 ICMPv6 Redirects......................................21 | |||
8.2 ND Neighbor Solicitation..............................20 | 8.2 ND Neighbor Solicitation..............................21 | |||
8.3 Potential Forwarding Loop.............................21 | 8.3 Potential Forwarding Loop.............................22 | |||
9. Operation over FDDI, Token Ring, and ATM LANE.............21 | 8.4 Recommendations regarding setting priority values.....22 | |||
9.1 Operation over FDDI...................................21 | 9. Operation over FDDI, Token Ring, and ATM LANE.............22 | |||
9.2 Operation over Token Ring.............................21 | 9.1 Operation over FDDI...................................22 | |||
9.3 Operation over ATM LANE...............................23 | 9.2 Operation over Token Ring.............................22 | |||
10. Security Considerations...................................24 | 9.3 Operation over ATM LANE...............................25 | |||
11. Acknowledgments...........................................24 | 10. Security Considerations...................................25 | |||
12. IANA Considerations.......................................24 | 11. Intellectual Property.....................................26 | |||
13. Normative References......................................25 | 12. Acknowledgments...........................................26 | |||
14. Informative References....................................26 | 13. IANA Considerations.......................................27 | |||
15. Authors' Address..........................................26 | 14. Normative References......................................27 | |||
16. Changes from RFC2338......................................26 | 15. Informative References....................................28 | |||
16. Authors' Address..........................................28 | ||||
17. Changes from RFC2338......................................29 | ||||
1. Introduction | 1. Introduction | |||
IPv6 hosts on a LAN will usually learn about one or more default | IPv6 hosts on a LAN will usually learn about one or more default | |||
routers by receiving Router Advertisements sent using the IPv6 | routers by receiving Router Advertisements sent using the IPv6 | |||
Neighbor Discovery protocol [ND]. The Router Advertisements are | Neighbor Discovery protocol [ND]. The Router Advertisements are | |||
multicast periodically at a rate that the hosts will learn about the | multicast periodically at a rate that the hosts will learn about the | |||
default routers in a few minutes. They are not sent frequently enough | default routers in a few minutes. They are not sent frequently enough | |||
to rely on the absence of the router advertisement to detect router | to rely on the absence of the router advertisement to detect router | |||
failures. | failures. | |||
skipping to change at page 3, line 44 | skipping to change at page 3, line 44 | |||
The Virtual Router Redundancy Protocol for IPv6 provides a much | The Virtual Router Redundancy Protocol for IPv6 provides a much | |||
faster switch over to an alternate default router than can be | faster switch over to an alternate default router than can be | |||
obtained using standard ND procedures. Using VRRP a backup router | obtained using standard ND procedures. Using VRRP a backup router | |||
can take over for a failed default router in around three seconds | can take over for a failed default router in around three seconds | |||
(using VRRP default parameters). This is done with out any | (using VRRP default parameters). This is done with out any | |||
interaction with the hosts and a minimum amount of VRRP traffic. | interaction with the hosts and a minimum amount of VRRP traffic. | |||
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 | |||
LAN. The VRRP router controlling the IP address associated with a | LAN. The VRRP router controlling the IP address(es) associated with | |||
virtual router is called the Master, and forwards packets sent to | a virtual router is called the Master, and forwards packets sent to | |||
this IP address. The election process provides dynamic fail over in | these IP addresses. The election process provides dynamic fail over | |||
the forwarding responsibility should the Master become unavailable. | in the forwarding responsibility should the Master become | |||
unavailable. | ||||
VRRP provides a function similar to a Cisco Systems, Inc. proprietary | VRRP provides a function similar to the proprietary protocols Hot | |||
protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a | Standby Router Protocol (HSRP) [HSRP] and IP Standby Protocol | |||
Digital Equipment Corporation, Inc. proprietary protocol named IP | [IPSTB]. | |||
Standby Protocol [IPSTB]. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC 2119]. | document are to be interpreted as described in [RFC 2119]. | |||
The IESG/IETF take no position regarding the validity or scope of any | ||||
intellectual property right or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology, or the extent | ||||
to which any license under such rights might or might not be | ||||
available. See the IETF IPR web page at http://www.ietf.org/ipr.html | ||||
for additional information. | ||||
1.1 Scope | 1.1 Scope | |||
The remainder of this document describes the features, design goals, | The remainder of this document describes the features, design goals, | |||
and theory of operation of VRRP for IPv6. The message formats, | and theory of operation of VRRP for IPv6. The message formats, | |||
protocol processing rules and state machine that guarantee | protocol processing rules and state machine that guarantee | |||
convergence to a single Virtual Router Master are presented. | convergence to a single Virtual Router Master are presented. | |||
Finally, operational issues related to MAC address mapping, handling | Finally, operational issues related to MAC address mapping, handling | |||
of Neighbor Discovery requests, generation of ICMPv6 redirect | of Neighbor Discovery requests, generation of ICMPv6 redirect | |||
messages, and security issues are addressed. | messages, and security issues are addressed. | |||
skipping to change at page 4, line 38 | skipping to change at page 4, line 31 | |||
1.2 Definitions | 1.2 Definitions | |||
VRRP Router A router running the Virtual Router Redundancy | VRRP Router A router running the Virtual Router Redundancy | |||
Protocol. It may participate in one or more | Protocol. It may participate in one or more | |||
virtual routers. | virtual routers. | |||
Virtual Router An abstract object managed by VRRP that acts | Virtual Router An abstract object managed by VRRP that acts | |||
as a default router for hosts on a shared LAN. | as a default router for hosts on a shared LAN. | |||
It consists of a Virtual Router Identifier and | It consists of a Virtual Router Identifier and | |||
an IPv6 address across a common LAN. A VRRP | an a set of associated IPv6 address(es) across | |||
Router may backup one or more virtual routers. | a common LAN. A VRRP Router may backup one or | |||
more virtual routers. | ||||
IPv6 Address Owner The VRRP router that has the virtual router's | IPv6 Address Owner The VRRP router that has the virtual router's | |||
IPv6 address as real interface address. This | IPv6 address(es) as real interface address. | |||
is the router that, when up, will respond to | This is the router that, when up, will respond | |||
packets addressed to the IPv6 addresses for | to packets addressed to the IPv6 address(es) | |||
ICMPv6 pings, TCP connections, etc. | for ICMPv6 pings, TCP connections, etc. | |||
Virtual Router Master The VRRP router that is assuming the | Virtual Router Master The VRRP router that is assuming the | |||
responsibility of forwarding packets sent to | responsibility of forwarding packets sent to | |||
the IPv6 address associated with the virtual | the IPv6 address(es) associated with the | |||
router, and answering ND requests for this | virtual router, and answering ND requests for | |||
IPv6 address. Note that if the IPv6 address | these IPv6 address(es). Note that if the IPv6 | |||
owner is available, then it will always become | address owner is available, then it will | |||
the Master. | always become the Master. | |||
Virtual Router Backup The set of VRRP routers available to assume | Virtual Router Backup The set of VRRP routers available to assume | |||
forwarding responsibility for a virtual router | forwarding responsibility for a virtual router | |||
should the current Master fail. | should the current Master fail. | |||
2.0 Required Features | 2.0 Required Features | |||
This section outlines the set of features that were considered | This section outlines the set of features that were considered | |||
mandatory and that guided the design of VRRP. | mandatory and that guided the design of VRRP. | |||
2.1 IPv6 Address Backup | 2.1 IPv6 Address Backup | |||
Backup of an IPv6 address is the primary function of the Virtual | Backup of an IPv6 address(es) is the primary function of the Virtual | |||
Router Redundancy Protocol. While providing election of a Virtual | Router Redundancy Protocol. While providing election of a Virtual | |||
Router Master and the additional functionality described below, the | Router Master and the additional functionality described below, the | |||
protocol should strive to: | protocol should strive to: | |||
- Minimize the duration of black holes. | - Minimize the duration of black holes. | |||
- Minimize the steady state bandwidth overhead and processing | - Minimize the steady state bandwidth overhead and processing | |||
complexity. | complexity. | |||
- Function over a wide variety of multiaccess LAN technologies | - Function over a wide variety of multiaccess LAN technologies | |||
capable of supporting IPv6 traffic. | capable of supporting IPv6 traffic. | |||
- Provide for election of multiple virtual routers on a network for | - Provide for election of multiple virtual routers on a network for | |||
skipping to change at page 6, line 15 | skipping to change at page 6, line 6 | |||
2.3 Minimization of Unnecessary Service Disruptions | 2.3 Minimization of Unnecessary Service Disruptions | |||
Once Master election has been performed then any unnecessary | Once Master election has been performed then any unnecessary | |||
transitions between Master and Backup routers can result in a | transitions between Master and Backup routers can result in a | |||
disruption in service. The protocol should ensure after Master | disruption in service. The protocol should ensure after Master | |||
election that no state transition is triggered by any Backup router | election that no state transition is triggered by any Backup router | |||
of equal or lower preference as long as the Master continues to | of equal or lower preference as long as the Master continues to | |||
function properly. | function properly. | |||
Some environments may find it beneficial to avoid the state | Some environments may find it beneficial to avoid the state | |||
transition triggered when a router becomes available that is more | transition triggered when a router becomes available that is | |||
preferential than the current Master. It may be useful to support an | preferred over the current Master. It may be useful to support an | |||
override of the immediate convergence to the preferred path. | override of the immediate convergence to the preferred path. | |||
2.4 Efficient Operation over Extended LANs | 2.4 Efficient Operation over Extended LANs | |||
Sending IPv6 packets on a multiaccess LAN requires mapping from an | Sending IPv6 packets on a multiaccess LAN requires mapping from an | |||
IPv6 address to a MAC address. The use of the virtual router MAC | IPv6 address to a MAC address. The use of the virtual router MAC | |||
address in an extended LAN employing learning bridges can have a | address in an extended LAN employing learning bridges can have a | |||
significant effect on the bandwidth overhead of packets sent to the | significant effect on the bandwidth overhead of packets sent to the | |||
virtual router. If the virtual router MAC address is never used as | 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 | the source address in a link level frame then the station location is | |||
skipping to change at page 6, line 48 | skipping to change at page 6, line 39 | |||
function described earlier. All protocol messaging is performed | function described earlier. All protocol messaging is performed | |||
using IPv6 multicast datagrams, thus the protocol can operate over a | using IPv6 multicast datagrams, thus the protocol can operate over a | |||
variety of multiaccess LAN technologies supporting IPv6 multicast. | variety of multiaccess LAN technologies supporting IPv6 multicast. | |||
Each VRRP virtual router has a single well-known MAC address | Each VRRP virtual router has a single well-known MAC address | |||
allocated to it. This document currently only details the mapping to | allocated to it. This document currently only details the mapping to | |||
networks using the IEEE 802 48-bit MAC address. The virtual router | 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 | 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. | by the Master router to enable bridge learning in an extended LAN. | |||
A virtual router is defined by its virtual router identifier (VRID) | A virtual router is defined by its virtual router identifier (VRID) | |||
and an IPv6 address. A VRRP router may associate a virtual router | and a set of IPv6 address(es). A VRRP router may associate a virtual | |||
with its real address on an interface, and may also be configured | router with its real address on an interface, and may also be | |||
with additional virtual router mappings and priority for virtual | configured with additional virtual router mappings and priority for | |||
routers it is willing to backup. The mapping between VRID and its | virtual routers it is willing to backup. The mapping between VRID | |||
IPv6 address must be coordinated among all VRRP routers on a LAN. | and its IPv6 address(es) must be coordinated among all VRRP routers | |||
However, there is no restriction against reusing a VRID with a | on a LAN. However, there is no restriction against reusing a VRID | |||
different address mapping on different LANs. The scope of each | with a different address mapping on different LANs. The scope of | |||
virtual router is restricted to a single LAN. | each virtual router is restricted to a single LAN. | |||
To minimize network traffic, only the Master for each virtual router | To minimize network traffic, only the Master for each virtual router | |||
sends periodic VRRP Advertisement messages. A Backup router will not | sends periodic VRRP Advertisement messages. A Backup router will not | |||
attempt to preempt the Master unless it has higher priority. This | attempt to preempt the Master unless it has higher priority. This | |||
eliminates service disruption unless a more preferred path becomes | eliminates service disruption unless a more preferred path becomes | |||
available. It's also possible to administratively prohibit all | available. It's also possible to administratively prohibit all | |||
preemption attempts. The only exception is that a VRRP router will | preemption attempts. The only exception is that a VRRP router will | |||
always become Master of any virtual router associated with address it | always become Master of any virtual router associated with address it | |||
owns. If the Master becomes unavailable then the highest priority | owns. If the Master becomes unavailable then the highest priority | |||
Backup will transition to Master after a short delay, providing a | Backup will transition to Master after a short delay, providing a | |||
skipping to change at page 10, line 29 | skipping to change at page 10, line 29 | |||
the IPv6 multicast address assigned to VRRP. | the IPv6 multicast address assigned to VRRP. | |||
5.1 VRRP Packet Format | 5.1 VRRP Packet Format | |||
This section defines the format of the VRRP packet and the relevant | This section defines the format of the VRRP packet and the relevant | |||
fields in the IPv6 header. | fields in the IPv6 header. | |||
0 1 2 3 | 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 | 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) | | |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| (reserved) | Adver Int | Checksum | | |(rsvd) | Adver Int | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
+ + | + + | |||
| | | | IPv6 Address(es) | | |||
+ IPv6 Address + | + + | |||
+ + | ||||
+ + | ||||
+ + | ||||
| | | | | | |||
+ + | + + | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
5.2 IPv6 Field Descriptions | 5.2 IPv6 Field Descriptions | |||
5.2.1 Source Address | 5.2.1 Source Address | |||
The IPv6 link-local address of the interface the packet is being sent | The IPv6 link-local address of the interface the packet is being sent | |||
skipping to change at page 12, line 17 | skipping to change at page 12, line 23 | |||
VRRP routers backing up a virtual router MUST use priority values | VRRP routers backing up a virtual router MUST use priority values | |||
between 1-254 (decimal). The default priority value for VRRP routers | between 1-254 (decimal). The default priority value for VRRP routers | |||
backing up a virtual router is 100 (decimal). | backing up a virtual router is 100 (decimal). | |||
The priority value zero (0) has special meaning indicating that the | The priority value zero (0) has special meaning indicating that the | |||
current Master has stopped participating in VRRP. This is used to | current Master has stopped participating in VRRP. This is used to | |||
trigger Backup routers to quickly transition to Master without having | trigger Backup routers to quickly transition to Master without having | |||
to wait for the current Master to timeout. | to wait for the current Master to timeout. | |||
5.3.5 Reserved | 5.3.5 Count IPv6 Addr | |||
This field MUST be set to zero on transmission and ignored on | The number of IPv6 addresses contained in this VRRP advertisement. | |||
reception. | The minimum value is 1. | |||
5.3.5 Reserved | 5.3.5 Rsvd | |||
This field MUST be set to zero on transmission and ignored on | This field MUST be set to zero on transmission and ignored on | |||
reception. | reception. | |||
5.3.6 Advertisement Interval (Adver Int) | 5.3.6 Advertisement Interval (Adver Int) | |||
The Advertisement interval indicates the time interval (in seconds) | The Advertisement interval is a 12-bit field that indicates the time | |||
between ADVERTISEMENTS. The default is 1 second. This field is used | interval (in centiseconds) between ADVERTISEMENTS. The default is | |||
for troubleshooting misconfigured routers. | 100 centiseconds (1 second). This field is used for troubleshooting | |||
misconfigured routers. | ||||
5.3.7 Checksum | 5.3.7 Checksum | |||
The checksum field is used to detect data corruption in the VRRP | The checksum field is used to detect data corruption in the VRRP | |||
message. | message. | |||
The checksum is the 16-bit one's complement of the one's complement | 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 | 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 | "pseudo-header" as defined in section 8.1 of RFC2460 [IPv6]. The | |||
next header field in the "pseudo-header" should be set to 112 | next header field in the "pseudo-header" should be set to 112 | |||
(decimal) for VRRP. For computing the checksum, the checksum field | (decimal) for VRRP. For computing the checksum, the checksum field | |||
is set to zero. See RFC1071 for more detail [CKSM]. | is set to zero. See RFC1071 for more detail [CKSM]. | |||
5.3.8 IPv6 Address | 5.3.8 IPv6 Address(es) | |||
The IPv6 link-local address associated with the virtual router. | One or more IPv6 addresses associated associated with the virtual | |||
router. The number of addresses included is specified in the "Count | ||||
IP Addr" field. The first address must be the IPv6 link-local | ||||
address associated with the virtual router. These fields are used | ||||
for troubleshooting misconfigured routers. | ||||
6. Protocol State Machine | 6. Protocol State Machine | |||
6.1 Parameters per Virtual Router | 6.1 Parameters per Virtual Router | |||
VRID Virtual Router Identifier. Configured item | VRID Virtual Router Identifier. Configurable | |||
in the range 1-255 (decimal). There is no | item in the range 1-255 (decimal). There is | |||
default. | no default. | |||
Priority Priority value to be used by this VRRP | Priority Priority value to be used by this VRRP | |||
router in Master election for this virtual | router in Master election for this virtual | |||
router. The value of 255 (decimal) is | router. The value of 255 (decimal) is | |||
reserved for the router that owns the IPv6 | reserved for the router that owns the IPv6 | |||
address associated with the virtual router. | address associated with the virtual router. | |||
The value of 0 (zero) is reserved for Master | The value of 0 (zero) is reserved for Master | |||
router to indicate it is releasing | router to indicate it is releasing | |||
responsibility for the virtual router. The | responsibility for the virtual router. The | |||
range 1-254 (decimal) is available for VRRP | range 1-254 (decimal) is available for VRRP | |||
routers backing up the virtual router. The | routers backing up the virtual router. The | |||
default value is 100 (decimal). | default value is 100 (decimal). | |||
IPv6_Address The IPv6 link-local address associated with | IPv6_Addresses One or more IPv6 addresses associated with | |||
this virtual router. Configured item. No | this virtual router. Configured item. No | |||
default. | default. The first address must be the | |||
Link-Local address associated with the | ||||
virtual router. | ||||
Advertisement_Interval Time interval between ADVERTISEMENTS | Advertisement_Interval Time interval between ADVERTISEMENTS | |||
(seconds). Default is 1 second. | (centiseconds). Default is 100 centiseconds | |||
(1 second). | ||||
Skew_Time Time to skew Master_Down_Interval in | Skew_Time Time to skew Master_Down_Interval in | |||
seconds. Calculated as: | centiseconds. Calculated as: | |||
( (256 - Priority) / 256 ) | ||||
(((256 - Priority) / 256) * | ||||
Advertisement_Interval) | ||||
Master_Down_Interval Time interval for Backup to declare Master | Master_Down_Interval Time interval for Backup to declare Master | |||
down (seconds). Calculated as: | down (centiseconds). Calculated as: | |||
(3 * Advertisement_Interval) + Skew_time | (3 * Advertisement_Interval) + Skew_time | |||
Preempt_Mode Controls whether a higher priority Backup | Preempt_Mode Controls whether a higher priority Backup | |||
router preempts a lower priority Master. | router preempts a lower priority Master. | |||
Values are True to allow preemption and | Values are True to allow preemption and | |||
False to prohibit preemption. Default is | False to prohibit preemption. Default is | |||
True. | True. | |||
Note: Exception is that the router that owns | Note: Exception is that the router that owns | |||
the IPv6 address associated with the virtual | the IPv6 address associated with the virtual | |||
router always preempts independent of the | router always preempts independent of the | |||
setting of this flag. | setting of this flag. | |||
Accept_Mode Controls whether a virtual router in Master | ||||
state will accept packets addressed to the | ||||
address owner's IPv6 address as its own if | ||||
it is not the IPv6 address owner. Default | ||||
is False. | ||||
6.2 Timers | 6.2 Timers | |||
Master_Down_Timer Timer that fires when ADVERTISEMENT has not | Master_Down_Timer Timer that fires when ADVERTISEMENT has not | |||
been heard for Master_Down_Interval. | been heard for Master_Down_Interval. | |||
Adver_Timer Timer that fires to trigger sending of | Adver_Timer Timer that fires to trigger sending of | |||
ADVERTISEMENT based on | ADVERTISEMENT based on | |||
Advertisement_Interval. | Advertisement_Interval. | |||
6.3 State Transition Diagram | 6.3 State Transition Diagram | |||
skipping to change at page 15, line 24 | skipping to change at page 16, line 13 | |||
endif | endif | |||
6.4.2 Backup | 6.4.2 Backup | |||
The purpose of the {Backup} state is to monitor the availability and | The purpose of the {Backup} state is to monitor the availability and | |||
state of the Master Router. | state of the Master Router. | |||
While in this state, a VRRP router MUST do the following: | While in this state, a VRRP router MUST do the following: | |||
- MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 | - MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 | |||
address associated with the virtual router. | address(es) associated with the virtual router. | |||
- MUST NOT send ND Router Advertisement messages for the virtual | - MUST NOT send ND Router Advertisement messages for the virtual | |||
router. | router. | |||
- MUST discard packets with a destination link layer MAC address | - MUST discard packets with a destination link layer MAC address | |||
equal to the virtual router MAC address. | equal to the virtual router MAC address. | |||
- MUST NOT accept packets addressed to the IPv6 address associated | - MUST NOT accept packets addressed to the IPv6 address(es) | |||
with the virtual router. | associated with the virtual router. | |||
- If a Shutdown event is received, then: | - If a Shutdown event is received, then: | |||
o Cancel the Master_Down_Timer | o Cancel the Master_Down_Timer | |||
o Transition to the {Initialize} state | o Transition to the {Initialize} state | |||
endif | endif | |||
- If the Master_Down_Timer fires, then: | - If the Master_Down_Timer fires, then: | |||
o Send an ADVERTISEMENT | o Send an ADVERTISEMENT | |||
o Compute and join the Solicited-Node multicast address [ADD-ARH] | o Compute and join the Solicited-Node multicast address [ADD-ARH] | |||
for the link-local IPv6 address of the Virtual Router. | for the IPv6 address(es) addresses associated with the the | |||
Virtual Router. | ||||
o Send an unsolicited ND Neighbor Advertisement with the Router | o Send an unsolicited ND Neighbor Advertisement with the Router | |||
Flag (R) set, the Solicited Flag (S) unset, the Override flag | Flag (R) set, the Solicited Flag (S) unset, the Override flag | |||
(O) set, the Target Address set to the IPv6 link-local address | (O) set, the Target Address set to the IPv6 link-local address | |||
of the Virtual Router, and the Target Link Layer address set to | of the Virtual Router, and the Target Link Layer address set to | |||
the virtual router MAC address. | the virtual router MAC address. | |||
o Set the Adver_Timer to Advertisement_Interval | o Set the Adver_Timer to Advertisement_Interval | |||
o Transition to the {Master} state | o Transition to the {Master} state | |||
endif | endif | |||
- If an ADVERTISEMENT is received, then: | - If an ADVERTISEMENT is received, then: | |||
If the Priority in the ADVERTISEMENT is Zero, then: | If the Priority in the ADVERTISEMENT is Zero, then: | |||
o Set the Master_Down_Timer to Skew_Time | o Set the Master_Down_Timer to Skew_Time | |||
skipping to change at page 16, line 43 | skipping to change at page 17, line 31 | |||
While in the {Master} state the router functions as the forwarding | While in the {Master} state the router functions as the forwarding | |||
router for the IPv6 address associated with the virtual router. | router for the IPv6 address associated with the virtual router. | |||
While in this state, a VRRP router MUST do the following: | While in this state, a VRRP router MUST do the following: | |||
- MUST be a member of the Solicited-Node multicast address for the | - MUST be a member of the Solicited-Node multicast address for the | |||
IPv6 link-local address associated with the virtual router. | IPv6 link-local address associated with the virtual router. | |||
- MUST respond to ND Neighbor Solicitation message for the IPv6 | - MUST respond to ND Neighbor Solicitation message for the IPv6 | |||
address associated with the virtual router. | address(es) associated with the virtual router. | |||
- MUST send ND Router Advertisements for the virtual router. | - MUST send ND Router Advertisements for the virtual router. | |||
- MUST respond to ND Router Solicitation message for the virtual | - MUST respond to ND Router Solicitation message for the virtual | |||
router. | router. | |||
- MUST forward packets with a destination link layer MAC address | - MUST forward packets with a destination link layer MAC address | |||
equal to the virtual router MAC address. | equal to the virtual router MAC address. | |||
- MUST NOT accept packets addressed to the IPv6 address associated | - MUST accept packets addressed to the IPv6 address(es) associated | |||
with the virtual router if it is not the IPv6 address owner. | with the virtual router if it is the IPv6 address owner or if | |||
Accept_Mode is True. Otherwise, MUST NOT accept these packets. | ||||
- MUST accept packets addressed to the IPv6 address associated with | ||||
the virtual router if it is the IPv6 address owner. | ||||
- If a Shutdown event is received, then: | - If a Shutdown event is received, then: | |||
o Cancel the Adver_Timer | o Cancel the Adver_Timer | |||
o Send an ADVERTISEMENT with Priority = 0 | o Send an ADVERTISEMENT with Priority = 0 | |||
o Transition to the {Initialize} state | o Transition to the {Initialize} state | |||
endif | endif | |||
- If the Adver_Timer fires, then: | - If the Adver_Timer fires, then: | |||
o Send an ADVERTISEMENT | o Send an ADVERTISEMENT | |||
o Reset the Adver_Timer to Advertisement_Interval | o Reset the Adver_Timer to Advertisement_Interval | |||
endif | endif | |||
- If an ADVERTISEMENT is received, then: | - If an ADVERTISEMENT is received, then: | |||
If the Priority in the ADVERTISEMENT is Zero, then: | If the Priority in the ADVERTISEMENT is Zero, then: | |||
skipping to change at page 18, line 36 | skipping to change at page 19, line 36 | |||
If the above check fails, the receiver SHOULD log the event and | If the above check fails, the receiver SHOULD log the event and | |||
SHOULD indicate via network management that a misconfiguration was | SHOULD indicate via network management that a misconfiguration was | |||
detected. If the packet was not generated by the address owner | detected. If the packet was not generated by the address owner | |||
(Priority does not equal 255 (decimal)), the receiver MUST drop the | (Priority does not equal 255 (decimal)), the receiver MUST drop the | |||
packet, otherwise continue processing. | packet, otherwise continue processing. | |||
- MUST verify that the Adver Interval in the packet is the same as | - MUST verify that the Adver Interval in the packet is the same as | |||
the locally configured for this virtual router | the locally configured for this virtual router | |||
If the above check fails, the receiver MUST discard the packet, | If the above check fails, the receiver SHOULD log the event and | |||
SHOULD log the event and SHOULD indicate via network management that | SHOULD indicate via network management that a misconfiguration was | |||
a misconfiguration was detected. | detected. | |||
7.2 Transmitting VRRP Packets | 7.2 Transmitting VRRP Packets | |||
The following operations MUST be performed when transmitting a VRRP | The following operations MUST be performed when transmitting a VRRP | |||
packet. | packet. | |||
- Fill in the VRRP packet fields with the appropriate virtual | - Fill in the VRRP packet fields with the appropriate virtual | |||
router configuration state | router configuration state | |||
- Compute the VRRP checksum | - Compute the VRRP checksum | |||
- Set the source MAC address to Virtual Router MAC Address | - Set the source MAC address to Virtual Router MAC Address | |||
skipping to change at page 21, line 18 | skipping to change at page 22, line 18 | |||
Address it becomes Master for if it is not the owner. Forwarding | Address it becomes Master for if it is not the owner. Forwarding | |||
these packets would result in unnecessary traffic. Also in the case | these packets would result in unnecessary traffic. Also in the case | |||
of LANs that receive packets they transmit (e.g., token ring) this | of LANs that receive packets they transmit (e.g., token ring) this | |||
can result in a forwarding loop that is only terminated when the IPv6 | can result in a forwarding loop that is only terminated when the IPv6 | |||
TTL expires. | TTL expires. | |||
One such mechanism for VRRP routers is to add/delete a reject host | One such mechanism for VRRP routers is to add/delete a reject host | |||
route for each adopted IPv6 address when transitioning to/from MASTER | route for each adopted IPv6 address when transitioning to/from MASTER | |||
state. | state. | |||
8.4 Recommendations regarding setting priority values | ||||
A priority value of 255 designates a particular router as the "IPv6 | ||||
address owner". Care must be taken not to configure more than one | ||||
router on the link in this way for a single VRID. | ||||
Routers with priority 255 will, as soon as they start up, preempt all | ||||
lower priority routers. Configure no more than one router on the | ||||
link with priority 255, especially if preemption is set. If no | ||||
router has this priority, and preemption is disabled, then no | ||||
preemption will occur. | ||||
When there are multiple Backup routers, their priority values should | ||||
be uniformly distributed. For example, if one Backup routers has the | ||||
default priority of 100 and another BR is added, a priority of 50 | ||||
would be a better choice for it than 99 or 100 to facilitate faster | ||||
convergence. | ||||
9. Operation over FDDI, Token Ring, and ATM LANE | 9. Operation over FDDI, Token Ring, and ATM LANE | |||
9.1 Operation over FDDI | 9.1 Operation over FDDI | |||
FDDI interfaces remove from the FDDI ring frames that have a source | FDDI interfaces remove from the FDDI ring frames that have a source | |||
MAC address matching the device's hardware address. Under some | MAC address matching the device's hardware address. Under some | |||
conditions, such as router isolations, ring failures, protocol | conditions, such as router isolations, ring failures, protocol | |||
transitions, etc., VRRP may cause there to be more than one Master | transitions, etc., VRRP may cause there to be more than one Master | |||
router. If a Master router installs the virtual router MAC address | router. If a Master router installs the virtual router MAC address | |||
as the hardware address on a FDDI device, then other Masters' | as the hardware address on a FDDI device, then other Masters' | |||
skipping to change at page 23, line 46 | skipping to change at page 25, line 19 | |||
in [RFC1469]. | in [RFC1469]. | |||
9.3 Operation over ATM LANE | 9.3 Operation over ATM LANE | |||
Operation of VRRP over ATM LANE on routers with ATM LANE interfaces | 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 | and/or routers behind proxy LEC's are beyond the scope of this | |||
document. | document. | |||
10. Security Considerations | 10. Security Considerations | |||
VRRP for IPv6 does not include any type of authentication. Earlier | VRRP for IPv6 does not currently include any type of authentication. | |||
versions of VRRP for IPv4 specification included several types of | Earlier versions of the VRRP (for IPv4) specification included | |||
authentication ranging from none to strong [VRRP-V4]. | several types of authentication ranging from none to strong. | |||
Operational experience and further analysis determined that these did | Operational experience and further analysis determined that these did | |||
not provide any real measure of security and do to the nature of the | not provide any real measure of security. Due to the nature of the | |||
VRRP protocol they did not prevent incorrectly configured or hostile | VRRP protocol, even if VRRP messages are cryptographically protected, | |||
routers from becoming VRRP masters. In general on LANs any device on | it does not prevent hostile routers from behaving as if they are a | |||
the LAN has the ability to disrupt all communication. For example | VRRP master, creating multiple masters. Authentication of VRRP | |||
although securing VRRP prevents unauthorized machines from taking | messages could have prevented a hostile router from causing all | |||
part in the election protocol, it does not protect hosts on the | properly functioning routers from going into backup state. However, | |||
network from being deceived. A gratuitous ND reply from what | having multiple masters can cause as much disruption as no routers, | |||
purports to be the virtual router's IPv6 address can redirect traffic | which authentication cannot prevent. Also, even if a hostile router | |||
to an unauthorized machine. Similarly, individual connections can be | could not disrupt VRRP, it can disrupt ARP and create the same effect | |||
diverted by means of forged ICMPv6 Redirect messages. Consequentially | as having all routers go into backup. | |||
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. | ||||
VRRP includes a mechanism (setting TTL=255, checking on receipt) that | It should be noted that these attacks are not worse and are a subset | |||
protects against VRRP packets being injected from another remote | of the attacks that any node attached to a LAN can do independently | |||
network. This limits most vulnerabilities to local attacks. | 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 | ||||
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 | VRRP does not provide any confidentiality. Confidentiality is not | |||
necessary for the correct operation of VRRP and there is no | necessary for the correct operation of VRRP and there is no | |||
information in the VRRP messages that must be kept secret from other | information in the VRRP messages that must be kept secret from other | |||
nodes on the LAN. | nodes on the LAN. | |||
11. Acknowledgments | 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. See the IETF IPR web page at | ||||
http://www.ietf.org/ipr.html for additional information. | ||||
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, Steve Deering, Radia Perlman, and Danny Mitzel for | Thomas Narten, Steve Deering, Radia Perlman, Danny Mitzel, Mukesh | |||
their helpful suggestions. | Gupta, Don Provan, and Mark Hollinger for their helpful suggestions. | |||
12. IANA Considerations | 13. 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: | |||
skipping to change at page 25, line 18 | skipping to change at page 27, line 30 | |||
The IANA should also reserve a block of IANA Ethernet unicast | The IANA should also reserve a block of IANA Ethernet unicast | |||
addresses from: | addresses from: | |||
00-00-5E-00-02-00 to 00-00-5E-00-02-FF in hex | 00-00-5E-00-02-00 to 00-00-5E-00-02-FF in hex | |||
for VRRP for IPv6. Similar assignments are documented in: | for VRRP for IPv6. Similar assignments are documented in: | |||
http://www.iana.org/assignments/ethernet-numbers | http://www.iana.org/assignments/ethernet-numbers | |||
13. Normative References | 14. Normative 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", RFC3513, April 2003. | Architecture", RFC3513, April 2003. | |||
[CKSM] Braden, R., D. Borman, C. Partridge, "Computing the | [CKSM] Braden, R., D. Borman, C. Partridge, "Computing the | |||
Internet Checksum", RFC1071, September 1988. | Internet Checksum", RFC1071, September 1988. | |||
skipping to change at page 26, line 9 | skipping to change at page 28, line 21 | |||
[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. | |||
14. Informative References | 15. Informative References | |||
[HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby | [HSRP] Li, T., B. Cole, P. Morton, D. Li, "Cisco Hot Standby | |||
Router Protocol (HSRP)", RFC2281, March 1998. | Router Protocol (HSRP)", RFC2281, March 1998. | |||
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to | [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to | |||
Provide Fast Failover in IP Networks", Digital Technical | Provide Fast Failover in IP Networks", Digital Technical | |||
Journal, Volume 9 Number 3, Winter 1997. | Journal, Volume 9 Number 3, Winter 1997. | |||
[OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998. | [OSPF] Moy, J., "OSPF version 2", RFC2328, STD0054, April 1998. | |||
[RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November | [RIP] Malkin, G., "RIP Version 2", RFC2453, STD0056, November | |||
1998. | 1998. | |||
15. Author's Address | 16. Author's Address | |||
Robert Hinden | Robert Hinden | |||
Nokia | Nokia | |||
313 Fairchild Drive | 313 Fairchild Drive | |||
Mountain View, CA 94043 | Mountain View, CA 94043 | |||
USA | USA | |||
Phone: +1 650 625-2004 | Phone: +1 650 625-2004 | |||
EMail: hinden@iprg.nokia.com | EMail: bob.hinden@nokia.com | |||
16. Changes from RFC2338 | 17. Changes from RFC2338 | |||
- Changed VMAC assignements to a separate block of IANA Ethernet | - Added new subsection (8.4) 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. | ||||
- 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 | ||||
addresses and added this to the IANA considerations section. | addresses and added this to the IANA considerations section. | |||
- Removed different authentication methods, header fields, and | - Removed different authentication methods, header fields, and | |||
updated the security considerations section. | updated the security considerations section to explain the reasons | |||
for doing this. | ||||
- 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 | ||||
addresses). This included removing address count field from | ||||
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. | |||
o Changed state machine actions to use Neighbor Discovery | o Changed state machine actions to use Neighbor Discovery | |||
mechanisms. This includes sending unsolicited Neighbor | mechanisms. This includes sending unsolicited Neighbor | |||
Advertisements, Receiving Neighbor Solicitations, joining the | Advertisements, Receiving Neighbor Solicitations, joining the | |||
appropriate solicited node multicast group, sending Router | appropriate solicited node multicast group, sending Router | |||
Advertisements, and receiving Router Solicitations. | Advertisements, and receiving Router Solicitations. | |||
- Revised the section 4 examples text with a clearer description of | - Revised the section 4 examples text with a clearer description of | |||
mapping of IPv6 address owner, priorities, etc. | mapping of IPv6 address owner, priorities, etc. | |||
- Clarify the section 7.1 text describing address list validation. | - Clarify the section 7.1 text describing address list validation. | |||
- Corrected text in Preempt_Mode definition. | - Corrected text in Preempt_Mode definition. | |||
- Changed authentication to be per Virtual Router instead of per | - Changed authentication to be per Virtual Router instead of per | |||
skipping to change at page 27, line 21 | skipping to change at page 29, line 48 | |||
mapping of IPv6 address owner, priorities, etc. | mapping of IPv6 address owner, priorities, etc. | |||
- Clarify the section 7.1 text describing address list validation. | - Clarify the section 7.1 text describing address list validation. | |||
- Corrected text in Preempt_Mode definition. | - Corrected text in Preempt_Mode definition. | |||
- Changed authentication to be per Virtual Router instead of per | - Changed authentication to be per Virtual Router instead of per | |||
Interface. | Interface. | |||
- 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.3) 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 against this | ||||
draft. | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |