Movatterモバイル変換

Network Working Group                                         D. MeyerRequest for Comments: 2770                               Cisco SystemsCategory: Experimental                                     P. Lothberg                                                                Sprint                                                         February 2000GLOP Addressing in 233/8Status 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   insection 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 inRFC 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 theRFC 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 withRFC 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 20004. 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 inRFC 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-addressesMeyer & 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",RFC2365, 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-             multicast9. 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.netMeyer & Lothberg              Experimental                      [Page 4]

RFC 2770                GLOP Addressing in 233/8           February 200010. 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]