rfc2776.txt

<VC++网络游戏建摸与实现>源代码

   [ZCM-RELATIVE-GROUP]:  The relative group in each scope zone, to
   which ZCMs are sent.  A Zone Boundary Router listens to the relative
   group in each scope for which it is a boundary.  Value: (last IP
   address in scope range) - 3.  For example, in the Local Scope, the
   relative group is the same as the [MZAP-LOCAL-GROUP] address.

   [ZAM-INTERVAL]:  The interval at which a Zone Boundary Router
   originates Zone Announcement Messages.  Default value: 600 seconds
   (10 minutes).

   [ZAM-HOLDTIME]:  The holdtime to include in a ZAM.  This SHOULD be
   set to at least 3 * [ZAM-INTERVAL].  Default value: 1860 seconds (31
   minutes).




Handley, et al.             Standards Track                    [Page 22]

RFC 2776                          MZAP                     February 2000


   [ZAM-DUP-TIME]:  The time interval after forwarding a ZAM, during
   which ZAMs for the same scope will not be forwarded.  Default value:
   30 seconds.

   [ZCM-INTERVAL]:  The interval at which a Zone Boundary Router
   originates Zone Convexity Messages.  Default value: 600 seconds (10
   minutes).

   [ZCM-HOLDTIME]:  The holdtime to include in a ZCM.  This SHOULD be
   set to at least 3 * [ZCM-INTERVAL].  Default value: 1860 seconds (31
   minutes).

   [ZLE-SUPPRESSION-INTERVAL]:  The interval over which to choose a
   random delay before sending a ZLE message.  Default value: 300
   seconds (5 minutes).

   [ZLE-MIN-INTERVAL]:  The minimum interval between sending ZLE
   messages, regardless of destination.  Default value: 300 seconds (5
   minutes).

   [NIM-INTERVAL]:  The interval at which a Zone Boundary Router
   originates Not-Inside Messages.  Default value: 1800 seconds (30
   minutes).

   [NIM-HOLDTIME]:   The holdtime to include the state within a NIM.
   This SHOULD be set to at least 3 * [NIM-INTERVAL]. Default value:
   5460 (91 minutes)

8.  Security Considerations

   While unauthorized reading of MZAP messages is relatively innocuous
   (so encryption is generally not an issue), accepting unauthenticated
   MZAP messages can be problematic.  Authentication of MZAP messages
   can be provided by using the IPsec Authentication Header (AH) [12].

   In the case of ZCMs and ZLEs, an attacker can cause false logging of
   convexity and leakage problems.  It is likely that is would be purely
   an annoyance, and not cause any significant problem.  (Such messages
   could be authenticated, but since they may be sent within large
   scopes, the receiver may not be able to authenticate a non-malicious
   sender.)

   ZAMs and NIMs, on the other hand, are sent within the Local Scope,
   where assuming a security relationship between senders and receivers
   is more practical.






Handley, et al.             Standards Track                    [Page 23]

RFC 2776                          MZAP                     February 2000


   In the case of NIMs, accepting unauthenticated messages can cause the
   false cancellation of nesting relationships.  This would cause a
   section of the hierarchy of zones to flatten.  Such a flattening
   would lessen the efficiency benefits afforded by the hierarchy but
   would not cause it to become unusable.

   Accepting unauthenticated ZAM messages, however, could cause
   applications to believe that a scope zone exists when it does not.
   If these were believed, then applications may choose to use this
   non-existent administrative scope for their uses.  Such applications
   would be able to communicate successfully, but would be unaware that
   their traffic may be traveling further than they expected.  As a
   result, any application accepting unauthenticated ZAMs MUST only take
   scope names as a guideline, and SHOULD assume that their traffic sent
   to non-local scope zones might travel anywhere.  The confidentiality
   of such traffic CANNOT be assumed from the fact that it was sent to a
   scoped address that was discovered using MZAP.

   In addition, ZAMs are used to inform Multicast Address Allocation
   Servers (MAASs) of names and address ranges of scopes, and accepting
   unauthenticated ZAMs could result in false names being presented to
   users, and in wrong addresses being allocated to users.  To counter
   this, MAAS's authenticate ZAMs as follows:

   (1) A ZBR signs all ZAMs it originates (using an AH).

   (2) A ZBR signs a ZAM it relays if and only if it can authenticate
       the previous sender.  A ZBR MUST still forward un-authenticated
       ZAMs (to provide leak detection), but should propagate an
       authenticated ZAM even if an un-authenticated one was received
       with the last [ZAM-DUP-TIME] seconds.

   (3) A MAAS SHOULD be configured with the public key of the local zone
       in which it resides.  A MAAS thus configured SHOULD ignore an
       unauthenticated ZAM if an authenticated one for the same scope
       has been received, and MAY ignore all unauthenticated ZAMs.

9.  Acknowledgements

   This document is a product of the MBone Deployment Working Group,
   whose members provided many helpful comments and suggestions, Van
   Jacobson provided some of the original ideas that led to this
   protocol.  The Multicast Address Allocation Working Group also
   provided useful feedback regarding scope names and interactions with
   applications.






Handley, et al.             Standards Track                    [Page 24]

RFC 2776                          MZAP                     February 2000


10.  References

   [1]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
        2365, July 1998.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast
        Address Allocation Architecture", Work in Progress.

   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [5]  Fenner, W. and S. Casner, "A `traceroute' facility for IP
        Multicast", Work in Progress.

   [6]  Alvestrand, H., "Tags for the Identification of Languages", RFC
        1766, March 1995.

   [7]  Handley, M. and S. Hanna.  "Multicast Address Allocation
        Protocol (AAP)", Work in Progress.

   [8]  Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward
        Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
        Vancouver, Canada.

   [9]  Hanna, S., Patel, B., and M. Shah.  "Multicast Address Dynamic
        Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

   [10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.

   [11] IANA, "Address Family Numbers", http://www.isi.edu/in-
        notes/iana/assignments/address-family-numbers

   [12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
        November 1998.













Handley, et al.             Standards Track                    [Page 25]

RFC 2776                          MZAP                     February 2000


11.  Authors' Addresses

   Mark Handley
   AT&T Center for Internet Research at ICSI
   1947 Center St, Suite 600
   Berkely, CA 94704
   USA

   EMail: [e-mail]


   David Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA 98052
   USA

   EMail: [e-mail]


   Roger Kermode
   Motorola Australian Research Centre
   12 Lord St,
   Botany, NSW 2019
   Australia

   EMail: [e-mail]
























Handley, et al.             Standards Track                    [Page 26]

RFC 2776                          MZAP                     February 2000


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Handley, et al.             Standards Track                    [Page 27]