Subject: Use of 226/8 for static allocations

From: David Meyer <[email-masked]>
Date: Wed, 3 Mar 1999 17:51:18 -0800 (PST)

MBONED Working Group                               David Meyer
Internet Draft                                     Cisco Systems

Category                                           Experimental
draft-ietf-mboned-glop-bits-00.txt                 March, 1999

                             Glop Bit Usage

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

2. Abstract

   This describes an experimental policy for use of the class D address
   space using 226/8 as the experimental subset. This new experimental
   allocation is in addition to those described on [IANA] (e.g.
   [RFC2365]).

   This memo is a product of the MBONE Deployment Working Group (MBONED)
   in the Operations and Management Area of the Internet Engineering
   Task Force. Submit comments to <[email-masked]> or the
   authors.

David Meyer                                                     [Page 1]

Internet Draft     draft-ietf-mboned-glop-bits-00.txt     Feburary, 1999

3. Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

4. Problem Statement

   Multicast address 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 with out a coherent multicast address allocation scheme. While
   the MALLOC working group is looking at a specific strategy [MADCAP,
   MASC], it is proposed that a different strategy be developed in
   parallel.

5. Glop Bits

   For purposes of the experiment described here, the IANA should
   allocate 226/8. The remaining 24 bits (GLOP bits) will be
   administered as described here. A multicast address in 226/8 is
   structured as follows:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      226      |X|               GLOP Bits                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The GLOP Bits field is comprised of an assigned prefix and a local
   use field:

David Meyer                                                     [Page 2]

Internet Draft     draft-ietf-mboned-glop-bits-00.txt     Feburary, 1999

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      226      |X|  Variable Length Prefix + Local Use Field   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that the maximum length of an assigned prefix is 22. The Local
   Use field is intended for local administration though an unspecified
   mechanism (while such a mechanism is outside the scope of this draft,
   see e.g. [MADCAP]).Finally, the addresses the X bit set to zero are
   reserved for future use.

6. Allocation

   The glop bits are intended to be used in an experiment of static
   allocation to achieve aggregation in a manner similar to the TLA
   approach described in [RFC2374].

7. Security Considerations

   The approach described here may have the effect of reduced exposure
   to denial of space attacks as it greatly reduces the space that is
   dynamically assigned. Further, since dynamic assignment does not
   cross domain boundaries, well known intra-domain security techniques
   can be applied.

8. IANA Considerations

   IANA should allocate 226/8 for experimental assignments. This
   assigment should timeout one year after the assigment 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 [RFC1707].

David Meyer                                                     [Page 3]

Internet Draft     draft-ietf-mboned-glop-bits-00.txt     Feburary, 1999

9. 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 contributed many insightful comments.

10. References

    [MADCAP]  B. Patel, et. al., "Multicast Address Dynamic Client
              Allocation Protocol (MADCAP)",
              draft-ietf-malloc-madcap-04.txt, Feburay, 1999.

    [MASC]    D. Estrin, et. al., "The Multicast Address-Set Claim
             (MASC) Protocol", draft-ietf-malloc-masc-01.txt, August,
             1998.

    [IANA]    www.isi.edu/in-notes/iana/assignments/multicast-addresses

    [RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April,
              1995.

    [RFC2365] David Meyer, "Administratively Scoped IP Multicast",
              July, 1998.

    [RFC2374] R. Hinden, et. al., "An IPv6 Aggregatable Global Unicast
              Address Format", July, 1998.

    [SAP]     Handley, Mark, "SAP: Session Announcement Protocol",
              draft-ietf-mmusic-sap-00.txt, November, 1996.

11. Author's Address

   David Meyer
   Cisco Systems, Inc.
   170 W. Tasman Drive
   San Jose, CA 95134-1706
   United States
   EMail: [email-masked]

David Meyer                                                     [Page 4]

---

From: Mark Handley <[email-masked]>
Date: Wed, 03 Mar 1999 18:17:36 -0800

>                             Glop Bit Usage
...
>   allocation is in addition to those described on [IANA] (e.g.

...

>   experiment described here is in the same spirit the experiment

Apart from the facts that static allocation results in poor address
space utilization (witness unicast address allocation), there is an
issue with address space leakage.

It's quite likely that addresses will be statically allocated, and
then permanently fall into disuse (get forgotten about, get allocated
to companies that disappear, etc).  I would say that this proposal is
infeasible in the long run unless the static allocations themselves
have a lifetime, and time out if they're not renewed.

This is about the only way IANA would be able to terminate this
experiment after a year if it was considered a failure.  Also it's in
keeping with transitioning between truely dynamic allocation
(MASC-style) and "static" allocation as users require one or the
other for whatever reason.

Cheers,
	Mark