GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2770

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2770.txt · Last modified: 2000/02/18 18:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki