Is ripe allocating /24's?

Daniel Karrenberg Daniel.Karrenberg at ripe.net
Tue Oct 20 09:43:56 UTC 1998


  > Edvard Tuinder <ed at cistron.net> writes:
  > I think he is misreading the allocation database. The minimum allocation
  > size used to be /19 and will become (or is) /20 to facilitate smaller
  > providers. A /24 will not be allocated.

This is not correct. There are currently no plans to reduce the minimum
allocation size from the current /19.  To be precise about allocation 
vs assignment I quote from ripe-159 below. See this document at
http://www.ripe.net/docs/ripe-159.html
for details.

Daniel

2.3.  The Internet Registry System

                The Internet Registry system has been established to
                achieve the goals stated in Section 2.2.  It con-
                sists of hierarchically organized Internet Reg-
                istries (IRs).  Address space is typically assigned
                to end users by Local IRs. The address space
                assigned is taken from that allocated to the Local
                IR by the Regional IR.  End users are those organi-
                zations operating networks in which the address
                space is used. ...

                Local IRs are typically
                operated by Internet Service Providers (ISPs).
                Local IRs hold allocations of address space for
                assignment to end users.  Assigned address space is
                actually used to operate networks, whereas allocated
                address space is held by IRs for future assignments
                to end users.  To achieve both the conservation and
                aggregation goals, only IRs can hold allocations of
                address space.
 
                ...


4.1.  The Slow Start Mechanism

                To prevent allocating large blocks of address space
                that won't be assigned, the RIPE NCC has introduced
                the concept of a slow start for allocations.  The
                idea is to allocate address space to Local IRs at
                the rate it will be assigned. The minimum size of an
                individual address space allocation is /19 (8192
                addresses), and the maximum size is /16 (65536
                addresses).  The size of an allocation to a particu-
                lar Local IR is based solely on the rate that the IR
                has assigned previously allocated address space to
                end users.

                The slow start mechanism implements a consistent and
                fair policy for every Local IR with respect to allo-
                cations.  Although the mechanism is similar to the
                assignment window mechanism described in Section
                3.6, the policy it implements is different.  The
                size of further allocations depends exclusively on
                the assignment rate of the Local IR concerned while
                the assignment window depends on the proficiency of
                the registry staff in evaluating requests and pro-
                cessing assignments.


    4.2.  First Allocation

                When a new Local IR starts up, it has no address
                space allocated to it.  The first allocation will be
                made automatically by the RIPE NCC, generally upon
                receipt of the first assignment request from the
                Local IR. Because there is no information about the
                rate at which a new IR will make address assign-
                ments, the size of the first allocation is always a
                /19 (8092 addresses).

                Remember that the amount of space allocated does not
                determine the size of assignments a Local IR can
                make.  As discussed at the end of Section 3, a new
                Local IR must have every assignment approved by the
                RIPE NCC until its assignment window is increased.


    4.3.  Further Allocations

                A Local IR can obtain additional allocations as
                required. A request should be submitted to the RIPE
                NCC when the currently allocated address space is
                nearly used up (about 90 percent), or if a single
                assignment will require a larger set of addresses
                than can be satisfied with the allocated address
                space. To obtain a new allocation, a Local IR should
                submit a request to the RIPE NCC which includes a
                complete list of the assignments made from all of
                their allocations. The RIPE NCC will check this
                information, compare it with assignments registered
                in the database and may request further information
                (such as documentation of some of the assignments)
                to determine the need for a new allocation. Addi-
                tional address space will be allocated after the
                information supplied with the request has been veri-
                fied, and a new allocation has been deemed neces-
                sary.

                Unfortunately, there is a tradeoff between the
                aggregation and conservation goals in making alloca-
                tions. To further aggregation, the RIPE NCC aims to
                allocate contiguous address ranges to a Local IR.
                However, because conservation of address space must
                also be taken into account, this is not always pos-
                sible.  A new allocation to a registry can therefore
                not be expected to be contiguous with past alloca-
                tions. While the RIPE NCC always aims to further the
                aggregation goal, and therefore to allocate contigu-
                ous space, the RIPE policy is that under no circum-
                stances are multiple allocations made to the same
                Local IR guaranteed to be contiguous and aggregat-
                able with previous allocations.




More information about the NANOG mailing list