summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2338.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2338.txt')
-rw-r--r--doc/rfc/rfc2338.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc2338.txt b/doc/rfc/rfc2338.txt
new file mode 100644
index 0000000..1f0ad02
--- /dev/null
+++ b/doc/rfc/rfc2338.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group S. Knight
+Request for Comments: 2338 D. Weaver
+Category: Standards Track Ascend Communications, Inc.
+ D. Whipple
+ Microsoft, Inc.
+ R. Hinden
+ D. Mitzel
+ P. Hunt
+ Nokia
+ P. Higginson
+ M. Shand
+ Digital Equipment Corp.
+ A. Lindem
+ IBM Corporation
+ April 1998
+
+
+ Virtual Router Redundancy Protocol
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ This memo defines the Virtual Router Redundancy Protocol (VRRP).
+ VRRP specifies an election protocol that dynamically assigns
+ responsibility for a virtual router to one of the VRRP routers on a
+ LAN. The VRRP router controlling the IP address(es) associated with
+ a virtual router is called the Master, and forwards packets sent to
+ these IP addresses. The election process provides dynamic fail over
+ in the forwarding responsibility should the Master become
+ unavailable. This allows any of the virtual router IP addresses on
+ the LAN to be used as the default first hop router by end-hosts. The
+ advantage gained from using VRRP is a higher availability default
+ path without requiring configuration of dynamic routing or router
+ discovery protocols on every end-host.
+
+
+
+
+
+
+Knight, et. al. Standards Track [Page 1]
+
+RFC 2338 VRRP April 1998
+
+
+Table of Contents
+
+ 1. Introduction...............................................2
+ 2. Required Features..........................................5
+ 3. VRRP Overview..............................................6
+ 4. Sample Configurations......................................8
+ 5. Protocol...................................................9
+ 5.1 VRRP Packet Format....................................10
+ 5.2 IP Field Descriptions.................................10
+ 5.3 VRRP Field Descriptions...............................11
+ 6. Protocol State Machine....................................13
+ 6.1 Parameters............................................13
+ 6.2 Timers................................................15
+ 6.3 State Transition Diagram..............................15
+ 6.4 State Descriptions....................................15
+ 7. Sending and Receiving VRRP Packets........................18
+ 7.1 Receiving VRRP Packets................................18
+ 7.2 Transmitting Packets..................................19
+ 7.3 Virtual MAC Address...................................19
+ 8. Operational Issues........................................20
+ 8.1 ICMP Redirects........................................20
+ 8.2 Host ARP Requests.....................................20
+ 8.3 Proxy ARP.............................................20
+ 9. Operation over FDDI and Token Ring........................21
+ 9.1 Operation over FDDI...................................21
+ 9.2 Operation over Token Ring.............................21
+ 10. Security Considerations...................................23
+ 10.1 No Authentication....................................23
+ 10.2 Simple Text Password.................................23
+ 10.3 IP Authentication Header.............................24
+ 11. Acknowledgments...........................................24
+ 12. References................................................24
+ 13. Authors' Addresses........................................25
+ 14. Full Copyright Statement..................................27
+
+1. Introduction
+
+ There are a number of methods that an end-host can use to determine
+ its first hop router towards a particular IP destination. These
+ include running (or snooping) a dynamic routing protocol such as
+ Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running
+ an ICMP router discovery client [DISC] or using a statically
+ configured default route.
+
+ Running a dynamic routing protocol on every end-host may be
+ infeasible for a number of reasons, including administrative
+ overhead, processing overhead, security issues, or lack of a protocol
+ implementation for some platforms. Neighbor or router discovery
+
+
+
+Knight, et. al. Standards Track [Page 2]
+
+RFC 2338 VRRP April 1998
+
+
+ protocols may require active participation by all hosts on a network,
+ leading to large timer values to reduce protocol overhead in the face
+ of large numbers of hosts. This can result in a significant delay in
+ the detection of a lost (i.e., dead) neighbor, which may introduce
+ unacceptably long "black hole" periods.
+
+ The use of a statically configured default route is quite popular; it
+ minimizes configuration and processing overhead on the end-host and
+ is supported by virtually every IP implementation. This mode of
+ operation is likely to persist as dynamic host configuration
+ protocols [DHCP] are deployed, which typically provide configuration
+ for an end-host IP address and default gateway. However, this
+ creates a single point of failure. Loss of the default router
+ results in a catastrophic event, isolating all end-hosts that are
+ unable to detect any alternate path that may be available.
+
+ The Virtual Router Redundancy Protocol (VRRP) is designed to
+ eliminate the single point of failure inherent in the static default
+ routed environment. VRRP specifies an election protocol that
+ dynamically assigns responsibility for a virtual router to one of the
+ VRRP routers on a LAN. The VRRP router controlling the IP
+ address(es) associated with a virtual router is called the Master,
+ and forwards packets sent to these IP addresses. The election
+ process provides dynamic fail-over in the forwarding responsibility
+ should the Master become unavailable. Any of the virtual router's IP
+ addresses on a LAN can then be used as the default first hop router
+ by end-hosts. The advantage gained from using VRRP is a higher
+ availability default path without requiring configuration of dynamic
+ routing or router discovery protocols on every end-host.
+
+ VRRP provides a function similar to a Cisco Systems, Inc. proprietary
+ protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a
+ Digital Equipment Corporation, Inc. proprietary protocol named IP
+ Standby Protocol [IPSTB].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ 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.
+
+
+
+
+
+
+Knight, et. al. Standards Track [Page 3]
+
+RFC 2338 VRRP April 1998
+
+
+1.1 Scope
+
+ The remainder of this document describes the features, design goals,
+ and theory of operation of VRRP. The message formats, protocol
+ processing rules and state machine that guarantee convergence to a
+ single Virtual Router Master are presented. Finally, operational
+ issues related to MAC address mapping, handling of ARP requests,
+ generation of ICMP redirect messages, and security issues are
+ addressed.
+
+ This protocol is intended for use with IPv4 routers only. A separate
+ specification will be produced if it is decided that similar
+ functionality is desirable in an IPv6 environment.
+
+1.2 Definitions
+
+ VRRP Router A router running the Virtual Router Redundancy
+ Protocol. It may participate in one or more
+ virtual routers.
+
+ Virtual Router An abstract object managed by VRRP that acts
+ as a default router for hosts on a shared LAN.
+ It consists of a Virtual Router Identifier and
+ a set of associated IP address(es) across a
+ common LAN. A VRRP Router may backup one or
+ more virtual routers.
+
+ IP Address Owner The VRRP router that has the virtual router's
+ IP address(es) as real interface address(es).
+ This is the router that, when up, will respond
+ to packets addressed to one of these IP
+ addresses for ICMP pings, TCP connections,
+ etc.
+
+ Primary IP Address An IP address selected from the set of real
+ interface addresses. One possible selection
+ algorithm is to always select the first
+ address. VRRP advertisements are always sent
+ using the primary IP address as the source of
+ the IP packet.
+
+ Virtual Router Master The VRRP router that is assuming the
+ responsibility of forwarding packets sent to
+ the IP address(es) associated with the virtual
+ router, and answering ARP requests for these
+ IP addresses. Note that if the IP address
+ owner is available, then it will always become
+ the Master.
+
+
+
+Knight, et. al. Standards Track [Page 4]
+
+RFC 2338 VRRP April 1998
+
+
+ Virtual Router Backup The set of VRRP routers available to assume
+ forwarding responsibility for a virtual router
+ should the current Master fail.
+
+2.0 Required Features
+
+ This section outlines the set of features that were considered
+ mandatory and that guided the design of VRRP.
+
+2.1 IP Address Backup
+
+ Backup of IP addresses is the primary function of the Virtual Router
+ Redundancy Protocol. While providing election of a Virtual Router
+ Master and the additional functionality described below, the protocol
+ should strive to:
+
+ - Minimize the duration of black holes.
+ - Minimize the steady state bandwidth overhead and processing
+ complexity.
+ - Function over a wide variety of multiaccess LAN technologies
+ capable of supporting IP traffic.
+ - Provide for election of multiple virtual routers on a network for
+ load balancing
+ - Support of multiple logical IP subnets on a single LAN segment.
+
+2.2 Preferred Path Indication
+
+ A simple model of Master election among a set of redundant routers is
+ to treat each router with equal preference and claim victory after
+ converging to any router as Master. However, there are likely to be
+ many environments where there is a distinct preference (or range of
+ preferences) among the set of redundant routers. For example, this
+ preference may be based upon access link cost or speed, router
+ performance or reliability, or other policy considerations. The
+ protocol should allow the expression of this relative path preference
+ in an intuitive manner, and guarantee Master convergence to the most
+ preferential router currently available.
+
+2.3 Minimization of Unnecessary Service Disruptions
+
+ Once Master election has been performed then any unnecessary
+ transitions between Master and Backup routers can result in a
+ disruption in service. The protocol should ensure after Master
+ election that no state transition is triggered by any Backup router
+ of equal or lower preference as long as the Master continues to
+ function properly.
+
+
+
+
+
+Knight, et. al. Standards Track [Page 5]
+
+RFC 2338 VRRP April 1998
+
+
+ Some environments may find it beneficial to avoid the state
+ transition triggered when a router becomes available that is more
+ preferential than the current Master. It may be useful to support an
+ override of the immediate convergence to the preferred path.
+
+2.4 Extensible Security
+
+ The virtual router functionality is applicable to a wide range of
+ internetworking environments that may employ different security
+ policies. The protocol should require minimal configuration and
+ overhead in the insecure operation, provide for strong authentication
+ when increased security is required, and allow integration of new
+ security mechanisms without breaking backwards compatible operation.
+
+2.5 Efficient Operation over Extended LANs
+
+ Sending IP packets on a multiaccess LAN requires mapping from an IP
+ address to a MAC address. The use of the virtual router MAC address
+ in an extended LAN employing learning bridges can have a significant
+ effect on the bandwidth overhead of packets sent to the virtual
+ router. If the virtual router MAC address is never used as the
+ source address in a link level frame then the station location is
+ never learned, resulting in flooding of all packets sent to the
+ virtual router. To improve the efficiency in this environment the
+ protocol should: 1) use the virtual router MAC as the source in a
+ packet sent by the Master to trigger station learning; 2) trigger a
+ message immediately after transitioning to Master to update the
+ station learning; and 3) trigger periodic messages from the Master to
+ maintain the station learning cache.
+
+3.0 VRRP Overview
+
+ VRRP specifies an election protocol to provide the virtual router
+ function described earlier. All protocol messaging is performed
+ using IP multicast datagrams, thus the protocol can operate over a
+ variety of multiaccess LAN technologies supporting IP multicast.
+ 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 a set of IP addresses. A VRRP router may associate a virtual
+ router with its real addresses 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 addresses must be coordinated among all VRRP routers on a LAN.
+
+
+
+Knight, et. al. Standards Track [Page 6]
+
+RFC 2338 VRRP April 1998
+
+
+ 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 pre-empt 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 pre-
+ emption attempts. The only exception is that a VRRP router will
+ always become Master of any virtual router associated with addresses
+ it owns. If the Master becomes unavailable then the highest priority
+ Backup will transition to Master after a short delay, providing a
+ controlled transition of the virtual router responsibility with
+ minimal service interruption.
+
+ VRRP defines three types of authentication providing simple
+ deployment in insecure environments, added protection against
+ misconfiguration, and strong sender authentication in security
+ conscious environments. Analysis of the protection provided and
+ vulnerability of each mechanism is deferred to Section 10.0 Security
+ Considerations. In addition new authentication types and data can be
+ defined in the future without affecting the format of the fixed
+ portion of the protocol packet, thus preserving backward compatible
+ operation.
+
+ The VRRP protocol design provides rapid transition from Backup to
+ Master to minimize service interruption, and incorporates
+ optimizations that reduce protocol complexity while guaranteeing
+ controlled Master transition for typical operational scenarios. The
+ optimizations result in an election protocol with minimal runtime
+ state requirements, minimal active protocol states, and a single
+ message type and sender. The typical operational scenarios are
+ defined to be two redundant routers and/or distinct path preferences
+ among each router. A side effect when these assumptions are violated
+ (i.e., more than two redundant paths all with equal preference) is
+ that duplicate packets may be forwarded for a brief period during
+ Master election. However, the typical scenario assumptions are
+ likely to cover the vast majority of deployments, loss of the Master
+ router is infrequent, and the expected duration in Master election
+ convergence is quite small ( << 1 second ). Thus the VRRP
+ optimizations represent significant simplifications in the protocol
+ design while incurring an insignificant probability of brief network
+ degradation.
+
+
+
+
+
+
+
+Knight, et. al. Standards Track [Page 7]
+
+RFC 2338 VRRP April 1998
+
+
+4. Sample Configurations
+
+4.1 Sample Configuration 1
+
+ The following figure shows a simple network with two VRRP routers
+ implementing one virtual router. Note that this example is provided
+ to help understand the protocol, but is not expected to occur in
+ actual practice.
+
+ +-----+ +-----+
+ | MR1 | | BR1 |
+ | | | |
+ | | | |
+ VRID=1 +-----+ +-----+
+ IP A ---------->* *<--------- IP B
+ | |
+ | |
+ | |
+ ------------------+------------+-----+--------+--------+--------+--
+ ^ ^ ^ ^
+ | | | |
+ (IP A) (IP A) (IP A) (IP A)
+ | | | |
+ +--+--+ +--+--+ +--+--+ +--+--+
+ | H1 | | H2 | | H3 | | H4 |
+ +-----+ +-----+ +--+--+ +--+--+
+
+ Legend:
+ ---+---+---+-- = Ethernet, Token Ring, or FDDI
+ H = Host computer
+ MR = Master Router
+ BR = Backup Router
+ * = IP Address
+ (IP) = default router for hosts
+
+ The above configuration shows a very simple VRRP scenario. In this
+ configuration, the end-hosts install a default route to the IP
+ address of virtual router #1 (IP A) and both routers run VRRP. The
+ router on the left becomes the Master for virtual router #1 (VRID=1)
+ and the router on the right is the Backup for virtual router #1. If
+ the router on the left should fail, the other router will take over
+ virtual router #1 and its IP addresses, and provide uninterrupted
+ service for the hosts.
+
+ Note that in this example, IP B is not backed up by the router on the
+ left. IP B is only used by the router on the right as its interface
+ address. In order to backup IP B, a second virtual router would have
+ to be configured. This is shown in the next section.
+
+
+
+Knight, et. al. Standards Track [Page 8]
+
+RFC 2338 VRRP April 1998
+
+
+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
+ expected to be very common in actual practice.
+
+ +-----+ +-----+
+ | MR1 | | MR2 |
+ | & | | & |
+ | BR2 | | BR1 |
+ VRID=1 +-----+ +-----+ VRID=2
+ IP A ---------->* *<---------- IP B
+ | |
+ | |
+ | |
+ ------------------+------------+-----+--------+--------+--------+--
+ ^ ^ ^ ^
+ | | | |
+ (IP A) (IP A) (IP B) (IP B)
+ | | | |
+ +--+--+ +--+--+ +--+--+ +--+--+
+ | H1 | | H2 | | H3 | | H4 |
+ +-----+ +-----+ +--+--+ +--+--+
+
+ Legend:
+ ---+---+---+-- = Ethernet, Token Ring, or FDDI
+ H = Host computer
+ MR = Master Router
+ BR = Backup Router
+ * = IP Address
+ (IP) = default router for hosts
+
+ In the above configuration, half of the hosts install a default route
+ to virtual router #1's IP address (IP A), and the other half of the
+ hosts install a default route to virtual router #2's IP address (IP
+ B). This has the effect of load balancing the outgoing traffic,
+ while also providing full redundancy.
+
+5.0 Protocol
+
+ The purpose of the VRRP packet is to communicate to all VRRP routers
+ the priority and the state of the Master router associated with the
+ Virtual Router ID.
+
+ VRRP packets are sent encapsulated in IP packets. They are sent to
+ the IPv4 multicast address assigned to VRRP.
+
+
+
+
+
+Knight, et. al. Standards Track [Page 9]
+
+RFC 2338 VRRP April 1998
+
+
+5.1 VRRP Packet Format
+
+ This section defines the format of the VRRP packet and the relevant
+ fields in the IP header.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Auth Type | Adver Int | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address (1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . |
+ | . |
+ | . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address (n) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Authentication Data (1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Authentication Data (2) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.2 IP Field Descriptions
+
+5.2.1 Source Address
+
+ The primary IP address of the interface the packet is being sent
+ from.
+
+5.2.2 Destination Address
+
+ The IP multicast address as assigned by the IANA for VRRP is:
+
+ 224.0.0.18
+
+ This is a link local scope multicast address. Routers MUST NOT
+ forward a datagram with this destination address regardless of its
+ TTL.
+
+5.2.3 TTL
+
+ The TTL MUST be set to 255. A VRRP router receiving a packet with
+ the TTL not equal to 255 MUST discard the packet.
+
+
+
+
+
+Knight, et. al. Standards Track [Page 10]
+
+RFC 2338 VRRP April 1998
+
+
+5.2.4 Protocol
+
+ The IP protocol number assigned by the IANA for VRRP is 112
+ (decimal).
+
+5.3 VRRP Field Descriptions
+
+5.3.1 Version
+
+ The version field specifies the VRRP protocol version of this packet.
+ This document defines version 2.
+
+5.3.2 Type
+
+ The type field specifies the type of this VRRP packet. The only
+ packet type defined in this version of the protocol is:
+
+ 1 ADVERTISEMENT
+
+ A packet with unknown type MUST be discarded.
+
+5.3.3 Virtual Rtr ID (VRID)
+
+ The Virtual Router Identifier (VRID) field identifies the virtual
+ router this packet is reporting status for.
+
+5.3.4 Priority
+
+ The priority field specifies the sending VRRP router's priority for
+ the virtual router. Higher values equal higher priority. This field
+ is an 8 bit unsigned integer field.
+
+ The priority value for the VRRP router that owns the IP address(es)
+ associated with the virtual router MUST be 255 (decimal).
+
+ VRRP routers backing up a virtual router MUST use priority values
+ between 1-254 (decimal). The default priority value for VRRP routers
+ backing up a virtual router is 100 (decimal).
+
+ The priority value zero (0) has special meaning indicating that the
+ current Master has stopped participating in VRRP. This is used to
+ trigger Backup routers to quickly transition to Master without having
+ to wait for the current Master to timeout.
+
+5.3.5 Count IP Addrs
+
+ The number of IP addresses contained in this VRRP advertisement.
+
+
+
+
+Knight, et. al. Standards Track [Page 11]
+
+RFC 2338 VRRP April 1998
+
+
+5.3.6 Authentication Type
+
+ The authentication type field identifies the authentication method
+ being utilized. Authentication type is unique on a per interface
+ basis. The authentication type field is an 8 bit unsigned integer.
+ A packet with unknown authentication type or that does not match the
+ locally configured authentication method MUST be discarded.
+
+ The authentication methods currently defined are:
+
+ 0 - No Authentication
+ 1 - Simple Text Password
+ 2 - IP Authentication Header
+
+5.3.6.1 No Authentication
+
+ The use of this authentication type means that VRRP protocol
+ exchanges are not authenticated. The contents of the Authentication
+ Data field should be set to zero on transmission and ignored on
+ reception.
+
+5.3.6.2 Simple Text Password
+
+ The use of this authentication type means that VRRP protocol
+ exchanges are authenticated by a clear text password. The contents
+ of the Authentication Data field should be set to the locally
+ configured password on transmission. There is no default password.
+ The receiver MUST check that the Authentication Data in the packet
+ matches its configured authentication string. Packets that do not
+ match MUST be discarded.
+
+ Note that there are security implications to using Simple Text
+ password authentication, and one should see the Security
+ Consideration section of this document.
+
+5.3.6.3 IP Authentication Header
+
+ The use of this authentication type means the VRRP protocol exchanges
+ are authenticated using the mechanisms defined by the IP
+ Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
+ and AH" [HMAC]. Keys may be either configured manually or via a key
+ distribution protocol.
+
+ If a packet is received that does not pass the authentication check
+ due to a missing authentication header or incorrect message digest,
+ then the packet MUST be discarded. The contents of the
+ Authentication Data field should be set to zero on transmission and
+ ignored on reception.
+
+
+
+Knight, et. al. Standards Track [Page 12]
+
+RFC 2338 VRRP April 1998
+
+
+5.3.7 Advertisement Interval (Adver Int)
+
+ The Advertisement interval indicates the time interval (in seconds)
+ between ADVERTISEMENTS. The default is 1 second. This field is used
+ for troubleshooting misconfigured routers.
+
+5.3.8 Checksum
+
+ The checksum field is used to detect data corruption in the VRRP
+ message.
+
+ The checksum is the 16-bit one's complement of the one's complement
+ sum of the entire VRRP message starting with the version field. For
+ computing the checksum, the checksum field is set to zero.
+
+5.3.9 IP Address(es)
+
+ One or more IP addresses that are associated with the virtual router.
+ The number of addresses included is specified in the "Count IP Addrs"
+ field. These fields are used for troubleshooting misconfigured
+ routers.
+
+5.3.10 Authentication Data
+
+ The authentication string is currently only utilized for simple text
+ authentication, similar to the simple text authentication found in
+ the Open Shortest Path First routing protocol [OSPF]. It is up to 8
+ characters of plain text. If the configured authentication string is
+ shorter than 8 bytes, the remaining space MUST be zero-filled. Any
+ VRRP packet received with an authentication string that does not
+ match the locally configured authentication string MUST be discarded.
+ The authentication string is unique on a per interface basis.
+
+ There is no default value for this field.
+
+6. Protocol State Machine
+
+6.1 Parameters
+
+6.1.1 Parameters per Interface
+
+
+ Authentication_Type Type of authentication being used. Values
+ are defined in section 5.3.6.
+
+ Authentication_Data Authentication data specific to the
+ Authentication_Type being used.
+
+
+
+
+Knight, et. al. Standards Track [Page 13]
+
+RFC 2338 VRRP April 1998
+
+
+6.1.2 Parameters per Virtual Router
+
+ VRID Virtual Router Identifier. Configured item
+ in the range 1-255 (decimal). There is no
+ default.
+
+ Priority Priority value to be used by this VRRP
+ router in Master election for this virtual
+ router. The value of 255 (decimal) is
+ reserved for the router that owns the IP
+ addresses associated with the virtual
+ router. The value of 0 (zero) is reserved
+ for Master router to indicate it is
+ releasing responsibility for the virtual
+ router. The range 1-254 (decimal) is
+ available for VRRP routers backing up the
+ virtual router. The default value is 100
+ (decimal).
+
+ IP_Addresses One or more IP addresses associated with
+ this virtual router. Configured item. No
+ default.
+
+ Advertisement_Interval Time interval between ADVERTISEMENTS
+ (seconds). Default is 1 second.
+
+ Skew_Time Time to skew Master_Down_Interval in
+ seconds. Calculated as:
+
+ ( (256 - Priority) / 256 )
+
+ Master_Down_Interval Time interval for Backup to declare Master
+ down (seconds). Calculated as:
+
+ (3 * Advertisement_Interval) + Skew_time
+
+ Preempt_Mode Controls whether a higher priority Backup
+ router preempts a lower priority Master.
+ Values are True to allow preemption and
+ False to not prohibit preemption. Default
+ is True.
+
+ Note: Exception is that the router that owns
+ the IP address(es) associated with the
+ virtual router always pre-empts independent
+ of the setting of this flag.
+
+
+
+
+
+Knight, et. al. Standards Track [Page 14]
+
+RFC 2338 VRRP April 1998
+
+
+6.2 Timers
+
+ Master_Down_Timer Timer that fires when ADVERTISEMENT has not
+ been heard for Master_Down_Interval.
+
+ Adver_Timer Timer that fires to trigger sending of
+ ADVERTISEMENT based on
+ Advertisement_Interval.
+
+6.3 State Transition Diagram
+
+ +---------------+
+ +--------->| |<-------------+
+ | | Initialize | |
+ | +------| |----------+ |
+ | | +---------------+ | |
+ | | | |
+ | V V |
+ +---------------+ +---------------+
+ | |---------------------->| |
+ | Master | | Backup |
+ | |<----------------------| |
+ +---------------+ +---------------+
+
+6.4 State Descriptions
+
+ In the state descriptions below, the state names are identified by
+ {state-name}, and the packets are identified by all upper case
+ characters.
+
+ A VRRP router implements an instance of the state machine for each
+ virtual router election it is participating in.
+
+6.4.1 Initialize
+
+ The purpose of this state is to wait for a Startup event. If a
+ Startup event is received, then:
+
+ - If the Priority = 255 (i.e., the router owns the IP address(es)
+ associated with the virtual router)
+
+ o Send an ADVERTISEMENT
+ o Broadcast a gratuitous ARP request containing the virtual
+ router MAC address for each IP address associated with the
+ virtual router.
+ o Set the Adver_Timer to Advertisement_Interval
+ o Transition to the {Master} state
+
+
+
+
+Knight, et. al. Standards Track [Page 15]
+
+RFC 2338 VRRP April 1998
+
+
+ else
+
+ o Set the Master_Down_Timer to Master_Down_Interval
+ o Transition to the {Backup} state
+
+ endif
+
+6.4.2 Backup
+
+ The purpose of the {Backup} state is to monitor the availability and
+ state of the Master Router.
+
+ While in this state, a VRRP router MUST do the following:
+
+ - MUST NOT respond to ARP requests for the IP address(s) associated
+ with the virtual router.
+
+ - MUST discard packets with a destination link layer MAC address
+ equal to the virtual router MAC address.
+
+ - MUST NOT accept packets addressed to the IP address(es) associated
+ with the virtual router.
+
+ - If a Shutdown event is received, then:
+
+ o Cancel the Master_Down_Timer
+ o Transition to the {Initialize} state
+
+ endif
+
+ - If the Master_Down_Timer fires, then:
+
+ o Send an ADVERTISEMENT
+ o Broadcast a gratuitous ARP request containing the virtual
+ router MAC address for each IP address associated with the
+ virtual router
+ o Set the Adver_Timer to Advertisement_Interval
+ o Transition to the {Master} state
+
+ endif
+
+ - If an ADVERTISEMENT is received, then:
+
+ If the Priority in the ADVERTISEMENT is Zero, then:
+
+ o Set the Master_Down_Timer to Skew_Time
+
+ else:
+
+
+
+Knight, et. al. Standards Track [Page 16]
+
+RFC 2338 VRRP April 1998
+
+
+ If Preempt_Mode is False, or If the Priority in the
+ ADVERTISEMENT is greater than or equal to the local
+ Priority, then:
+
+ o Reset the Master_Down_Timer to Master_Down_Interval
+
+ else:
+
+ o Discard the ADVERTISEMENT
+
+ endif
+ endif
+ endif
+
+6.4.3 Master
+
+ While in the {Master} state the router functions as the forwarding
+ router for the IP address(es) associated with the virtual router.
+
+ While in this state, a VRRP router MUST do the following:
+
+ - MUST respond to ARP requests for the IP address(es) associated
+ with the virtual router.
+
+ - MUST forward packets with a destination link layer MAC address
+ equal to the virtual router MAC address.
+
+ - MUST NOT accept packets addressed to the IP address(es) associated
+ with the virtual router if it is not the IP address owner.
+
+ - MUST accept packets addressed to the IP address(es) associated
+ with the virtual router if it is the IP address owner.
+
+ - If a Shutdown event is received, then:
+
+ o Cancel the Adver_Timer
+ o Send an ADVERTISEMENT with Priority = 0
+ o Transition to the {Initialize} state
+
+ endif
+
+ - If the Adver_Timer fires, then:
+
+ o Send an ADVERTISEMENT
+ o Reset the Adver_Timer to Advertisement_Interval
+
+ endif
+
+
+
+
+Knight, et. al. Standards Track [Page 17]
+
+RFC 2338 VRRP April 1998
+
+
+ - If an ADVERTISEMENT is received, then:
+
+ If the Priority in the ADVERTISEMENT is Zero, then:
+
+ o Send an ADVERTISEMENT
+ o Reset the Adver_Timer to Advertisement_Interval
+
+ else:
+
+ If the Priority in the ADVERTISEMENT is greater than the
+ local Priority,
+ or
+ If the Priority in the ADVERTISEMENT is equal to the local
+ Priority and the primary IP Address of the sender is greater
+ than the local primary IP Address, then:
+
+ o Cancel Adver_Timer
+ o Set Master_Down_Timer to Master_Down_Interval
+ o Transition to the {Backup} state
+
+ else:
+
+ o Discard ADVERTISEMENT
+
+ endif
+ endif
+ endif
+
+7. Sending and Receiving VRRP Packets
+
+7.1 Receiving VRRP Packets
+
+ Performed the following functions when a VRRP packet is received:
+
+ - MUST verify that the IP TTL is 255.
+ - MUST verify the VRRP version
+ - MUST verify that the received packet length is greater than or
+ equal to the VRRP header
+ - MUST verify the VRRP checksum
+ - MUST perform authentication specified by Auth Type
+
+ 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.
+
+ - MUST verify that the VRID is valid on the receiving interface
+
+ If the above check fails, the receiver MUST discard the packet.
+
+
+
+Knight, et. al. Standards Track [Page 18]
+
+RFC 2338 VRRP April 1998
+
+
+ - MAY verify that the IP address(es) associated with the VRID are
+ valid
+
+ 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.
+
+ - 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.
+
+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
+ - Set the source IP address to interface primary IP address
+ - Set the IP protocol to VRRP
+ - Send the VRRP packet to the VRRP IP multicast group
+
+ 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)
+
+ 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
+ mapping provides for up to 255 VRRP routers on a network.
+
+
+
+
+
+
+Knight, et. al. Standards Track [Page 19]
+
+RFC 2338 VRRP April 1998
+
+
+8. Operational Issues
+
+8.1 ICMP Redirects
+
+ ICMP Redirects may be used normally when VRRP is running between a
+ group of routers. This allows VRRP to be used in environments where
+ the topology is not symmetric.
+
+ The IP source address of an ICMP 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 Host ARP Requests
+
+ When a host sends an ARP request for one of the virtual router IP
+ addresses, the Master virtual router MUST respond to the ARP request
+ 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 VRRP router restarts or boots, it SHOULD not send any ARP
+ messages with its physical MAC address for the IP address it owns, it
+ should only send ARP messages that include Virtual MAC addresses.
+ This may entail:
+
+ - When configuring an interface, VRRP routers should broadcast a
+ gratuitous ARP request containing the virtual router MAC address
+ for each IP address on that interface.
+
+ - At system boot, when initializing interfaces for VRRP operation;
+ delay gratuitous ARP requests and ARP responses until both the IP
+ address and the virtual router MAC address are configured.
+
+8.3 Proxy ARP
+
+ If Proxy ARP is to be used on a VRRP router, then the VRRP router
+ must advertise the Virtual Router MAC address in the Proxy ARP
+ message. Doing otherwise could cause hosts to learn the real MAC
+ address of the VRRP router.
+
+
+
+Knight, et. al. Standards Track [Page 20]
+
+RFC 2338 VRRP April 1998
+
+
+9. Operation over FDDI and Token Ring
+
+9.1 Operation over FDDI
+
+ FDDI interfaces remove from the FDDI ring frames that have a source
+ MAC address matching the device's hardware address. Under some
+ conditions, such as router isolations, ring failures, protocol
+ transitions, etc., VRRP may cause there to be more than one Master
+ router. If a Master router installs the virtual router MAC address
+ as the hardware address on a FDDI device, then other Masters'
+ ADVERTISEMENTS will be removed from the ring during the Master
+ convergence, and convergence will fail.
+
+ To avoid this an implementation SHOULD configure the virtual router
+ MAC address by adding a unicast MAC filter in the FDDI device, rather
+ than changing its hardware MAC address. This will prevent a Master
+ router from removing any ADVERTISEMENTS it did not originate.
+
+9.2 Operation over Token Ring
+
+ Token ring has several characteristics which make running VRRP
+ difficult. These include:
+
+ - In order to switch to a new master located on a different bridge
+ token ring segment from the previous master when using source
+ route bridges, a mechanism is required to update cached source
+ route information.
+
+ - No general multicast mechanism supported across old and new token
+ ring adapter implementations. While many newer token ring adapters
+ support group addresses, token ring functional address support is
+ the only generally available multicast mechanism. Due to the
+ limited number of token ring functional addresses these may
+ collide with other usage of the same token ring functional
+ addresses.
+
+ Due to these difficulties, the preferred mode of operation over token
+ ring will be to use a token ring functional address for the VRID
+ virtual MAC address. Token ring functional addresses have the two
+ high order bits in the first MAC address octet set to B'1'. They
+ range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format).
+ However, unlike multicast addresses, there is only one unique
+ functional address per bit position. The functional addresses
+ addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved
+ by the Token Ring Architecture [TKARCH] for user-defined
+ applications. However, since there are only 12 user-defined token
+ ring functional addresses, there may be other non-IP protocols using
+ the same functional address. Since the Novell IPX [IPX] protocol uses
+
+
+
+Knight, et. al. Standards Track [Page 21]
+
+RFC 2338 VRRP April 1998
+
+
+ the 03-00-00-10-00-00 functional address, operation of VRRP over
+ token ring will avoid use of this functional address. In general,
+ token ring VRRP users will be responsible for resolution of other
+ user-defined token ring functional address conflicts.
+
+ VRIDs are mapped directly to token ring functional addresses. In
+ order to decrease the likelihood of functional address conflicts,
+ allocation will begin with the largest functional address. Most non-
+ IP protocols use the first or first couple user-defined functional
+ addresses and it is expected that VRRP users will choose VRIDs
+ sequentially starting with 1.
+
+ VRID Token Ring Functional Address
+ ---- -----------------------------
+ 1 03-00-02-00-00-00
+ 2 03-00-04-00-00-00
+ 3 03-00-08-00-00-00
+ 4 03-00-10-00-00-00
+ 5 03-00-20-00-00-00
+ 6 03-00-40-00-00-00
+ 7 03-00-80-00-00-00
+ 8 03-00-00-01-00-00
+ 9 03-00-00-02-00-00
+ 10 03-00-00-04-00-00
+ 11 03-00-00-08-00-00
+
+ Or more succinctly, octets 3 and 4 of the functional address are
+ equal to (0x4000 >> (VRID - 1)) in non-canonical format.
+
+ Since a functional address cannot be used used as a MAC level source
+ address, the real MAC address is used as the MAC source address in
+ VRRP advertisements. This is not a problem for bridges since packets
+ addressed to functional addresses will be sent on the spanning-tree
+ explorer path [802.1D].
+
+ The functional address mode of operation MUST be implemented by
+ routers supporting VRRP on token ring.
+
+ Additionally, routers MAY support unicast mode of operation to take
+ advantage of newer token ring adapter implementations which support
+ non-promiscuous reception for multiple unicast MAC addresses and to
+ avoid both the multicast traffic and usage conflicts associated with
+ the use of token ring functional addresses. Unicast mode uses the
+ same mapping of VRIDs to virtual MAC addresses as Ethernet. However,
+ one important difference exists. ARP request/reply packets contain
+ the virtual MAC address as the source MAC address. The reason for
+ this is that some token ring driver implementations keep a cache of
+ MAC address/source routing information independent of the ARP cache.
+
+
+
+Knight, et. al. Standards Track [Page 22]
+
+RFC 2338 VRRP April 1998
+
+
+ Hence, these implementations need have to receive a packet with the
+ virtual MAC address as the source address in order to transmit to
+ that MAC address in a source-route bridged network.
+
+ Unicast mode on token ring has one limitation which should be
+ considered. If there are VRID routers on different source-route
+ bridge segments and there are host implementations which keep their
+ source-route information in the ARP cache and do not listen to
+ gratuitous ARPs, these hosts will not update their ARP source-route
+ information correctly when a switch-over occurs. The only possible
+ solution is to put all routers with the same VRID on the same source-
+ bridge segment and use techniques to prevent that bridge segment from
+ being a single point of failure. These techniques are beyond the
+ scope this document.
+
+ For both the multicast and unicast mode of operation, VRRP
+ advertisements sent to 224.0.0.18 should be encapsulated as described
+ in [RFC1469].
+
+10. Security Considerations
+
+ VRRP is designed for a range of internetworking environments that may
+ employ different security policies. The protocol includes several
+ authentication methods ranging from no authentication, simple clear
+ text passwords, and strong authentication using IP Authentication
+ with MD5 HMAC. The details on each approach including possible
+ attacks and recommended environments follows.
+
+ Independent of any authentication type VRRP includes a mechanism
+ (setting TTL=255, checking on receipt) that protects against VRRP
+ packets being injected from another remote network. This limits most
+ vulnerabilities to local attacks.
+
+10.1 No Authentication
+
+ The use of this authentication type means that VRRP protocol
+ exchanges are not authenticated. This type of authentication SHOULD
+ only be used in environments were there is minimal security risk and
+ little chance for configuration errors (e.g., two VRRP routers on a
+ LAN).
+
+10.2 Simple Text Password
+
+ The use of this authentication type means that VRRP protocol
+ exchanges are authenticated by a simple clear text password.
+
+
+
+
+
+
+Knight, et. al. Standards Track [Page 23]
+
+RFC 2338 VRRP April 1998
+
+
+ This type of authentication is useful to protect against accidental
+ misconfiguration of routers on a LAN. It protects against routers
+ inadvertently backing up another router. A new router must first be
+ configured with the correct password before it can run VRRP with
+ another router. This type of authentication does not protect against
+ hostile attacks where the password can be learned by a node snooping
+ VRRP packets on the LAN. The Simple Text Authentication combined
+ with the TTL check makes it difficult for a VRRP packet to be sent
+ from another LAN to disrupt VRRP operation.
+
+ This type of authentication is RECOMMENDED when there is minimal risk
+ of nodes on a LAN actively disrupting VRRP operation. If this type
+ of authentication is used the user should be aware that this clear
+ text password is sent frequently, and therefore should not be the
+ same as any security significant password.
+
+10.3 IP Authentication Header
+
+ The use of this authentication type means the VRRP protocol exchanges
+ are authenticated using the mechanisms defined by the IP
+ Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP
+ and AH", [HMAC]. This provides strong protection against
+ configuration errors, replay attacks, and packet
+ corruption/modification.
+
+ This type of authentication is RECOMMENDED when there is limited
+ control over the administration of nodes on a LAN. While this type
+ of authentication does protect the operation of VRRP, there are other
+ types of attacks that may be employed on shared media links (e.g.,
+ generation of bogus ARP replies) which are independent from VRRP and
+ are not protected.
+
+11. Acknowledgments
+
+ The authors would like to thank Glen Zorn, and Michael Lane, Clark
+ Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve
+ Bellovin, and Thomas Narten for their comments and suggestions.
+
+12. References
+
+ [802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
+ 802.1D, 1993 edition.
+
+ [AUTH] Kent, S., and R. Atkinson, "IP Authentication Header",
+ Work in Progress.
+
+ [DISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
+ September 1991.
+
+
+
+Knight, et. al. Standards Track [Page 24]
+
+RFC 2338 VRRP April 1998
+
+
+ [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [HMAC] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
+ ESP and AH", Work in Progress.
+
+ [HSRP] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby
+ Router Protocol (HSRP)", RFC 2281, March 1998.
+
+ [IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
+ Provide Fast Failover in IP Networks", Digital Technical
+ Journal, Volume 9 Number 3, Winter 1997.
+
+ [IPX] Novell Incorporated., "IPX Router Specification", Version
+ 1.10, October 1992.
+
+ [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [RIP] Hedrick, C., "Routing Information Protocol", RFC 1058,
+ June 1988.
+
+ [RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June
+ 1993.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
+ SC30-3374-02, Third Edition, (September, 1989).
+
+13. Authors' Addresses
+
+ Steven Knight Phone: +1 612 943-8990
+ Ascend Communications EMail: Steven.Knight@ascend.com
+ High Performance Network Division
+ 10250 Valley View Road, Suite 113
+ Eden Prairie, MN USA 55344
+ USA
+
+ Douglas Weaver Phone: +1 612 943-8990
+ Ascend Communications EMail: Doug.Weaver@ascend.com
+ High Performance Network Division
+ 10250 Valley View Road, Suite 113
+ Eden Prairie, MN USA 55344
+ USA
+
+
+
+
+
+
+Knight, et. al. Standards Track [Page 25]
+
+RFC 2338 VRRP April 1998
+
+
+ David Whipple Phone: +1 206 703-3876
+ Microsoft Corporation EMail: dwhipple@microsoft.com
+ One Microsoft Way
+ Redmond, WA USA 98052-6399
+ USA
+
+ Robert Hinden Phone: +1 408 990-2004
+ Nokia EMail: hinden@iprg.nokia.com
+ 232 Java Drive
+ Sunnyvale, CA 94089
+ USA
+
+ Danny Mitzel Phone: +1 408 990-2037
+ Nokia EMail: mitzel@iprg.nokia.com
+ 232 Java Drive
+ Sunnyvale, CA 94089
+ USA
+
+ Peter Hunt Phone: +1 408 990-2093
+ Nokia EMail: hunt@iprg.nokia.com
+ 232 Java Drive
+ Sunnyvale, CA 94089
+ USA
+
+ P. Higginson Phone: +44 118 920 6293
+ Digital Equipment Corp. EMail: higginson@mail.dec.com
+ Digital Park
+ Imperial Way
+ Reading
+ Berkshire
+ RG2 0TE
+ UK
+
+ M. Shand Phone: +44 118 920 4424
+ Digital Equipment Corp. EMail: shand@mail.dec.com
+ Digital Park
+ Imperial Way
+ Reading
+ Berkshire
+ RG2 0TE
+ UK
+
+ Acee Lindem Phone: 1-919-254-1805
+ IBM Corporation E-Mail: acee@raleigh.ibm.com
+ P.O. Box 12195
+ Research Triangle Park, NC 27709
+ USA
+
+
+
+
+Knight, et. al. Standards Track [Page 26]
+
+RFC 2338 VRRP April 1998
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Knight, et. al. Standards Track [Page 27]
+