doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3171.txt b/doc/rfc/rfc3171.txt
new file mode 100644
index 0000000..515d2c9
--- /dev/null
+++ b/doc/rfc/rfc3171.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         Z. Albanna
+Request for Comments: 3171                              Juniper Networks
+BCP: 51                                                      K. Almeroth
+Category: Best Current Practice                                     UCSB
+                                                                D. Meyer
+                                                                  Sprint
+                                                             M. Schipper
+                                                                    IANA
+                                                             August 2001
+
+
+         IANA Guidelines for IPv4 Multicast Address Assignments
+
+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 memo provides guidance for the Internet Assigned Numbers
+   Authority (IANA) in assigning IPv4 multicast addresses.
+
+1. Introduction
+
+   The Internet Assigned Numbers Authority (IANA) (www.iana.org) is
+   charged with allocating parameter values for fields in protocols
+   which have been designed, created or are maintained by the Internet
+   Engineering Task Force (IETF).  RFC 2780 [RFC2780] provides the IANA
+   guidance in the assignment of parameters for fields in newly
+   developed protocols.  This memo expands on section 4.4.2 of RFC 2780
+   and attempts to codify existing IANA practice used in the assignment
+   IPv4 multicast addresses.
+
+   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].
+
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 1]
+
+RFC 3171             IANA IPv4 Multicast Guidelines          August 2001
+
+
+   In general, due to the relatively small size of the IPv4 multicast
+   addresses space, further assignment of IPv4 multicast address space
+   is recommended only in limited circumstances.  Specifically, the IANA
+   should only assign addresses in those cases where the dynamic
+   selection (SDP/SAP), GLOP, SSM or Administratively Scoped address
+   spaces cannot be used.  The guidelines described below are reflected
+   in http://www.iana.org/numbers.html.
+
+2. Definition of Current Assignment Practice
+
+   Unlike IPv4 unicast address assignment, where blocks of addresses are
+   delegated to regional registries, IPv4 multicast addresses are
+   assigned directly by the IANA.  Current assignments appear as follows
+   [IANA]:
+
+   224.0.0.0   - 224.0.0.255     (224.0.0/24)  Local Network Control Block
+   224.0.1.0   - 224.0.1.255     (224.0.1/24)  Internetwork Control Block
+   224.0.2.0   - 224.0.255.0                   AD-HOC Block
+   224.1.0.0   - 224.1.255.255   (224.1/16)    ST Multicast Groups
+   224.2.0.0   - 224.2.255.255   (224.2/16)    SDP/SAP Block
+   224.252.0.0 - 224.255.255.255               DIS Transient Block
+   225.0.0.0   - 231.255.255.255               RESERVED
+   232.0.0.0   - 232.255.255.255 (232/8)       Source Specific Multicast
+                                               Block
+   233.0.0.0   - 233.255.255.255 (233/8)       GLOP Block
+   234.0.0.0   - 238.255.255.255               RESERVED
+   239.0.0.0   - 239.255.255.255 (239/8)       Administratively Scoped
+                                               Block
+
+   The IANA generally assigns addresses from the Local Network Control,
+   Internetwork Control, and AD-HOC blocks.  Assignment guidelines for
+   each of these blocks, as well as for the Source Specific Multicast,
+   GLOP and Administratively Scoped Blocks, are described below.
+
+3. Local Network Control Block (224.0.0/24)
+
+   Addresses in the Local Network Control block are used for protocol
+   control traffic that is not forwarded off link.  Examples of this
+   type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].
+
+3.1. Assignment Guidelines
+
+   Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
+   Local Network Control block follow an Expert Review, IESG Approval or
+   Standards Action process.  See [IANA] for the current set of
+   assignments.
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 2]
+
+RFC 3171             IANA IPv4 Multicast Guidelines          August 2001
+
+
+4. Internetwork Control Block (224.0.1/24)
+
+   Addresses in the Internetwork Control block are used for protocol
+   control that must be forwarded through the Internet.  Examples
+   include 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover
+   [RFC2730]).
+
+4.1. Assignment Guidelines
+
+   Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
+   Internetwork Control block follow an Expert Review, IESG Approval or
+   Standards Action process.  See [IANA] for the current set of
+   assignments.
+
+5. AD-HOC Block (224.0.2.0/24 - 224.0.255.0/24)
+
+   Addresses in the AD-HOC block have traditionally been assigned for
+   those applications that don't fit in either the Local or Internetwork
+   Control blocks.  These addresses are globally routed and are
+   typically used by applications that require small blocks of
+   addressing (e.g., less than a /24).
+
+5.1. Assignment Guidelines
+
+   In general, the IANA SHOULD NOT assign addressing in the AD-HOC
+   Block.  However, the IANA may under special special circumstances,
+   assign addressing from this block.  Pursuant to section 4.4.2 of RFC
+   2780 [RFC2780], assignments from the AD-HOC block follow an Expert
+   Review, IESG Approval or Standards Action process.  See [IANA] for
+   the current set of assignments.
+
+6. SDP/SAP Block (224.2/16)
+
+   Addresses in the SDP/SAP block are used by applications that receive
+   addresses through the Session Announcement Protocol [RFC2974] for use
+   via applications like the session directory tool (such as SDR [SDR]).
+
+6.1. Assignment Guidelines
+
+   Since addresses in the SDP/SAP block are chosen randomly from the
+   range of addresses not already in use [RFC2974], no IANA assignment
+   policy is required.  Note that while no additional IANA assignment is
+   required, addresses in the SDP/SAP block are explicitly for use by
+   SDP/SAP and MUST NOT be used for other purposes.
+
+
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 3]
+
+RFC 3171             IANA IPv4 Multicast Guidelines          August 2001
+
+
+7. Source Specific Multicast Block (232/8)
+
+   The Source Specific Multicast (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.
+   Note that this block as initially assigned to the VMTP transient
+   groups [IANA].
+
+7.1. Assignment Guidelines
+
+   Because the SSM model essentially makes the entire multicast address
+   space local to the host, no IANA assignment policy is required.
+   Note, however, that while no additional IANA assignment is required,
+   addresses in the SSM block are explicitly for use by SSM and MUST NOT
+   be used for other purposes.
+
+8. GLOP Block (233/8)
+
+   Addresses in the GLOP block are globally scoped statically assigned
+   addresses.  The assignment is made by mapping a domain's autonomous
+   system number into the middle two octets of 233.X.Y.0/24.  The
+   mapping and assignment is defined in [RFC2770].
+
+8.1. Assignment Guidelines
+
+   Because addresses in the GLOP block are algorithmically pre-assigned,
+   no IANA assignment policy is required.  In addition, RFC 3138
+   [RFC3138] delegates assignment of the GLOP sub-block mapped by the
+   RFC 1930 [RFC1930] private AS space (233.252.0.0 - 233.255.255.255)
+   to the Internet Routing Registries.  Note that while no additional
+   IANA assignment is required, addresses in the GLOP  block are
+   assigned for use as defined in RFC 2770 and MUST NOT be used for
+   other purposes.
+
+9. Administratively Scoped Address Block (239/8)
+
+   Addresses in the Administratively Scoped Address block are for local
+   use within a domain and are described in [RFC2365].
+
+9.1. Assignment Guidelines
+
+   Since addresses in this block are local to a domain, no IANA
+   assignment policy is required.
+
+
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 4]
+
+RFC 3171             IANA IPv4 Multicast Guidelines          August 2001
+
+
+9.1.1. Relative Offsets
+
+   The relative offsets [RFC2365] are used to ensure that a service can
+   be located independent of the extent of the enclosing scope (see RFC
+   2770 for details).  Since there are only 256 such offsets, the IANA
+   should only assign a relative offset to a protocol that provides an
+   infrastructure supporting service.  Examples of such services include
+   the Session Announcement Protocol [RFC2974].  Pursuant to section
+   4.4.2 of RFC 2780 [RFC2780], assignments of Relative Offsets follow
+   an Expert Review, IESG Approval or Standards Action process.  See
+   [IANA] for the current set of assignments.
+
+10. Annual Review
+
+   Given the dynamic nature of IPv4 multicast and its associated infra-
+   structure, and the previously undocumented IPv4 multicast address
+   assignment guidelines, the IANA should conduct an annual review of
+   currently assigned addresses.
+
+10.1. Address Reclamation
+
+   During the review described above, addresses that were mis-assigned
+   should, where possible, be reclaimed or reassigned.
+
+   The IANA should also review assignments in the AD-HOC, DIS Transient
+   Groups, and ST Multicast Groups blocks and reclaim those addresses
+   that are not in use on the global Internet (i.e, those applications
+   which can use SSM, GLOP, or Administratively Scoped addressing, or
+   are not globally routed).
+
+11. Use of IANA Reserved Addresses
+
+   Applications MUST NOT use addressing in the IANA reserved blocks.
+
+12. Security Considerations
+
+   The assignment guidelines described in this document do not alter the
+   security properties of either the Any Source or Source Specific
+   multicast service models.
+
+13. Acknowledgments
+
+   The authors would like to thank Joe St. Sauver, John Meylor, Randy
+   Bush, and Thomas Narten for their constructive feedback and comments.
+
+
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 5]
+
+RFC 3171             IANA IPv4 Multicast Guidelines          August 2001
+
+
+14. Authors' Addresses
+
+   Zaid Albanna
+   1149 N. Mathilda Ave
+   Sunnyvale, CA. 94089
+
+   EMail: zaid@juniper.net
+
+
+   Kevin Almeroth
+   UC Santa Barbara
+   Santa Barbara, CA.
+
+   EMail: almeroth@cs.ucsb.edu
+
+
+   David Meyer
+   Sprint E|Solutions
+
+   EMail: dmm@sprint.net
+
+
+   Michelle Schipper
+   IANA Administrator
+   Internet Assigned Numbers Authority
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA 90292
+
+   EMail: iana@iana.org
+
+15. References
+
+   [IANA]    http://www.iana.org/numbers.html
+
+   [RFC1190] Topolcic, C., "Experimental Internet Stream Protocol,
+             Version 2 (ST-II)", RFC 1190, October 1990.
+
+   [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.
+
+   [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+             for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 6]
+
+RFC 3171             IANA IPv4 Multicast Guidelines          August 2001
+
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
+             RFC 2365, July 1998.
+
+   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 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.
+
+   [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+             Values In the Internet Protocol and Related Headers", BCP
+             37, RFC 2780, March 2000.
+
+   [RFC2908] Thaler, D., Handley, M. and D.Estrin, "The Internet
+             Multicast Address Allocation Architecture", RFC 2908,
+             September 2000.
+
+   [RFC2909] Thaler, D., Handley, M. and D. Estrin, "The Multicast
+             Address-Set Claim (MASC) Protocol", RFC 2909, September
+             2000.
+
+   [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.
+
+   [SDR]     http://www-mice.cs.ucl.ac.uk/multimedia/software/
+
+
+
+
+
+
+
+
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 7]
+
+RFC 3171             IANA IPv4 Multicast Guidelines          August 2001
+
+
+16. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Albanna, et al.          Best Current Practice                  [Page 8]
+