1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc3138.txt b/doc/rfc/rfc3138.txt
new file mode 100644
index 0000000..ec542db
--- /dev/null
+++ b/doc/rfc/rfc3138.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                           D. Meyer
+Request for Comments: 3138                                        Sprint
+Category: Informational                                        June 2001
+
+
+                     Extended Assignments in 233/8
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This memo provides describes the mapping of the GLOP addresses
+   corresponding to the private AS space.
+
+1. Introduction
+
+   RFC 2770 [RFC2770] describes an experimental policy for use of the
+   class D address space using 233/8.  The technique described there
+   maps 16 bits of Autonomous System number (AS) into the middle two
+   octets of 233/8 to yield a /24.  While this technique has been
+   successful, the assignments are inefficient in those cases in which a
+   /24 is too small or the user doesn't have its own AS.
+
+   RFC 1930 [RFC1930] defines the private AS space to be 64512 through
+   65535.  This memo expands on RFC 2770 to allow routing registries to
+   assign multicast addresses from the GLOP space corresponding to the
+   RFC 1930 private AS space.  This space will be referred to as the
+   EGLOP (Extended GLOP) address space.
+
+   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.
+
+   The terms "Specification Required", "Expert Review", "IESG Approval",
+   "IETF Consensus", and "Standards Action", are used in this memo to
+   refer to the processes described in [RFC2434].  The keywords MUST,
+   MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT,
+   SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119
+   [RFC2119].
+
+
+
+Meyer                        Informational                      [Page 1]
+
+RFC 3138             Extended Assignments in 233/8             June 2001
+
+
+2. Overview
+
+   http://www.iana.org/assignments/multicast-addresses defines a
+   mechanism for assignment of multicast addresses that are generally
+   for use in network control applications.  It is envisioned that those
+   addresses assigned from the EGLOP space (233.252.0.0 -
+   233.255.255.255) will be used by applications that cannot use
+   Administratively Scoped Addressing [RFC2365], GLOP Addressing
+   [RFC2770], or Source Specific Multicast (Source Specific Multicast,
+   or SSM, is an extension of IP Multicast in which traffic is forwarded
+   to receivers from only those multicast sources for which the
+   receivers have explicitly expressed interest, and is primarily
+   targeted at one-to-many (broadcast) applications).
+
+3. Assignment Criteria
+
+   Globally scoped IPv4 multicast addresses in the EGLOP space are
+   assigned by a Regional Registry (RIR).  An applicant MUST, as per
+   [IANA], show that the request cannot be satisfied using
+   Administratively Scoped addressing [RFC2365], GLOP addressing
+   [RFC2770], or SSM.  The fine-grained assignment policy is left to the
+   assigning RIR.
+
+4. Security Considerations
+
+   The assignment scheme described in this document does not effect the
+   security properties of the the single source or any source multicast
+   service models.
+
+5. Acknowledgments
+
+   Kurt Kayser, Mirjam Kuehne, Michelle Schipper and Randy Bush provided
+   many insightful comments on earlier versions of this document.
+
+6. Author's Address
+
+   David Meyer
+   Sprint
+   12502 Sunrise Valley Dr
+   Reston VA,  20191
+
+   EMail: dmm@sprint.net
+
+
+
+
+
+
+
+
+
+Meyer                        Informational                      [Page 2]
+
+RFC 3138             Extended Assignments in 233/8             June 2001
+
+
+7. References
+
+   [IANA]          http://www.iana.org/assignments/multicast-addresses
+
+   [RFC1930]       Hawkinson J. and T. Bates, "Guidelines for
+                   creation, selection, and registration of an
+                   Autonomous System (AS)", RFC 1930, March 1996.
+
+   [RFC2026]       Bradner, S., "The Internet Standards Process --
+                   Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to
+                   Indicate Requirement Levels", BCP 14, RFC 2119,
+                   March 1997.
+
+   [RFC2365]       Meyer, D., "Administratively Scoped IP Multicast",
+                   RFC 2365, July 1998.
+
+   [RFC2770]       Meyer, D. and P. Lothberg, "GLOP Addressing in
+                   233/8", RFC 2770, February 2000.
+
+   [RFC2780]       Bradner, S. and V. Paxson, "IANA Allocation
+                   Guidelines For Values In the Internet Protocol
+                   and Related Headers", BCP 37, RFC 2780, March
+                   2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meyer                        Informational                      [Page 3]
+
+RFC 3138             Extended Assignments in 233/8             June 2001
+
+
+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                        Informational                      [Page 4]
+