IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service
Region
Mirjam Kuehne
Nurani Nimpuno
Paul Rendek
Sabrina Wilmot
Document ID: 234
Date: 14 June 2002
Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159, ripe-185
_________________________________________________________________
Abstract
This document describes the current IPv4 address allocation
policies developed by the Local Internet Registry Working Group
(LIR WG) of the RIPE community and implemented by the RIPE
NCC. These policies apply to the RIPE NCC and the Local Internet
Registries (LIRs) in the RIPE NCC service region.
_________________________________________________________________
Table of Contents
1.0 Introduction
1.1 Scope
2.0 Internet Address Space
3.0 Goals of the Internet
4.0 Establishing a New LIR
5.0 IPv4 Address Assignment and Allocation Policies
5.1 General
5.1.1 Documentation
5.1.2 Registration Requirements
5.1.3 Utilisation
5.1.4 Reservations Not Supported
5.1.5 Administrative Ease
5.1.6 Provider Independent vs. Provider Aggregatable Address Space
5.1.7 Private Address Space
5.2 Assignment Guidelines
5.2.1 Validity of an Assignment
5.2.2 Dynamic Assignments
5.2.3 Web Hosting
5.2.4 Renumbering
5.2.5 Assignment Window
5.2.5.1 Assignment Window for LIR Infrastructure
5.2.5.2 Assignment Window for End User Assignments
5.3 Policies and Guidelines for Allocations
5.3.1 First Allocation
5.3.2 Slow-start Mechanism
5.3.3 Further Allocations
5.4 Operating an LIR
5.4.1 Record Keeping
5.4.2 LIR Contact Persons
5.4.3 Mergers, Takeovers, and Closures of LIRs
5.4.4 LIR Audit
5.4.5 Closure of an LIR by the RIPE NCC
5.4.6 Reverse Delegation
6.0 Appendices
I. RIPE Whois Database Procedures
II. Assignment Window
III. Useful URLs
IV. Bit Boundary Chart
1.0 Introduction
The RIPE Network Coordination Centre, established as an independent
association, serves as one of three Regional Internet Registries
(RIRs). Its service region incorporates Europe, the Middle East,
Central Asia and African countries located north of the equator. As
an RIR, the RIPE NCC is responsible for the assignment and
allocation of IP address space, Autonomous System (AS) Numbers and
the management of reverse domain names. The distribution of IP
address space follows the hierarchical scheme described in the
document "Internet Registry System" available from the RIPE
Document Store at:
http://www.ripe.net/ripe/docs/registry-system.html
The RIPE NCC allocates address space to LIRs who then assign
address space to End Users. In this document, the policies
associated with the distribution and management of IPv4 address
space are described. These policies must be implemented by all
LIRs.
The RIPE community, through the open-consensus process used for
policy development, has developed the policies described in this
document. In RIPE, it is the RIPE LIR Working Group (LIR-WG) where
Internet address policy is developed, discussed and set. This
process is facilitated and supported by the RIPE NCC.
1.1 Scope
This document describes the policies for the responsible management
of the globally unique IPv4 Internet address space in the RIPE NCC
service region. The policies set forth in this document apply to
all IPv4 address space allocated and assigned by the RIPE NCC.
This document does not describe address policies related to IPv6,
multicast, or private address space. This document does not
describe address distribution policies used by other RIRs. Policies
regarding AS Numbers are also out of scope for this document. The
document "Autonomous System (AS) Number Assignment Policies and
Procedures" available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/asn-assignments.html
2.0 Internet Address Space
IP addresses, for the purposes of this document, are 32-bit binary
numbers used as addresses in the IPv4 protocol. There are three
main types of IPv4 addresses:
Public Addresses
Public IP addresses are assigned to be globally unique according to
the goals described in Section 3 of this document.
Private Addresses
Some address ranges have been set aside for the operation of
private networks using IP. Anyone can use these addresses in their
private networks without any registration or co-ordination. Hosts
using these addresses cannot be reached directly from the
Internet. For a detailed description of private address space and
the ranges set aside for this purpose, please refer to RFC 1918
(Address Allocation for Private Internets) at:
ftp://ftp.ripe.net/rfc/rfc1918.txt
Special and Reserved Addresses
There are a number of address ranges reserved for applications such
as multicast. These are described in RFC 1112 (Host Extensions for
IP Multicasting) and are beyond the scope of this document. RFC
1112 can be found at:
http://www.ietf.org/rfc/rfc1112.txt?number=1112
3.0 Goals of the Internet
In this document, we are primarily concerned with the management of
public Internet address space as applied to IPv4. It should be
understood that the focus or importance of these goals might differ
for other IP versions, such as IPv6.
Public Internet address space assignments should be made with the
following goals in mind:
Uniqueness
Each public Internet address worldwide must be unique. This is an
absolute requirement that guarantees that every host on the
Internet can be uniquely identified.
Aggregation
Public Internet addresses must be distributed in an hierarchical
manner, permitting the aggregation of routing information. This is
necessary to ensure proper operation of Internet routing. This goal
could also be called Routability.
Conservation
Public Internet address space must be fairly distributed, according to
the operational needs of the End Users' operating networks using
this address space. To maximise the lifetime of the public Internet
address space resource, addresses must be distributed according to
need, and stockpiling must be prevented.
Registration
The provision of a public registry documenting address space
allocations and assignments must exist. This is necessary to ensure
uniqueness and to provide information for Internet troubleshooting
at all levels.
It is in the interest of the Internet community as a whole that
these goals are pursued. It is worth noting that "conservation" and
"aggregation" are often conflicting goals. Therefore each
assignment must be evaluated carefully. Moreover, the above goals
may occasionally be in conflict with the interests of individual
End Users or service providers. Careful analysis and judgement are
necessary in each individual case to find an appropriate
compromise. The rules and guidelines in this document are intended
to help LIRs and End Users in their search for equitable
compromises.
4.0 Establishing a New LIR
The process of setting up a new LIR is explained in detail in the
RIPE document, "Guidelines for Setting up a Local Internet Registry
at the RIPE NCC" available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/new-lir.html
5.0 IPv4 Address Assignment and Allocation Policies
5.1 General
The policies in the RIPE NCC service region document are applicable
to all globally unique, unicast IPv4 addresses. Specific policies
and guidelines for Provider Aggregatable (PA) and Provider
Independent (PI) address space are covered later in this section.
5.1.1 Documentation
Relevant information must be gathered about the network in question
in order to determine the amount of addresses required for that
network. This information may include organisation details,
addressing requirements, network infrastructure, current address
space usage, and future plans of the End User requesting address
space. This information is essential in making the appropriate
assignment decisions, balancing the overall goals of the Internet
Registry system (Section 3.0) with the requirements of the network
in question, and is needed for every network (the level of detail
is dependent on the complexity of the network). The LIR must ensure
that the necessary information is complete before proceeding with a
request.
The RIPE NCC provides a set of forms to be completed for gathering
the required information as well as supporting notes for the
forms. The set of information requested in the forms provided by
the RIPE NCC should be collected by the LIR. LIRs may use these
forms for their customers' requests or develop their own local set
of forms. Please note that local forms produced by the LIR can be
used provided they record all the required data.
However, if a request needs to be approved by the RIPE NCC or if
information is required in the event of an audit, the information
must be submitted on a current version of the IPv4 Address Space
Request Form available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/iprequestform.html
For complete instructions on how to fill out the IPv4 Address Space
Request Form, please refer to:
http://www.ripe.net/ripe/docs/iprequestsupport.html
Please note that all information sent to the RIPE NCC must be
submitted in English.
5.1.2 Registration Requirements
Each assignment and allocation for public Internet address space
must be registered in a publicly accessible Whois
Database. Allocations and assignments in the RIPE NCC service
region are registered in the RIPE Whois Database. This is necessary
to ensure uniqueness and to support network operations.
Only allocations and assignments registered in the RIPE Database
are considered valid. The required registration of objects in the
RIPE Database is the final step in making an assignment. This step
validates the assignment and makes information regarding the
assignment publicly available and archived. Therefore, care should
be taken to ensure that the data registered is correct
(e.g. correct IP address range, contact information, etc.).
IP addresses used solely for the connection of an End User to an
LIR can be considered as part of the service provider's
infrastructure. This means that these addresses do not have to be
registered with the End User's contact details but can be
registered as part of the service provider's internal
infrastructure, i.e. point-to-point links. However, four or more
addresses (e.g. /30 or more) used on the End User's network need to
be registered separately with the contact details of the End User.
For further instructions on how to register objects in the
Database, please refer to Section I (RIPE Whois Database
Procedures) of the Appendix.
5.1.3 Utilisation
Immediate utilisation should be at least 25% of the assigned
address space and the utilisation rate after one year should be at
least 50% of the address assignment unless special circumstances
are defined. Assignments must be based solely on realistic
expectations as specified in the addressing plan and the current
address space usage. End Users are not permitted to reserve
addresses based on long-term plans as this fragments the address
space. LIRs cannot make long-term reservations for End Users or
their infrastructure as this violates the goal of conservation and
also fragments the address space in case the initial forecasts are
not met.
5.1.4 Reservations Not Supported
In accordance with the goal of address conservation, End Users are
not permitted to reserve address space. Evaluation of IP address
space requests must be based on a demonstrated need. If possible,
unused or inefficiently used address space assigned in the past
should be used to meet the current request. Once an organisation
has used its assigned address space, it can request additional
address space based on an updated estimate of growth in its
network.
5.1.5 Administrative Ease
The current rate of consumption of the remaining unassigned IPv4
address space does not permit the assignment of addresses for
administrative ease. Examples of this include, but are not limited
to, ease of billing administration and network management.
5.1.6 Provider Independent vs. Provider Aggregatable Address Space
Provider Aggregatable Address Space (PA)
LIRs are allocated Provider Aggregatable address space that they
assign to their End Users and announced as one prefix. If an End
User changes its service provider, the PA address space assigned by
the previous service provider will have to be returned and the
network renumbered.
Provider Independent Address Space (PI)
In contrast to PA address space, PI address space is not aggregatable
but can remain assigned to the network as long as the criteria for
the original assignment are met. However, PI addresses are
expensive to route as no use can be made of aggregation and
therefore they might not be globally routable.
Please note that the use of PA address space should always be
recommended.
LIRs must make it clear to the End User which type of address space
is assigned. Clear contractual arrangements that specify the
validity and duration of the address assignment are strongly
recommended for every address assignment.
For further information and more detailed recommendations
concerning PI and PA addresses, please refer to the RIPE document:
"Provider Independent versus Provider Aggregatable Address Space"
available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/pi-pa.html
5.1.7 Private Address Space
Using private addresses helps to meet the conservation goal and
provides more flexibility for the End User when addressing the
network. For this reason End Users should always be informed that
private addresses might be a viable option. For a detailed
description of private address space and the actual ranges of
addresses set aside for that purpose, please refer to RFC 1918
("Address Allocation for Private Internets") at:
http://www.ietf.org/rfc/rfc1918.txt?number=1918
5.2 Assignment Guidelines
LIRs assign IP address space from the range of addresses allocated
to them by the RIPE NCC.
As conservation and aggregation are often conflicting goals, each
address request needs to be evaluated carefully in order to assign
the amount of address space fulfilling these goals in the best way
possible. Implications for both conservation and aggregation have
to be evaluated before an assignment is made. For example, if the
assignment of the exact number of addresses required creates a
large number of prefixes, it might be better to assign one single
prefix. In other cases, multiple prefixes might have to be
"announced" if the assignment of one single prefix would leave too
many addresses unused.
Please note that the RIPE NCC must approve requests that are larger
than the LIR's Assignment Window (Section 5.2.5). LIRs are always
welcome to request advice from the RIPE NCC in making assignment
decisions.
5.2.1 Validity of an Assignment
Address space assignments of any kind are valid as long as the
original criteria on which the assignment was based are still
valid. If an assignment is made for a specific purpose and that
purpose no longer exists, the assignment is no longer valid. If an
assignment is based on information that turns out to be invalid,
the assignment is no longer valid.
5.2.2 Dynamic Assignments
The use of static IP address assignments (e.g. one address per
customer) for dial-up users is strongly discouraged due to a
shortage of IPv4 address space. Organisations considering the use
of static IP address assignments are expected to investigate and
implement dynamic assignment technologies whenever possible. If
static IP address assignments are requested, special verification
procedures apply. However, for services that are permanently
connected to the Internet, static one-to-one connections are
considered acceptable, although verification is still needed.
All assignments to End Users need to be registered in the RIPE
Whois Database. However, static assignments of single IP addresses
to individual End Users (e.g. dial-up, ADSL, etc.) do not have to
be registered separately to the Database. However, special
verification methods apply.
5.2.3 Web Hosting
With the development of HTTP 1.1, the need for one-to-one mapping
of IP addresses to web sites has been eliminated. The RIPE
community strongly encourages the deployment of name-based web
hosting versus IP-based web hosting in accordance with the goal of
conservation. For certain applications the need for IP-based web
hosting is recognised and should be described. Special verification
methods apply for IP-based web hosting.
5.2.4 Renumbering
In general, address space can be replaced on a one-to-one basis. A
valid assignment can be replaced with the same amount of addresses
if the original assignment criteria are still met and if the
address space to be replaced is currently in use. An End User will
be required to submit the usual documentation to the LIR only if a
large percentage of the original assignment is not in use
(50%). This part of the request is then treated as any other
request for the assignment of additional addresses.
If this exceeds the Assignment Window, see Section 5.2.5.2
(Assignment Window for End User Assignments), the renumbering
request needs to be sent to the RIPE NCC for approval.
A period of three months is generally accepted, within the RIPE
community, to be enough to migrate a network from the old to the
new address space. For exceptional cases where the End User
requests to keep both assignments for more than three months, an
agreement should be obtained from the RIPE NCC for the proposed
time frame.
5.2.5 Assignment Window
An Assignment Window (AW) refers to the maximum number of addresses
that can be assigned by the LIR to either their own network or to
an End User's network without prior approval from the RIPE
NCC. This is expressed in /nn notation.
The Assignment Window procedure was put in place to achieve various
levels of support based on the level of experience of the LIR. The
RIPE NCC may review LIR assignments made with the LIR's AW in order
to ensure that the LIR is assigning according to policies. This is
important to assure the fair distribution of address space and to
meet the goals of aggregation, conservation and
registration. Documentation regarding assignments made with an AW
need to contain equivalent information as in a completed IPv4
Address Space Request Form.
All new LIRs start with an Assignment Window of zero (0). This
means that every assignment requires prior approval from the RIPE
NCC.
The AW is applied differently depending on whether the assignment
is for an End User or for the LIR's infrastructure.
5.2.5.1 Assignment Window for LIR Infrastructure
The Assignment Window policy was adjusted in December 2001 to
include LIR infrastructure assignments. There is no constraint as
to how often the LIR uses its AW for its own infrastructure
assignments. These assignments may not exceed the LIR's AW. This
means that an LIR with a /25 AW can make numerous individual /25
assignments to its own network infrastructure without having to
send each request to the RIPE NCC. However, where a single
assignment would exceed a /25 the LIR would need to complete an
IPv4 Address Space Request Form and send it to the RIPE NCC for
approval.
An LIR must specify which assignments have been made with the AW to
the LIR's own infrastructure. Such assignments must have a
"remarks:" attribute with the value <INFRA-AW> in the inetnum
object registered in the RIPE database. It is important that a
separate "remarks:" attribute is used solely for this purpose.
For further explanation of the Assignment Window procedures, please
refer to Section II (Assignment Window) of the Appendix.
5.2.5.2 Assignment Window for End User Assignments
An LIR can apply their Assignment Window to an End User network
only once in any 12-month period. This means that if an LIR makes
more than one assignment to an organisation, the total amount of
address space assigned with their AW in any twelve month period may
not exceed the LIR's AW size. The LIR may only assign additional
addresses to the same organisation after approval from the RIPE
NCC.
5.3 Policies and Guidelines for Allocations
All LIRs that receive address space from the RIPE NCC shall adopt
allocation and assignment policies that are consistent with the
policies formulated by the RIPE community as described in this
document.
An LIR cannot have more than one "open" (less than about 80%
assigned) allocation.
The RIPE NCC is the only organisation that allocates address space
in its service region. An LIR is not allowed to reallocate part of
its allocation to any other organisation. An LIR can only make
assignments. If an LIR is planning to exchange or transfer address
space it needs to contact the RIPE NCC so that the changes can be
properly registered. Please note that the LIR always remains
responsible for the entire allocation it receives from the RIPE NCC
and that all policies are applied.
5.3.1 First Allocation
The minimum allocation size to LIRs is a /20 (4096 addresses),
according to the slow-start mechanism described in Section 5.3.2
(Slow-start Mechanism). It is expected that this prefix be
announced as one aggregate.
In order to receive an initial allocation an LIR needs to
demonstrate:
* either the efficient previous utilisation of a minimum /22 (1024
addresses)
* or an immediate need for at least a /22 of address space.
This can include address assignments to the LIR's infrastructure as
well as assignments to customers' networks that will be renumbered
into the LIR's new allocation.
Verification of previous efficient utilisation by an organisation
is based on the assignments registered in the RIPE Database, as
only assignments registered in the RIPE Database are considered
valid.
Further details can be found in the RIPE document "Guidelines for
Setting up a Local Internet Registry at the RIPE NCC" available
from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/new-lir.html
5.3.2 Slow-start Mechanism
The intent of the slow-start mechanism is to treat all new LIRs
equally by allocating address space to LIRs at the rate that the
addresses are assigned by the LIRs. The minimum size of the first
allocation is /20 (4096 addresses). An allocation larger than a /20
can be made if the need is demonstrated. Additionally, the size of
future allocations will be based on the usage rate of the previous
allocation.
The slow-start mechanism was put into place by the Regional
Internet Registries to ensure a consistent and fair policy for all
LIRs with respect to allocations.
5.3.3 Further Allocations
An LIR is eligible for additional address space allocation when:
* about eighty percent (80%) of the currently allocated address
space is used in valid assignments;
* or if a single assignment will require a larger set of addresses
that cannot be satisfied with the address space currently held by
the LIR;
* the appropriate documentation is available for each assignment;
* each assignment is registered in the RIPE Whois Database;
* all allocations must be at about 80% usage;
* overall usage must also be about 80%.
Reservations are not counted as assignments. It may be useful for
internal aggregation to keep some address space free for future
growth in addition to the actual assignment. However, the LIR must
be aware that these internal reservations do not count as
assignments. The space must be assigned before the LIR can request
another allocation. The size of further allocations mainly depends
on the assignment rate of previous allocations.
To obtain a new allocation, an LIR should submit a request to the
RIPE NCC using the "IPv4 Additional Allocation Request Form"
available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/add-allocation.html
Please include a complete list of the assignments (i.e. IP address
range and netname) made from their last allocation. However, all
previous allocations made to the LIR also need to show a
utilisation rate of about 80%.
Additional address space will be allocated only after the
information supplied with the request has been verified and a new
allocation has been deemed necessary.
The RIPE NCC will do its best to allocate contiguous address space
in order to support aggregation. This cannot be guaranteed as it
depends on factors outside the RIPE NCC's influence (e.g. the
number of new LIRs and the time needed to utilise the allocation).
5.4 Operating an LIR
This section outlines procedures associated with IP registration
services that LIRs are expected to follow in order to ensure that
the policies are applied in a fair and impartial manner throughout
the entire RIPE NCC service region.
5.4.1 Record Keeping
All documentation related to an IP address request and assignment
must be maintained by the LIR for future reference. This data is
needed for the evaluation of subsequent requests for the same
organisation/End User, for audits by the RIR, and for the
resolution of any questions that may arise regarding
assignments. The records must include:
* The original request
* All supporting documentation
* All related correspondence between the LIR and the customer
* The assignment decision, including:
+ Reasons behind any unusual decision
* The person responsible for making the decision.
The chronology of events and the persons responsible should be
stated clearly in the records. In order to facilitate the exchange
of information, it is highly recommended that documents are kept
electronically and readily accessible. If requested, any of this
information should be made available to the RIPE NCC in English.
5.4.2 LIR Contact Persons
Each LIR must provide the RIPE NCC with a list of contact
persons. The contact persons should be those who submit address
space requests for the LIR. This contact information should be kept
up-to-date. Address space requests will only be accepted from LIR
staff members that are registered as contact persons for an
LIR. This is necessary to ensure confidentiality. Every registered
contact person can make updates and/or changes to the contact
information the RIPE NCC keeps for that LIR.
A list of registered contact person's responsibilities and
important referencing documents can be found at:
http://www.ripe.net/ripe/docs/new-lir.html
5.4.3 Mergers, Takeovers, and Closures of LIRs
In the event that an LIR changes ownership (e.g. merger, sale, or
takeover), the new entity must register any changes to its network
operations or contact persons with the RIPE NCC. If the effect of a
takeover, sale, or merger results in a change of the LIR as a legal
the new organisation to the RIPE NCC.
Further information on change of LIR ownership and closures is
presented in the RIPE document "Mergers, Acquisitions, Takeovers
and Closures of Organisations Operating an LIR" available from the
RIPE Document Store at:
http://www.ripe.net/ripe/docs/mergers.html
5.4.4 LIR Audit
The RIPE NCC was asked by the RIPE community to audit LIR
operations in order to ensure consistent and fair implementation of
address policies set by the community. This includes regular checks
of assignment data in the RIPE Whois Database for completeness and
consistency. The RIPE NCC may also contact an LIR to ask for
documentation or for more information about certain requests or
database entries. The RIPE NCC will work with an LIR to correct any
problems that are found. If necessary, the RIPE NCC may take
corrective action such as adjust the LIR's Assignment Window.
This activity is described in detail in the RIPE document "RIPE NCC
Consistency and Auditing Activity" available from the RIPE Document
Store at:
http://www.ripe.net/ripe/docs/audit.html
For further information regarding the RIPE NCC auditing activity,
please refer to:
http://www.ripe.net/audit
5.4.5 Closure of an LIR by the RIPE NCC
The RIPE NCC may decide to close an LIR for any of the following
reasons:
* the LIR stops paying its bills to the RIPE NCC
* the LIR cannot be contacted by the RIPE NCC for a significant
period of time
* If an LIR consistently violates the policies applicable in the
RIPE NCC service region.
In the event of an LIR closure, the RIPE NCC will take
responsibility for all address space held by the LIR.
5.4.6 Reverse Delegation
LIRs should maintain in-addr.arpa resource records for their
customers' networks. The RIPE NCC only accepts requests for reverse
delegation from LIRs. More information about reverse delegation can
be found in the document "Reverse Delegation Under "in-addr.arpa"
in the RIPE NCC Service Region" available from the RIPE Document
Store at: http://www.ripe.net/ripe/docs/rev-del.html
6.0 Appendices
I. RIPE Whois Database Procedures
Registration of objects related to an assignment in the RIPE Whois
Database enables uniqueness of IP addresses and provides contact
information for troubleshooting.
This is essential for the effective administration and operation of
IP networks.
The information collected about the End User's organisation in the
Network Template (see
http://www.ripe.net/ripe/docs/iprequestsupport.html) is used to
construct an inetnum object. The range of addresses assigned to the
End User is also entered in the inetnum object and is specified in
dotted quad notation. For example, if an organisation is assigned a
/22 address set for 1024 network addresses, the range will resemble
the following:
193.0.0.0 - 193.0.1.255
Submission of objects to the RIPE Whois Database is the final step
in making an assignment. This step validates the assignment and
makes the information regarding the assignment publicly
available. Therefore, care should be taken to assure the assignment
and of all relevant data is correct prior to completing this step.
A person object must be submitted for each person specified in the
"tech-c:" and "admin-c:" fields of the inetnum object unless
up-to-date objects are already available in the RIPE Database in
addition to the inetnum object. The person object is referenced
from the inetnum by its nic-handle.
The information should remain in the RIPE Database for as long as
the original assignment is valid. If the address space is returned,
the LIR that made the assignment must remove the old entry from the
RIPE Database.
An assignment is considered valid when based on the following
factors:
* all assignments must be registered in the RIPE Database
* assignments should either be covered by an LIR's AW or should have
received prior approval from the RIPE NCC
* Database objects describing an assignment approved by the RIPE NCC
should:
+ use the same "netname:" as approved by the RIPE NCC
* use the date of approval or a later date in the first
"changed:"line of the inetnum object
* not exceed the number of IP addresses approved by the RIPE NCC.
The type of the assigned address space must be registered in the
"status:" attribute of the inetnum object. The possible values of
this attribute are:
ASSIGNED PA
This is used for PA address space that has been assigned to an End
User.
ASSIGNED PI
This is used for PI address space that has been assigned to an End
User.
Every new address space assignment must be marked as PA or PI in
the RIPE Database. To improve registration of old assignments, LIRs
are encouraged to mark legacy assignments in the RIPE Database with
PA or PI as appropriate. This should be done in collaboration with
the End User to make sure of the status of the address space is
correct. Both LIR and End User should understand the implications.
Allocation Registration
The RIPE NCC registers all address space allocated to an LIR in the
RIPE Whois Database using inetnum objects. inetnum objects
describing allocations to LIRs are maintained by the RIPE
NCC. Hierarchical authorisation must be used to allow the LIR the
creation of inetnum objects more specific than the allocation
objects as detailed in: "New Values of the "status:" Attribute for
inetnum Objects (LIR-PARTITIONED)" which is available from the RIPE
Document Store at:
http://www.ripe.net/ripe/docs/lir-partitioned.html
Organisational information about the LIR is stored together with
the address space range and the type of addresses. The range of the
addresses is stored in the "inetnum:" field in dotted quad
notation. The address type is stored in the "status:" field and
can have one of the following values:
ALLOCATED PA
This address space has been allocated to an LIR or an RIR and all
assignments made from it are provider aggregatable. This is the
most common allocation type for LIRs.
ALLOCATED PI
This address space has been allocated to an LIR and all assignments
made from it are provider independent. This case is extremely rare
and is only done after careful consideration.
ALLOCATED UNSPECIFIED
This address space has been allocated to an LIR and assignments
made from it may be either provider aggregatable or provider
independent. This type of allocation is obsolete and will not be
applied to future allocations. Some older allocations have been
used for both PA and PI assignments and as such received this
allocation type.
For information and instructions on the use of the RIPE Database,
please refer to the document: "RIPE Database Reference Manual"
available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/databaseref-manual.html
II. Assignment Window
The LIR's Assignment Window can either be applied to assignments
for their own network infrastructure or for End User assignments.
As mentioned in Section 5.2.5.1 (Assignment Window for LIR
Infrastructure), LIRs must specify in the RIPE Database which
assignments have been made to the LIR's own infrastructure network
using their AW. Only assignments to the LIR's infrastructure may
have the <INFRA-AW> identifier. Assignments to End Users do not
need any identifier.
The AW is regularly reviewed by the RIPE NCC Hostmasters. LIRs may
approach the RIPE NCC for an evaluation of its Assignment Window at
any time. Please note that LIRs are always welcome to approach the
RIPE NCC for a second opinion on requests even if they fall within
the LIR's Assignment Window.
Raising of the Assignment Window
As the proficiency of the LIR contacts increases, the size of their
Assignment Window may be raised. This is determined based on:
* correctly completed documentation presented to the RIPE NCC
* good judgement shown in the evaluation of address space requests
* past assignments have been properly registered.
Lowering of the Assignment Window
An established LIR is responsible for training new LIR contacts to
handle address space assignments according to the policies
described in this document and their procedures. Less experienced
LIR contacts may make errors both in judgement and procedure. If
errors happen repeatedly the Assignment Window of the LIR may be
decreased to prevent the LIR from making erroneous assignments. The
Assignment Window may again be increased based on the criteria
stated above.
The Assignment Window may be lowered as a result of an audit where
erroneous assignments are noted or to enforce overdue payment.
III. Useful URLs
RIPE NCC Registration Services information
http://www.ripe.net/rs/
RIPE NCC E-mail contacts
http://www.ripe.net/ripencc/about/contact.html
RIPE NCC Frequently Asked Questions
http://www.ripe.net/ripencc/faq/index.html
Quick Tips for IP and AS Requests
http://www.ripe.net/ripencc/tips/tips.html
IPv6 Allocation and Assignment Information
http://www.ripe.net/ipv6
New Values of the "status:" Attribute for inetnum Objects
(LIR-PARTITIONED)
http://www.ripe.net/ripe/docs/lir-partitioned.html
RIPE Document Store
http://www.ripe.net/ripe/docs/index.html
IV. Bit Boundary Chart
Historically, IP addresses have been assigned in the form of
network numbers of class A, B, or C. With the introduction of CIDR
(Classless Inter-Domain Routing) classful restrictions are no
longer valid. Address space is now allocated and assigned on bit
boundaries. The following table illustrates this:
+----------------------------------------------+
|addrs bits pref mask |
+----------------------------------------------+
| 1 0 /32 255.255.255.255 |
| 2 1 /31 255.255.255.254 |
| 4 2 /30 255.255.255.252 |
| 8 3 /29 255.255.255.248 |
| 16 4 /28 255.255.255.240 |
| 32 5 /27 255.255.255.224 |
| 64 6 /26 255.255.255.192 |
| 128 7 /25 255.255.255.128 |
| 256 8 /24 255.255.255 |
| 512 9 /23 255.255.254 |
| 1K 10 /22 255.255.252 |
| 2K 11 /21 255.255.248 |
| 4K 12 /20 255.255.240 |
| 8K 13 /19 255.255.224 |
| 16K 14 /18 255.255.192 |
| 32K 15 /17 255.255.128 |
| 64K 16 /16 255.255 |
| 128K 17 /15 255.254 |
| 256K 18 /14 255.252 |
| 512K 19 /13 255.248 |
| 1M 20 /12 255.240 |
| 2M 21 /11 255.224 |
| 4M 22 /10 255.192 |
| 8M 23 /9 255.128 |
| 16M 24 /8 255 |
| 32M 25 /7 254 |
| 64M 26 /6 252 |
| 128M 27 /5 248 |
| 256M 28 /4 240 |
| 512M 29 /3 224 |
|1024M 30 /2 192 |
+----------------------------------------------+
'bits'
The size of the allocation / assignment in bits of address space.
'addrs'
The number of addresses available; note that the number of
addressable hosts is normally two less than this number because the
host parts with all equal bits (all 0s, all 1s) are reserved.
'pref'
The length of the route prefix covering this address space. This is
sometimes used to indicate the size of an allocation / assignment.
'mask'
The network mask defining the routing prefix in dotted quad
notation. Throughout this document, the RIPE NCC refers to the
size of allocation and assignments in terms of 'bits of address
space' and adds the length of the route prefix in parentheses
wherever appropriate.