rfc2338.txt

中、英文RFC文档大全打包下载完全版 .

   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: [phone]
   Ascend Communications                EMail: [e-mail]
   High Performance Network Division
   10250 Valley View Road, Suite 113
   Eden Prairie, MN USA 55344
   USA

   Douglas Weaver                       Phone: [phone]
   Ascend Communications                EMail: [e-mail]
   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: [phone]
   Microsoft Corporation                EMail: [e-mail]
   One Microsoft Way
   Redmond, WA USA 98052-6399
   USA

   Robert Hinden                        Phone: [phone]
   Nokia                                EMail: [e-mail]
   232 Java Drive
   Sunnyvale, CA 94089
   USA

   Danny Mitzel                         Phone: [phone]
   Nokia                                EMail: [e-mail]
   232 Java Drive
   Sunnyvale, CA 94089
   USA

   Peter Hunt                           Phone: [phone]
   Nokia                                EMail: [e-mail]
   232 Java Drive
   Sunnyvale, CA 94089
   USA

   P. Higginson                         Phone: [phone]
   Digital Equipment Corp.              EMail: [e-mail]
   Digital Park
   Imperial Way
   Reading
   Berkshire
   RG2 0TE
   UK

   M. Shand                             Phone: [phone]
   Digital Equipment Corp.              EMail: [e-mail]
   Digital Park
   Imperial Way
   Reading
   Berkshire
   RG2 0TE
   UK

   Acee Lindem                          Phone: [phone]
   IBM Corporation                      E-Mail: [e-mail]
   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]