doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc2770.txt b/doc/rfc/rfc2770.txt
new file mode 100644
index 0000000..e7d614f
--- /dev/null
+++ b/doc/rfc/rfc2770.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                         D. Meyer
+Request for Comments: 2770                               Cisco Systems
+Category: Experimental                                     P. Lothberg
+                                                                Sprint
+                                                         February 2000
+
+
+                        GLOP Addressing in 233/8
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This describes an experimental policy for use of the class D address
+   space using 233/8 as the experimental statically assigned subset of
+   the class D address space. This new experimental allocation is in
+   addition to those described on [IANA] (e.g. [RFC2365]).
+
+   This memo is a product of the Multicast 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 authors.
+
+1. Problem Statement
+
+   Multicast addresses have traditionally been allocated by a dynamic
+   mechanism such as SDR [SAP]. However, many current multicast
+   deployment models are not amenable to dynamic allocation. For
+   example, many content aggregators require group addresses which are
+   fixed on a time scale which is not amenable to allocation by a
+   mechanism such as described in [SAP]. Perhaps more seriously, since
+   there isn't general consensus by providers, content aggregators, or
+   application writers as to the allocation mechanism, the Internet is
+   left without a coherent multicast address allocation scheme.
+
+
+
+
+
+
+
+
+Meyer & Lothberg              Experimental                      [Page 1]
+
+RFC 2770                GLOP Addressing in 233/8           February 2000
+
+
+   The MALLOC working group is looking at a specific strategy for global
+   multicast address allocation [MADCAP, MASC]. This experiment will
+   proceed in parallel. MADCAP may be employed within AS's, if so
+   desired.
+
+   This document proposes an experimental method of statically
+   allocating multicast addresses with global scope. This experiment
+   will last for a period of one year, but may be extended as described
+   in section 6.
+
+2. Address Space
+
+   For purposes of the experiment described here, the IANA has allocated
+   233/8. The remaining 24 bits will be administered in a manner similar
+   to that described in RFC 1797:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      233      |           16 bits AS          |  local bits   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1. Example
+
+   Consider, for example, AS 5662. Written in binary, left padded with
+   0s, we get 0001011000011110. Mapping the high order octet to the
+   second octet of the address, and the low order octet to the third
+   octet, we get 233.22.30/24.
+
+3. Allocation
+
+   As mentioned above, the allocation proposed here follows the RFC 1797
+   (case 1) allocation scheme, modified as follows: the high order octet
+   has the value 233, and the next 16 bits are a previously assigned
+   Autonomous System number (AS), as registered by a network registry
+   and listed in the RWhois database system. This allows a single /24
+   per AS.
+
+   As was the case with RFC 1797, using the AS number in this way allows
+   the experiment to get underway quickly in that it automatically
+   allocates some addresses to each service provider and does not
+   require a registration step.
+
+3.1. Private AS Space
+
+   The address space mapped to the private AS space [RFC1930] is
+   reserved for future allocation.
+
+
+
+
+
+Meyer & Lothberg              Experimental                      [Page 2]
+
+RFC 2770                GLOP Addressing in 233/8           February 2000
+
+
+4. Transition from GLOP to Other Address Allocation Schemes
+
+   It may not be necessary to transition from the address allocation
+   scheme described here to a more dynamic approach (see, e.g., [MASC]).
+   The reasoning here is that the statically assigned addresses taken
+   from 233/8 may be sufficient for those applications which must have
+   static addressing, and any other addressing can come from either a
+   dynamic mechanism such as [MASC], the administratively scoped address
+   space [RFC2365], or the Single-source address space [SS].
+
+5. Security Considerations
+
+   The approach described here may have the effect of reduced exposure
+   to denial of space attacks based on dynamic allocation. Further,
+   since dynamic assignment does not cross domain boundaries, well known
+   intra-domain security techniques can be applied.
+
+6. IANA Considerations
+
+   IANA has allocated 233/8 for experimental assignments. This
+   assignment should timeout one year after the assignment is made. The
+   assignment may be renewed at that time. It should be noted that the
+   experiment described here is in the same spirit the experiment
+   described in [RFC1797].
+
+7. Acknowledgments
+
+   This idea originated with Peter Lothberg's idea that we use the same
+   allocation (AS based) as described in RFC 1797 in the class D address
+   space. Randy Bush and Mark Handley contributed many insightful
+   comments.
+
+8. References
+
+   [RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address
+             Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
+             December 1999.
+
+   [MASC]    D. Estrin, et al., "The Multicast Address-Set Claim (MASC)
+             Protocol", Work in Progress.
+
+   [MSDP]    D. Farinacci et al., "Multicast Source Discovery Protocol
+             (MSDP)", Work in Progress.
+
+   [IANA]    www.isi.edu/in-notes/iana/assignments/multicast-addresses
+
+
+
+
+
+
+Meyer & Lothberg              Experimental                      [Page 3]
+
+RFC 2770                GLOP Addressing in 233/8           February 2000
+
+
+   [RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April 1995.
+
+   [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
+             selection, and registration of an Autonomous System (AS)",
+             RFC 1930, March 1996.
+
+   [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", RFC
+             2365, July 1998.
+
+   [RFC2374] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
+             Aggregatable Global Unicast Address Format", RFC 2374, July
+             1998.
+
+   [SAP]     Handley, M., "SAP: Session Announcement Protocol", Work in
+             Progress.
+
+   [SS]      www.isi.edu/in-notes/iana/assignments/single-source-
+             multicast
+
+9. Authors' Addresses
+
+   David Meyer
+   Cisco Systems, Inc.
+   170 W. Tasman Drive
+   San Jose, CA 95134-1706
+   United States
+
+   EMail: dmm@cisco.com
+
+
+   Peter Lothberg
+   Sprint
+   VARESA0104
+   12502 Sunrise Valley Drive
+   Reston VA, 20196
+
+   EMail: roll@sprint.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meyer & Lothberg              Experimental                      [Page 4]
+
+RFC 2770                GLOP Addressing in 233/8           February 2000
+
+
+10. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meyer & Lothberg              Experimental                      [Page 5]
+