draft-ietf-vrrp-ipv6-spec-04.txt | draft-ietf-vrrp-ipv6-spec-05.txt | |||
---|---|---|---|---|
INTERNET-DRAFT R. Hinden/Nokia | INTERNET-DRAFT R. Hinden/Nokia | |||
May 20, 2003 | June 29, 2003 | |||
Virtual Router Redundancy Protocol for IPv6 | Virtual Router Redundancy Protocol for IPv6 | |||
<draft-ietf-vrrp-ipv6-spec-04.txt> | <draft-ietf-vrrp-ipv6-spec-05.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 November 20, 2003. | This internet draft expires on January 4, 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 | |||
skipping to change at page 7, line 4 | skipping to change at page 7, line 4 | |||
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 an IPv6 address. A VRRP router may associate a virtual router | |||
with its real address on an interface, and may also be configured | with its real address on an interface, and may also be configured | |||
with additional virtual router mappings and priority for virtual | 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. | IPv6 address must be coordinated among all VRRP routers on a LAN. | |||
However, there is no restriction against reusing a VRID with a | However, there is no restriction against reusing a VRID with a | |||
different address mapping on different LANs. The scope of each | different address mapping on different LANs. The scope of each | |||
virtual router is restricted to a single LAN. | 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 | |||
skipping to change at page 9, line 22 | skipping to change at page 9, line 22 | |||
hosts. | hosts. | |||
Note that in this example IPv6 B is not backed up, it is only used by | 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 | Rtr2 as its interface address. In order to backup IPv6 B, a second | |||
virtual router must be configured. This is shown in the next | virtual router must be configured. This is shown in the next | |||
section. | section. | |||
4.2 Sample Configuration 2 | 4.2 Sample Configuration 2 | |||
The following figure shows a configuration with two virtual routers | 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. | expected to be common in actual practice. | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
| Rtr1 | | Rtr2 | | | Rtr1 | | Rtr2 | | |||
|(MR VRID=1)| |(BR VRID=1)| | |(MR VRID=1)| |(BR VRID=1)| | |||
|(BR VRID=2)| |(MR VRID=2)| | |(BR VRID=2)| |(MR VRID=2)| | |||
VRID=1 +-----------+ +-----------+ VRID=2 | VRID=1 +-----------+ +-----------+ VRID=2 | |||
IPv6 A -------->* *<---------- IPv6 B | IPv6 A -------->* *<---------- IPv6 B | |||
| | | | | | |||
| | | | | | |||
skipping to change at page 18, line 21 | skipping to change at page 18, line 21 | |||
- MUST verify that the IPv6 Hop Limit is 255. | - MUST verify that the IPv6 Hop Limit is 255. | |||
- MUST verify the VRRP version is 3 | - MUST verify the VRRP version is 3 | |||
- MUST verify that the received packet contains the complete VRRP | - MUST verify that the received packet contains the complete VRRP | |||
packet (including fixed fields, and IPv6 Address. | packet (including fixed fields, and IPv6 Address. | |||
- MUST verify the VRRP checksum | - MUST verify the VRRP checksum | |||
- MUST verify that the VRID is configured on the receiving | - MUST verify that the VRID is configured on the receiving | |||
interface and the local router is not the IPv6 Address owner | interface and the local router is not the IPv6 Address owner | |||
(Priority equals 255 (decimal)). | (Priority equals 255 (decimal)). | |||
If any one of the above checks fails, the receiver MUST discard the | If any one of the above checks fails, the receiver MUST discard the | |||
packet, SHOULD log the event and MAY indicate via network management | packet, SHOULD log the event and SHOULD indicate via network | |||
that an error occurred. | management that an error occurred. | |||
- MAY verify that the IPv6 Address matches the IPv6_Address | - MAY verify that the IPv6 Address matches the IPv6_Address | |||
configured for the VRID. | configured for the VRID. | |||
If the above check fails, the receiver SHOULD log the event and MAY | If the above check fails, the receiver SHOULD log the event and | |||
indicate via network management that a misconfiguration was detected. | SHOULD indicate via network management that a misconfiguration was | |||
If the packet was not generated by the address owner (Priority does | detected. If the packet was not generated by the address owner | |||
not equal 255 (decimal)), the receiver MUST drop the packet, | (Priority does not equal 255 (decimal)), the receiver MUST drop the | |||
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 MUST discard the packet, | |||
SHOULD log the event and MAY indicate via network management that a | SHOULD log the event and SHOULD indicate via network management that | |||
misconfiguration was detected. | a misconfiguration was 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 19, line 14 | skipping to change at page 19, line 14 | |||
Note: VRRP packets are transmitted with the virtual router MAC | Note: VRRP packets are transmitted with the virtual router MAC | |||
address as the source MAC address to ensure that learning bridges | address as the source MAC address to ensure that learning bridges | |||
correctly determine the LAN segment the virtual router is attached | correctly determine the LAN segment the virtual router is attached | |||
to. | to. | |||
7.3 Virtual Router MAC Address | 7.3 Virtual Router MAC Address | |||
The virtual router MAC address associated with a virtual router is an | The virtual router MAC address associated with a virtual router is an | |||
IEEE 802 MAC Address in the following format: | 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 | 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 | octets (00-02) indicate the address block assigned to the VRRP for | |||
protocol. {VRID} is the VRRP Virtual Router Identifier. This | IPv6 protocol. {VRID} is the VRRP Virtual Router Identifier. This | |||
mapping provides for up to 255 VRRP routers on a network. | mapping provides for up to 255 VRRP routers on a network. | |||
7.4 IPv6 Interface Identifiers | 7.4 IPv6 Interface Identifiers | |||
IPv6 Routers running VRRP MUST create their Interface Identifiers in | IPv6 Routers running VRRP MUST create their Interface Identifiers in | |||
the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over | the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over | |||
Ethernet"). They MUST NOT use the Virtual Router MAC address to | Ethernet"). They MUST NOT use the Virtual Router MAC address to | |||
create the Modified EUI-64 identifiers. | create the Modified EUI-64 identifiers. | |||
This VRRP specification describes how to advertise and resolve the | This VRRP specification describes how to advertise and resolve the | |||
VRRP routers IPv6 link local address into the Virtual Router MAC | VRRP routers IPv6 link local address into the Virtual Router MAC | |||
address. | address. | |||
8. Operational Issues | 8. Operational Issues | |||
8.1 ICMPv6 Redirects | 8.1 ICMPv6 Redirects | |||
ICMPv6 Redirects may be used normally when VRRP is running between a | ICMPv6 Redirects may be used normally when VRRP is running between a | |||
group of routers [ICMPv6]. This allows VRRP to be used in | 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 IPv6 source address of an ICMPv6 redirect should be the address | |||
the end host used when making its next hop routing decision. If a | the end host used when making its next hop routing decision. If a | |||
VRRP router is acting as Master for virtual router(s) containing | VRRP router is acting as Master for virtual router(s) containing | |||
addresses it does not own, then it must determine which virtual | addresses it does not own, then it must determine which virtual | |||
router the packet was sent to when selecting the redirect source | router the packet was sent to when selecting the redirect source | |||
address. One method to deduce the virtual router used is to examine | address. One method to deduce the virtual router used is to examine | |||
the destination MAC address in the packet that triggered the | the destination MAC address in the packet that triggered the | |||
redirect. | 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 | 8.2 ND Neighbor Solicitation | |||
When a host sends an ND Neighbor Solicitation message for the virtual | When a host sends an ND Neighbor Solicitation message for the virtual | |||
router IPv6 address, the Master virtual router MUST respond to the ND | router IPv6 address, the Master virtual router MUST respond to the ND | |||
Neighbor Solicitation message with the virtual MAC address for the | Neighbor Solicitation message with the virtual MAC address for the | |||
virtual router. The Master virtual router MUST NOT respond with its | virtual router. The Master virtual router MUST NOT respond with its | |||
physical MAC address. This allows the client to always use the same | physical MAC address. This allows the client to always use the same | |||
MAC address regardless of the current Master router. | MAC address regardless of the current Master router. | |||
When a Master virtual routers sends an ND Neighbor Solicitation | When a Master virtual router sends an ND Neighbor Solicitation | |||
message for a hosts IPv6 address, the Master virtual router MUST | 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 | include the virtual MAC address for the virtual router if it sends a | |||
source link-layer address option in the neighbor solicitation | source link-layer address option in the neighbor solicitation | |||
message. It MUST NOT use its physical MAC address in the source | message. It MUST NOT use its physical MAC address in the source | |||
link-layer address option. | link-layer address option. | |||
When a VRRP router restarts or boots, it SHOULD not send any ND | 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, | messages with its physical MAC address for the IPv6 address it owns, | |||
it should only send ND messages that include Virtual MAC addresses. | it should only send ND messages that include Virtual MAC addresses. | |||
This may entail: | This may entail: | |||
skipping to change at page 24, line 42 | skipping to change at page 24, line 36 | |||
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. 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, and Steve Deering for their his helpful suggestions. | Thomas Narten, Steve Deering, Radia Perlman, and Danny Mitzel for | |||
their helpful suggestions. | ||||
12. IANA Considerations | 12. 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: | |||
FF02:0:0:0:0:0:0:12 | FF02:0:0:0:0:0:0:12 | |||
as this would be consistent with the IPv4 assignment for VRRP. | 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 | 13. 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", Internet Draft, <draft-ietf-ipngwg-addr- | Architecture", RFC3513, April 2003. | |||
arch-v3-11.txt>, October 2002. | ||||
[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. | |||
[ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol | [ICMPv6] Conta, A., S. Deering, "Internet Control Message Protocol | |||
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", | (ICMPv6) for the Internet Protocol Version 6 (IPv6)", | |||
RFC2463, December 1998. | RFC2463, December 1998. | |||
[IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6 | [IPv6] Deering, S., R. Hinden, "Internet Protocol, Version 6 | |||
(IPv6) Specification", RFC2460, December 1998. | (IPv6) Specification", RFC2460, December 1998. | |||
skipping to change at page 26, line 32 | skipping to change at page 26, line 36 | |||
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: hinden@iprg.nokia.com | |||
16. Changes from RFC2338 | 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 | - Removed different authentication methods, header fields, and | |||
updated the security considerations section. | updated the security considerations section. | |||
- 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 | o Change to only support one router address (instead of multiple | |||
addresses). This included removing address count field from | addresses). This included removing address count field from | |||
header. | header. | |||
o Rewrote text to specify IPv6 Neighbor Discovery mechanisms | o Rewrote text to specify IPv6 Neighbor Discovery mechanisms | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |