Draft: IPv4 Sub-allocations Made by Local Internet Registries
Operating within the RIPE NCC Service Region
Gert Döring
Leo Vegoda
Date: January 2003
Document-ID: ripe-t.b.a.
Table of Contents
Introduction
This document specifies the RIPE community’s policies on allocations
made by Local Internet Registries (LIRs) within the unicast IPv4 address
space. The RIPE community’s IPv6 policies are documented in the
“IPv6 Address Allocation and Assignment Policy”, found at:
http://www.ripe.net/ripe/docs/ipv6policy.html
The introduction of Classless Inter Domain Routing (CIDR) allowed routing
information to be aggregated so that the routes of a downstream network
operator could be summarised by an upstream operator. The RIPE community
has strongly supported the introduction of CIDR as it reduces the total
number of routes within the default free zone of the BGP4 routing tables.
Previously, LIRs were only permitted to register a single layer of assignments
(inetnum objects with a status attribute value of “ASSIGNED
PA” or “ASSIGNED PI”). This document describes a new
policy, agreed by the RIPE community at RIPE 43 in Rhodes, September 2002,
to allow LIRs to make sub-allocations to downstream organisations.
In the same way that Internet address space is allocated in a hierarchy,
some LIRs have internal addressing hierarchies. Often, these LIRs will
have resellers with their own end customers. Consequently, these LIRs
need to allocate or reserve parts of their allocation for these resellers.
However, LIRs have not been able to allocate address space to resellers
as the policy formally forbade it. The RIPE NCC was not able to consider
these networks as used; they were classified as unofficial reservations
and could not be documented in the Database. This could result in problems
for LIRs needing a new allocation but whose resellers have not assigned
all of the address space routed to them.
1.0 Policy framework
This policy applies to LIRs who have an Assignment Window (AW). The AW
policy is described in “IPv4 Address Allocation and Assignment Policies
in the RIPE NCC Service Region” found at:
http://www.ripe.net/ripe/docs/ipv4-policies.html
1.1 Policy intended to aid aggregation
This policy is intended to aid the goal of routing aggregation and does
not apply to allocations with a status other than “ALLOCATED PA”.
LIRs holding “ALLOCATED PI” or “ALLOCATED UNSPECIFIED”
allocations may be able to convert them to “ALLOCATED PA”
if there are no PI assignments within them.
If the LIR wants to convert their allocation, they should contact the
RIPE NCC via e-mail at:
<lir-help@ripe.net>.
1.2 Minimum size of sub-allocations
The minimum size of a sub-allocation is /24. This is the smallest prefix
length that can be reverse delegated and allows for a reasonable number
of small assignments to be made by a downstream network operator.
1.3 Rules for making sub-allocations
An LIR may sub-allocate a network up to 400% of its Assignment Window
to a single organisation each year. Thus, an LIR with an AW of /26 may
make a /24 sub-allocation.
LIRs with an AW smaller than /26 may not make sub-allocations as the
minimum sub-allocation size is /24.
LIRs may make sub-allocations to multiple downstream network operators.
Downstream network operators efficiently using a /22 sub-allocation will
qualify to receive a /20 PA allocation from the RIPE NCC if they decide
to become an LIR themselves. Information about joining the RIPE NCC is
available in the RIPE document “Procedure for Becoming a Member
of the RIPE NCC” available at:
http://www.ripe.net/ripe/docs/new-lir.html
1.4 Maximum size of sub-allocations
The maximum size of sub-allocations is /20 even if this is less than
400% of the LIR’s AW. For instance, an LIR with a /21 AW may not
sub-allocate a /19 to a downstream network. However, downstream network
operators may receive sub-allocations totalling more than a /20 from one
or more LIRs.
1.5 Responsibilities of the LIR
The LIR is contractually responsible for ensuring the address space allocated
to it is used in accordance with the RIPE community’s policies.
It is recommended that LIRs have contracts requiring downstream network
operators to follow the RIPE community’s policies when those operators
have sub-allocations.
1.6 Sub-allocation
considered usage (additional allocations)
The RIPE NCC considers sub-allocated space as used when evaluating requests
from the LIR for an additional IPv4 allocation. LIRs are still required
to demonstrate about 80% usage for all their allocations. Where an LIR
has made many sub-allocations with little assigned within them, the RIPE
NCC will ask the LIR to justify the reasons for the sub-allocations.
1.7 Reverse delegation
Address space reverse delegation is a RIPE NCC membership service. Only
LIRs may request reverse delegation. In order to receive reverse delegation
of address space there must be a valid assignment within the /24 being
requested. Additional information on reverse delegation is available at:
http://www.ripe.net/ripe/docs/rev-del.html
2.0 Recommendations for LIRs
2.1 Allocation different from assignment
Evaluating a request for an allocation is different from evaluating a
request for an assignment. With assignments, the evaluator can see the
network plans for a single organisation. With allocations, the evaluator
is often presented with sales and marketing plans and the addressing requirements
of individual organizations cannot be examined.
The RIPE community has a “slow-start” mechanism for allocating
address space to LIRs. LIRs start with a small allocation and a larger
allocation is only made after the RIPE NCC has been able to see the LIR’s
usage rate. More information can be found at:
http://www.ripe.net/ripe/docs/ipv4-policies.html
It is recommended that LIRs make use of a slow-start mechanism when making
a sub-allocation for a downstream network operator.
There are two main advantages to this:
- the LIR can ensure that the address space it sub-allocates is likely
to be used efficiently;
- the LIR can determine the ability of the downstream organisation
to operate within the policies set by the RIPE community.
2.2 Contractual status of sub-allocations
Sub-allocations form part of an LIR’s aggregatable address space.
As such, an LIR may want to ensure that a reseller does not retain the
address space if the reseller ceases to receive connectivity from the
LIR’s network. LIRs not wishing to lose address space in this way
should ensure that the status of the sub-allocation is clear in any contracts
between the LIR and the reseller.
3.0 Database registration
3.1 Status attribute for inetnums representing
sub-allocations
Registration of a sub-allocation in the RIPE Database requires the creation
of an inetnum object with an appropriate status value.
3.2 Restriction on creation of inetnums with
an “ASSIGNED” status
The creation of an inetnum object with a status of “ASSIGNED
PA” or “ASSIGNED PI” will not be allowed if there is
either a less specific or more specific inetnum object
with an “ASSIGNED” status. The assigned status inetnum
is the most specific registration allowed.
3.3 Use of Routing Policy System Security (RPSS)
in the RIPE Database
The RIPE Database implements RPSS as described in RFC 2725 (ftp://ftp.ripe.net/rfc/rfc2725.txt).
The RPSS “reclaim:” and “no-reclaim:” attributes
are not available at the time of writing. The issue of how best to implement
the RPSS “reclaim” and “no-reclaim” functionality
will be discussed within the RIPE Database Working Group.
4.0 Training considerations
LIRs are welcome to use the training material published by the RIPE NCC.
All course material is available for download from the RIPE NCC web site
at:
http://www.ripe.net/training/
|
you are here: RIPE -> RIPE Draft Documents
