1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc3180.txt b/doc/rfc/rfc3180.txt
new file mode 100644
index 0000000..5202086
--- /dev/null
+++ b/doc/rfc/rfc3180.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                           D. Meyer
+Request for Comments: 3180                                   P. Lothberg
+Obsoletes: 2770                                                   Sprint
+BCP: 53                                                   September 2001
+Category: Best Current Practice
+
+
+                        GLOP Addressing in 233/8
+
+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 (2001).  All Rights Reserved.
+
+Abstract
+
+   This document defines the policy for the use of 233/8 for statically
+   assigned multicast addresses.
+
+1. Introduction
+
+   It is envisioned that the primary use of this space will be many-to-
+   many applications.  This allocation is in addition to those described
+   on [IANA] (e.g., [RFC2365]).  The IANA has allocated 223/8 as per RFC
+   2770 [RFC2770].  This document obsoletes RFC 2770.
+
+2. Problem Statement
+
+   Multicast addresses have traditionally been allocated by a dynamic
+   mechanism such as SDR [RFC2974].  However, many current multicast
+   deployment models are not amenable to dynamic allocation.  For
+   example, many content aggregators require group addresses that are
+   fixed on a time scale that is not amenable to allocation by a
+   mechanism such as described in [RFC2974].  Perhaps more seriously,
+   since there is not 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         Best Current Practice                  [Page 1]
+
+RFC 3180                GLOP Addressing in 233/8          September 2001
+
+
+   The MALLOC working group has created a specific strategy for global
+   multicast address allocation [RFC2730, RFC2909].  However, this
+   approach has not been widely implemented or deployed.  This document
+   proposes a solution for a subset of the problem, namely, those cases
+   not covered by Source Specific Multicast.
+
+3. Address Space
+
+   The IANA has allocated 223/8 as per RFC 2770 [RFC2770].  RFC 2770
+   describes the administration of the middle two octets of 233/8 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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.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.
+
+4. 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
+   automatic assignment of a single /24 to each service provider and
+   does not require an additional registration step.
+
+4.1. Private AS Space
+
+   The part of 233/8 that is mapped to the private AS space [RFC1930] is
+   assigned to the IRRs [RFC3138].
+
+5. Large AS Numbers
+
+   It is important to note that this approach will work only for two
+   octet AS numbers.  In particular, it does not work for any AS number
+   extension scheme.
+
+
+
+
+Meyer & Lothberg         Best Current Practice                  [Page 2]
+
+RFC 3180                GLOP Addressing in 233/8          September 2001
+
+
+6. Security Considerations
+
+   The approach described here may have the effect of reduced exposure
+   to denial-of-service attacks based on dynamic allocation.  Further,
+   since dynamic assignment does not cross domain boundaries, well-known
+   intra-domain security techniques can be applied.
+
+7. IANA Considerations
+
+   The IANA has assigned 233/8 for this purpose.
+
+8. Acknowledgments
+
+   This proposal originated with Peter Lothberg's idea that we use the
+   same allocation (AS based) as described in RFC 1797.  Randy Bush and
+   Mark Handley contributed many insightful comments, and Pete and
+   Natalie Whiting contributed greatly to the readability of this
+   document.
+
+9. References
+
+   [IANA]    http://www.iana.org/numbers.html
+
+   [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.
+
+   [RFC2730] Hanna, S.,  Patel, B. and M. Shah, "Multicast Address
+             Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
+             December 1999.
+
+   [RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC
+             2770, February 2000.
+
+   [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
+             Kumar, S. and D. Thaler, "The Multicast Address-Set Claim
+             (MASC) Protocol", RFC 2909, September 2000.
+
+
+
+
+
+Meyer & Lothberg         Best Current Practice                  [Page 3]
+
+RFC 3180                GLOP Addressing in 233/8          September 2001
+
+
+   [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session
+             Announcement Protocol", RFC 2974, October 2000.
+
+   [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June
+             2001.
+
+10. Authors' Addresses
+
+   David Meyer
+   Sprint
+   VARESA0104
+   12502 Sunrise Valley Drive
+   Reston VA, 20196
+
+   EMail: dmm@sprint.net
+
+
+   Peter Lothberg
+   Sprint
+   VARESA0104
+   12502 Sunrise Valley Drive
+   Reston VA, 20196
+
+   EMail: roll@sprint.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meyer & Lothberg         Best Current Practice                  [Page 4]
+
+RFC 3180                GLOP Addressing in 233/8          September 2001
+
+
+11. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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         Best Current Practice                  [Page 5]
+