rfc2365.txt

RFC 的详细文档！


RFC 2365          Administratively Scoped IP Multicast         July 1998


8. Partitioning of the Administratively Scoped Multicast Space

   The following table outlines the partitioning of the IPv4 multicast
   space, and gives the mapping from IPv4 multicast prefixes to IPv6
   SCOP values:

   IPv6 SCOP  RFC 1884 Description             IPv4 Prefix
   ===============================================================
   0          reserved
   1          node-local scope
   2          link-local scope             224.0.0.0/24
   3          (unassigned)                 239.255.0.0/16
   4          (unassigned)
   5          site-local scope
   6          (unassigned)
   7          (unassigned)
   8          organization-local scope     239.192.0.0/14
   A          (unassigned)
   B          (unassigned)
   C          (unassigned)
   D          (unassigned)
   E          global scope                 224.0.1.0-238.255.255.255
   F          reserved
              (unassigned)                 239.0.0.0/10
              (unassigned)                 239.64.0.0/10
              (unassigned)                 239.128.0.0/10

9. Structure and Use of a Scoped Region

   The high order /24 in every scoped region is reserved for relative
   assignments. A relative assignment is an integer offset from highest
   address in the scope and represents a 32-bit address (for IPv4). For
   example, in the Local Scope defined above, 239.255.255.0/24 is
   reserved for relative allocations. The de-facto relative assignment
   "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
   SAP [SAP]. The next relative assignment, "1", corresponds to the
   address 239.255.255.254 in the Local Scope. The rest of a scoped
   region below the reserved /24 is available for dynamic assignment
   (presumably by an address allocation protocol).

   In is important to note that a scope discovery protocol [MZAP] will
   have to be developed to make practical use of scopes other than the
   Local Scope. In addition, since any use of any administratively
   scoped region, including the Local Scope, requires dynamically
   assigned addressing, an Address Allocation Protocol (AAP) will need
   to be developed to make administrative scoping generally useful.





Meyer                    Best Current Practice                  [Page 5]

RFC 2365          Administratively Scoped IP Multicast         July 1998


9.1. Relative Assignment Guidelines

   Requests for relative assignments should be directed to the IANA. The
   IANA will be advised by an area expert when making relative address
   assignments. The area expert will be appointed by the relevant Area
   Director.

   In general, relative addresses will be used only for bootstrapping to
   dynamic address assignments from within the scope.  As such, relative
   assignments should only be made to those services that cannot use a
   dynamic address assignment protocol to find the address used by that
   service within the desired scope, such as a dynamic address
   assignment service itself.

   10. Security Considerations

   It is recommended that organizations using the administratively
   scoped IP Multicast addresses not rely on them to prevent sensitive
   data from being transmitted outside the organization.  Should a
   multicast router on an administrative boundary be mis-configured,
   have a bug in the administrative scoping code, or have other problems
   that would cause that router to forward an administratively scoped IP
   multicast packet outside of the proper scope, the organizations data
   would leave its intended transmission region.

   Organizations using administratively scoped IP Multicasting to
   transmit sensitive data should use some confidentiality mechanism
   (e.g. encryption) to protect that data.  In the case of many existing
   video-conferencing applications (e.g. vat), encryption is available
   as an application feature and merely needs to be enabled (and
   appropriate cryptographic keys securely distributed). For many other
   applications, the use of the IP Encapsulating Security Payload (ESP)
   [RFC-1825, RFC-1827] can provide IP-layer confidentiality though
   encryption.

   Within the context of an administratively scoped IP multicast group,
   the use of manual key distribution might well be feasible.  While
   dynamic key management for IP Security is a research area at the time
   this note is written, it is expected that the IETF will be extending
   the ISAKMP key management protocol to support scalable multicast key
   distribution in the future.

   It is important to note that the "boundary router" described in this
   note is not necessarily providing any kind of firewall capability.







Meyer                    Best Current Practice                  [Page 6]

RFC 2365          Administratively Scoped IP Multicast         July 1998


11. References

   [ASMA]    V. Jacobson,  S. Deering, "Administratively Scoped IP
             Multicast", presented at the 30th IETF, Toronto, Canada, 25
             July 1994.

   [DVMRP]   Pusateri, T., "Distance Vector Multicast Routing Protocol",
             Work in Progress.

   [MZAP]    Handley, M., "Multicast-Scope Zone Announcement Protocol
             (MZAP)", Work in Progress.

   [PIMDM]   Deering, S, et. al., "Protocol Independent Multicast
             Version 2, Dense Mode Specification", Work in Progress.

   [PIMSM]   Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
             S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
             Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM):
             Protocol Specification", RFC 2362, June 1998.

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

   [RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing
             Architecture", RFC1884, December 1995.

   [SAP]     Handley, M., "SAP: Session Announcement Protocol", Work in
             Progress.

12. Author's Address

   David Meyer
   Cisco Systems
   San Jose, CA

   EMail:  [e-mail]















Meyer                    Best Current Practice                  [Page 7]

RFC 2365          Administratively Scoped IP Multicast         July 1998


13.  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.
























Meyer                    Best Current Practice                  [Page 8]