doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc2365.txt b/doc/rfc/rfc2365.txt
new file mode 100644
index 0000000..ef6c1b5
--- /dev/null
+++ b/doc/rfc/rfc2365.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           D. Meyer
+Request for Comments: 2365                          University of Oregon
+BCP: 23                                                        July 1998
+Category: Best Current Practice
+
+
+                  Administratively Scoped IP Multicast
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1. Abstract
+
+   This document defines the "administratively scoped IPv4 multicast
+   space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it
+   describes a simple set of semantics for the implementation of
+   Administratively Scoped IP Multicast. Finally, it provides a mapping
+   between the IPv6 multicast address classes [RFC1884] and IPv4
+   multicast address classes.
+
+   This memo is a product of the MBONE Deployment Working Group (MBONED)
+   in the Operations and Management Area of the Internet Engineering
+   Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
+
+2. Acknowledgments
+
+   Much of this memo is taken from "Administratively Scoped IP
+   Multicast", Van Jacobson and Steve Deering, presented at the 30th
+   IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and
+   Dave Thaler have also provided insightful comments on earlier
+   versions of this document.
+
+3. Introduction
+
+   Most current IP multicast implementations achieve some level of
+   scoping by using the TTL field in the IP header. Typical MBONE
+   (Multicast Backbone) usage has been to engineer TTL thresholds that
+   confine traffic to some administratively defined topological region.
+   The basic forwarding rule for interfaces with configured TTL
+   thresholds is that a packet is not forwarded across the interface
+   unless its remaining TTL is greater than the threshold.
+
+
+
+Meyer                    Best Current Practice                  [Page 1]
+
+RFC 2365          Administratively Scoped IP Multicast         July 1998
+
+
+   TTL scoping has been used to control the distribution of multicast
+   traffic with the objective of easing stress on scarce resources
+   (e.g., bandwidth), or to achieve some kind of improved privacy or
+   scaling properties. In addition, the TTL is also used in its
+   traditional role to limit datagram lifetime. Given these often
+   conflicting roles, TTL scoping has proven difficult to implement
+   reliably, and the resulting schemes have often been complex and
+   difficult to understand.
+
+   A more serious architectural problem concerns the interaction of TTL
+   scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The
+   particular problem is that in many common cases, TTL scoping can
+   prevent pruning from being effective. Consider the case in which a
+   packet has either had its TTL expire or failed a TTL threshold. The
+   router which discards the packet will not be capable of pruning any
+   upstream sources, and thus will sink all multicast traffic (whether
+   or not there are downstream receivers). Note that while it might seem
+   possible to send prunes upstream from the point at which a packet is
+   discarded, this strategy can result in legitimate traffic being
+   discarded, since subsequent packets could take a different path and
+   arrive at the same point with a larger TTL.
+
+   On the other hand, administratively scoped IP multicast can provide
+   clear and simple semantics for scoped IP multicast. The key
+   properties of administratively scoped IP multicast are that (i).
+   packets addressed to administratively scoped multicast addresses do
+   not cross configured administrative boundaries, and (ii).
+   administratively scoped multicast addresses are locally assigned, and
+   hence are not required to be unique across administrative boundaries.
+
+4. Definition of the Administratively Scoped IPv4 Multicast Space
+
+   The administratively scoped IPv4 multicast address space is defined
+   to be the range 239.0.0.0 to 239.255.255.255.
+
+5. Discussion
+
+   In order to support administratively scoped IP multicast, a router
+   should support the configuration of per-interface scoped IP multicast
+   boundaries. Such a router, called a boundary router, does not forward
+   packets matching an interface's boundary definition in either
+   direction (the bi-directional check prevents problems with multi-
+   access networks). In addition, a boundary router always prunes the
+   boundary for dense-mode groups [PIMDM], and doesn't accept joins for
+   sparse-mode groups [PIMSM] in the administratively scoped range.
+
+
+
+
+
+
+Meyer                    Best Current Practice                  [Page 2]
+
+RFC 2365          Administratively Scoped IP Multicast         July 1998
+
+
+6. The Structure of the Administratively Scoped Multicast Space
+
+   The structure of the IP version 4 administratively scoped multicast
+   space is loosely based on the IP Version 6 Addressing Architecture
+   described in RFC 1884 [RFC1884]. This document defines two important
+   scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These
+   scopes are described below.
+
+6.1. The IPv4 Local Scope -- 239.255.0.0/16
+
+   239.255.0.0/16 is defined to be the IPv4 Local Scope.  The Local
+   Scope is the minimal enclosing scope, and hence is not further
+   divisible. Although the exact extent of a Local Scope is site
+   dependent, locally scoped regions must obey certain topological
+   constraints. In particular, a Local Scope must not span any other
+   scope boundary. Further, a Local Scope must be completely contained
+   within or equal to any larger scope. In the event that scope regions
+   overlap in area, the area of overlap must be in its own local scope.
+   This implies that any scope boundary is also a boundary for the Local
+   Scope. The more general topological requirements for administratively
+   scoped regions are discussed below.
+
+   6.1.1. Expansion of the IPv4 Local Scope
+
+   The IPv4 Local Scope space grows "downward". As such, the IPv4 Local
+   Scope may grow downward from 239.255.0.0/16 into the reserved ranges
+   239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not
+   be utilized until the 239.255.0.0/16 space is no longer sufficient.
+
+6.2. The IPv4 Organization Local Scope -- 239.192.0.0/14
+
+   239.192.0.0/14 is defined to be the IPv4 Organization Local Scope,
+   and is the space from which an organization should allocate sub-
+   ranges when defining scopes for private use.
+
+6.2.1. Expansion of the IPv4 Organization Local Scope
+
+   The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are
+   unassigned and available for expansion of this space.  These ranges
+   should be left unassigned until the 239.192.0.0/14 space is no longer
+   sufficient. This is to allow for the possibility that future
+   revisions of this document may define additional scopes on a scale
+   larger than organizations.
+
+6.3. Other IPv4 Scopes of Interest
+
+   The other two scope classes of interest, statically assigned link-
+   local scope and global scope already exist in IPv4 multicast space.
+
+
+
+Meyer                    Best Current Practice                  [Page 3]
+
+RFC 2365          Administratively Scoped IP Multicast         July 1998
+
+
+   The statically assigned link-local scope is 224.0.0.0/24. The
+   existing static global scope allocations are somewhat more granular,
+   and include
+
+        224.1.0.0-224.1.255.255         ST Multicast Groups
+        224.2.0.0-224.2.127.253         Multimedia Conference Calls
+        224.2.127.254                   SAPv1 Announcements
+        224.2.127.255                   SAPv0 Announcements (deprecated)
+        224.2.128.0-224.2.255.255       SAP Dynamic Assignments
+        224.252.0.0-224.255.255.255     DIS transient groups
+        232.0.0.0-232.255.255.255       VMTP transient groups
+
+   See [RFC1700] for current multicast address assignments (this list
+   can also be found, possibly in a more current form, on
+   ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
+
+7. Topological Requirements for Administrative Boundaries
+
+   An administratively scoped IP multicast region is defined to be a
+   topological region in which there are one or more boundary routers
+   with common boundary definitions. Such a router is said to be a
+   boundary for scoped addresses in the range defined in its
+   configuration.
+
+   Network administrators may configure a scope region whenever
+   constrained multicast scope is required. In addition, an
+   administrator may configure overlapping scope regions (networks can
+   be in multiple scope regions) where convenient, with the only
+   limitations being that a scope region must be connected (there must
+   be a path between any two nodes within a scope region that doesn't
+   leave that region), and convex (i.e., no path between any two points
+   in the region can cross a region boundary). However, it is important
+   to note that if administratively scoped areas intersect
+   topologically, then the outer scope must consist of its address space
+   minus the address spaces of any intersecting scopes. This requirement
+   prevents the problem that would arise when a path between two points
+   in a convex region crosses the boundary of an intersecting region.
+   For this reason, it is recommended that administrative scopes that
+   intersect topologically should not intersect in address range.
+
+   Finally, note that any scope boundary is a boundary for the Local
+   Scope. This implies that packets sent to groups covered by
+   239.255.0.0/16 must not be forwarded across any link for which a
+   scoped boundary is defined.
+
+
+
+
+
+
+
+Meyer                    Best Current Practice                  [Page 4]
+
+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:  dmm@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+