New Draft version of IPv4 Policy Document
- Date: Sun, 03 Mar 2002 20:28:13 +0000
Dear IPv4 editorial group,
Please find below the new version of the IPv4 policy document. We
received a number of comments, most of them have been incorporated in
this version. You will notice that this new document is much smaller
than the current ripe-185 and therefore hopefully easier to read. We
tried to concentrate mainly on policies and took procedural details
out wherever possible. This will make the document more compact and
also more stable. You will further notice that the document still
contains editorial notes, mainly to illustrate some of the changes.
I would however recommend to read the entire document very carefully.
I would like to thank Nurani Nimpuno who has put much effort into the
first versions of this document and everybody for their feedback and
collaboration. I am looking forward for the next round of comments :-)
Kind Regards,
Mirjam Kuehne
RIPE NCC
**************************************************
IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region
Document ID: ripe-[insert number here]
Date Published: [insert date here]
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 Working Group (LIR WG) of the
RIPE community and implemented by the RIPE NCC. These policies are
valid for the RIPE NCC and the Local Internet Registries in the RIPE
NCC service region.
Table of Contents
The numbering in the table of contents doesn't match the numbering in
the text. Please double check. Example: 5.2.3 and following
Abstract
1.0 Introduction
1.1 Scope
2.0 Internet Address Space (NOTE: will be separate document)
3.0 The Internet Registry System (NOTE: will be separate document)
3.1 Goals of Public Address Space Distribution
4.0 Policy Framework (NOTE: will be separate document)
5.0 IPv4 Policies
5.1 General
5.1.1 Validity of Assignment
5.1.2 Documentation
5.1.3 Registration Requirements
5.2.4 Reservations not supported
5.1.5 Administrative Ease
5.1.6 Utilisation
5.1.7 Provider Independent vs. Provider Aggregatable addresses
5.1.8 Private Address Space
5.1.9 Static Assignments
5.1.10 Web hosting
5.1.11 Assignments Guidelines
5.1.12 Renumbering
5.1.13 Assignment Window for End User Assignments
5.1.14 Assignment Window for LIR Infrastructure
5.2 Policies and Guidelines for Allocations
5.2.1 First allocation
5.2.2 Slow-start Mechanism
5.2.3 Further allocations
5.3 Operating an LIR
5.3.1 Establishing a new LIR
5.3.2 Record keeping
5.3.3 Contact persons
5.3.4 Mergers, take-overs, and closures of LIRs
5.3.5 External Quality Assurance
5.3.6 Closure of an LIR by the RIPE NCC
6.0 Glossary (NOTE: will be separate document)
7.0 References
8.0 Appendices
I. RIPE 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 existing Regional Internet
Registries (RIRs). Its service region covers Europe, the Middle East,
Central Asia, and African countries north of the equator. As an RIR,
it is responsible for the assignment and allocation of IP address
space, Autonomous System Numbers and the management of reverse domain
name space. The distribution of IP address space follows the
hierarchical scheme described in <'Internet Registry System' document
to be published>.
The RIPE NCC allocates address space to Local Internet Registries
(LIRs) that assign it to End Users. In this document, the policies
associated with the distribution and management of IPv4 address space
that need to be implement by all LIRs are described.
The policies described in this document have been developed by the
RIPE community, through the open consensus process facilitated by the
RIPE NCC <pointer to 'Policy Framework' document to be published)
1.1 Scope
This document describes the policies for the responsible management of
the globally unique Internet address space and in the RIPE NCC service
region. The policies set forth in this document have been developed by
the RIPE LIR-WG are binding for all address space allocated and
assigned via the RIPE NCC.
This document does not describe specific addressing policies related
to IPv6, multicast, or private Internet address space. This document
does not describe allocation and assignment procedures used by other
RIRs. Policies regarding Autonomous System Numbers are also out of
scope for this document.
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 IP addresses:
Public Addresses
Public IP addresses are assigned to be globally unique according to
the goals described in Section 3.1. The main purpose of this address
space is to allow communication, using IPv4 over the Internet.
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 coordination. Hosts using these
addresses cannot be reached from the Internet. For a thorough
description of private address space, please refer to RFC 1918
[Rekhter96b].
Special and Reserved Addresses
There are a number of address ranges reserved for applications like
multicasting. These are described elsewhere (cf RFC 1112 [Deering89a])
and are beyond the scope of this document.
3.0 The Internet Registry System (NOTE:will be published as separate document)
4.0 Policy framework (NOTE: will be published as separate document)
5.0 IPv4 Policies
5.1 General
The policies in this 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 Validity of assignment
Assignments of any kind of address space 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 the purpose
no longer exists, then the assignment is no longer valid. If an
assignment is based on information that turns out to be invalid, so is
the assignment.
5.1.2 Documentation
To make appropriate assignment decisions, relevant information must be
gathered about the network in question in order to determine the
amount of addresses needed. Such information may include organisation,
addressing requirements, network infrastructure, current address space
usage, and future plans of the End User requesting address space. This
information is essential to the assignment process, and is formally
required by the LIRs. The LIR must assure that the required
information is complete before proceeding with the request.
For gathering the required information, the RIPE NCC provides a set of
forms and supporting notes to fill them in. LIRs may use them for
their customers or develop their own local form. The set of
information requested in the form provided by the RIPE NCC should be
gathered by the LIR, but a local form can be used.
If the request needs to be sent to the RIPE NCC for approval or during
an audit, the information must be submitted on a current version of
the "European IP Address Space Request Form" in English:
http://www.ripe.net/ripe/docs/iprequestform.html
All information required by the RIPE NCC must be in English.
For complete instructions on how to fill out the "European IP Address
Request Form", please refer to:
http://www.ripe.net/ripe/docs/iprequestsupport.html
5.1.3 Registration Requirements
Every assignment and allocation of public Internet address space must
be registered in a publicly accessible whois Database. This is
necessary to ensure uniqueness and to support network operations.
Allocations and assignments in the RIPE NCC service region are
registered in the RIPE whois Database. Only allocations and
assignments registered in the RIPE Database are considered
valid. Submission of objects to the database is the final and required
step in making an assignment. This step makes the assignment definite,
and makes information regarding the assignment publicly available to
anyone seeking it. Care should therefore be taken to assure the
correctness of the data registered (e.g. correct IP address range,
contact information etc.)
Please note that assignments of up to a /30 to individual end users do
not have to be registered with the end users contact details but can
contain the contact details of the LIR. This also applies to leased
lines or point to point links of a /29. These assignments are viewed
as infrastructure of the LIR and can therefore be registered with the
LIR's contact details.
For further instructions on how to register objects in the database,
please see the appendix, section I.
5.1.4 Reservations not supported
In accordance with the conservation goal, End Users are not permitted
to reserve address space. Evaluation of IP address space requests must
be based on demonstrated need. Address space assigned in the past
should be used to meet the current request, if possible. 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 Utilisation
Unless there are special circumstances, immediate utilisation should
be at least 25% of the assigned address space, and the utilisation
rate one year later should be at least 50%. 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, because it fragments the
address space.
5.1.7 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 that can be announced as one prefix. If
an End User changes service providers, the PA address space assigned
by the previous service provider will have to be renumbered. The End
User will obtain new address space and return the previously assigned
addresses.
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 because no use can be made of aggregation and therefore they may
not be routable globally.
LIRs must make it clear to the 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.
The use of PA address space should always be recommended.
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" at:
http://www.ripe.net/ripe/docs/pi-pa.html
5.1.8 Private Address Space
Using private addresses helps to meet the conservation goal and
provides more flexibility for the user when addressing the
network. For this reason, users should always be informed that private
addresses might be a viable option. For a thorough description of
private address space, please refer to RFC 1918 [Rekhter96b].
5.1.9 Dynamic Assignments
Due to constraints on the available free pool of IPv4 address space,
the use of static IP address assignments (e.g., one address per
customer) for dial-up users is strongly discouraged. Organisations
considering the use of static IP address assignment are expected to
investigate and implement dynamic assignment technologies whenever
possible. If assignments for static assignments are indeed made,
special verification procedures apply. However, for services that are
permanently connected to the Internet, static one-to-one connections
are considered acceptable. If static assignments to a large number of
end users are made without registering these end user assignments in
the whois database (e.g. for static single-IP dial-up assignments,
cable modem usage with fixed IP address, DSL customers with fixed IP
address) special verification of address usage will apply. Please
contact the RIPE NCC for details on these verification methods.
5.1.10 Web hosting
Since the development of HTTP 1.1 the need for one-to-one mapping of
IP addresses to web sites has been eliminated. In accordance with the
goal of conservation, the RIPE community strongly encourages the
deployment of name-based web hosting versus IP-based web hosting. 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.1.11 Assignment Guidelines
LIRs make assignments from its allocated address block. If the
addresses are to be assigned from a range of address space allocated
to the LIR making the assignment, then care must be taken to prevent
fragmentation of the allocated space.
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 a best possible
way. If the assignment of the exact number of addresses needed creates
a large number of prefixes it might be better to assign one single
prefix. In other cases multiple prefixes might have to be 'carried' if
the assignment of one single prefix would 'waste' too many
addresses. Implications for both conservation and aggregation have to
be evaluated before an assignment is made.
LIRs are always welcome to request advice from the RIPE NCC in making
assignment decisions. Assignments larger than those that the LIR is
authorised to make must be approved by the RIPE NCC in advance. The
assignment size that an LIR is authorised to make without prior
approval is based on the LIR's experience and is reflected in the
LIR's Assignment Window. (See Section 5.1.13.)
5.1.12 Renumbering
In general, address space can be replaced on a one-to-one basis. An
assignment can be replaced with a different range of addresses if the
original assignment criteria are still met and if the address space to
be replaced is currently in use. Only if a large percentage of the
original assignment is not in use (50%) will an End User be required
to submit the usual documentation to the LIR. This part of the
request is then treated like any other request for assignment of
additional addresses.
If this exceeds the Assignment Window (see section 5.1.13), the
renumbering request needs to be sent to the RIPE NCC for approval.
Within the RIPE community a period of 3 months to migrate a network
from the old to the new address space is generally accepted. For
exceptional cases, where the End User requests to keep both
assignments for more than three months, agreement should be obtained
for the proposed time frame from the RIPE NCC.
5.1.13 Assignment Window for End User Assignments
An Assignment Window (AW) refers to the maximum number of addresses
that can be assigned by the LIR to either to an End User's
network. The Assignment Window procedure was put in place to achieve
various levels of support, based on the level of experience of the LIR
and to ensure that assignment policies are applied by the LIR. This is
important to ensure fair distribution of address space and to meet the
goals of aggregation, conservation and registration.
All new LIRs start with an Assignment Window of zero (0). This means
that every assignment requires prior approval by the RIPE NCC before
becoming effective.
This will encourage organisations to carefully plan the deployment of
the network and to prevent wastage of resources.
The Assignment Window is not only applied to individual assignments,
but to multiple assignments to the same End User network in a 12-month
period. If an LIR makes more than one assignment to an organisation in
any 12-month period, the total amount of address space assigned may
not exceed the LIR's assignment window. Additional address space may
be assigned to that organisation only upon approval by the RIPE NCC.
Address space assignments larger than the LIR's Assignment Window is
formally invalid until explicit approval is acquired from the RIPE
NCC.
It should be noted that LIRs may approach the RIPE NCC for an
evaluation of its Assignment Window. Additionally, LIRs are always
welcome to approach the RIPE NCC for a second opinion on requests that
fall within the LIR's Assignment Window.
For further explanation of the Assignment Window procedures, please
see Appendix, Section II.
5.1.14 Assignment Window for LIR Infrastructure
LIRs can make assignments to their own network infrastructure up to
their Assignment Window (AW) as many times as needed. 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 still need to send an IP Request Form to the RIPE NCC as
usual.
5.2 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 80% assigned)
allocation.
The RIPE NCC is the only organisation permitted to allocate address
space in its service region. An LIR is not allowed to re-allocate part
of its allocation to any other organisation. An LIR can only make
assignments. Moreover, without prior approval by the RIPE NCC, LIRs
are not permitted to exchange or transfer allocated address space
among them.
The RIPE NCC recognises that LIRs may want to give parts of their
allocation to re-sellers or downstream ISPs as this may be benefitial
for aggregation. It should be noted however, that the LIR will always
remain responsible for the entire allocation it received from the RIPE
NCC. That means the LIR has to make sure the appropriate documentation
is available for each assignment, each assignments gets registered in
the RIPE whois database and the entire allocation is utilised before
they requests additional address space (basically that all policies
are applied).
5.2.1 First Allocation
The minimum allocation size allocated to LIRs is a /20 (4096
addresses), according to the slow-start mechanism described below. It
is expected that this prefix is announced as one aggregate.
In order to receive an initial allocation, an LIR needs to demonstrate
either the utilisation of a minimum /22 (1024 addresses), or an
immediate address space need for at least a /22 . 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.
As only assignments registered in the RIPE Database are considered
valid, verification of previous utilisation by an organisation is
based on the assignments registered in the database.
Further details can be found in the document "Guidelines for Setting
up a Local Internet Registry at the RIPE NCC":
http://www.ripe.net/ripe/docs/new-lir.html
5.2.2 Slow-start Mechanism
The slow-start mechanism was put in place by the RIRs to ensure a
consistent and fair policy for every LIR with respect to
allocations. The slow-start mechanism was also introduced to prevent
allocating large blocks of address space that will not be used. The
idea is to allocate address space to LIRs at the rate it will be
assigned. The minimum size of an individual address space allocation
is /20 (4096 addresses). More than a /20 can be allocated if the need
can be demonstrated.
5.2.3 Further Allocations
An LIR is eligible for additional address space allocation when at
least eighty (80) percent of the currently allocated address space is
assigned, 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. Reservations are not counted as assignments. It may
be useful for internal aggregation to keep some address space free for
a customer for future growth in addition to the actual
assignment. However, the LIR must be aware that these internal
reservations do not count as assignments and 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 that includes 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 at least 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. However, 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.3 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
RIPE NCC service area.
5.3.1 Establishing a new LIR
The process of setting up a new LIR is explained in detail in the
Document, "Guidelines for Setting up a Local Internet Registry at the
RIPE NCC": http://www.ripe.net/ripe/docs/new-lir.html
5.3.2 Record Keeping
LIRs must maintain proper records about all address assignments made
by them. All documentation related to an IP address request and
assignment needs to be kept by the LIR for future reference.
This data is needed for the evaluation of subsequent requests for the
same customers, 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 that they are readily accessible. If requested, any
of this information should be made available to the RIPE NCC in
English.
5.3.3 LIR Contact Persons
Every 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. The 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.
5.3.4 Mergers, take-overs, and closures of LIRs
If an LIR changes ownership (e.g. merger, sale, or take-over), then
the new entity must register with the RIPE NCC any changes to its
network operations or contact personnel. If the effect of a take-over,
sale, or merger is that the legal entity of the LIR changes, then the
LIR must provide to the RIPE NCC relevant legal documentation showing
the new organisation.
For further information on change of LIR ownership and closures, see
the document <to be published>.
5.3.5 Auditing
In order to ensure consistent and fair implementation of assignment
policies set by the community, the RIPE NCC was asked to audit LIR
operations. 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. If the RIPE NCC finds
problems, it will work with the LIR to correct these. If necessary,
the RIPE NCC may take corrective actions, such as lowering the LIR's
Assignment Window. This activity is described in detail in the RIPE
Document, "RIPE NCC Consistency and Auditing Activity", which can be
found at: http://www.ripe.net/ripe/docs/auditing.html
For further information on the RIPE NCC auditing activity, please
refer to: http://www.ripe.net/audit
5.3.6 Closure of an LIR by the RIPE NCC
The RIPE NCC may decide to close an LIR that stops paying its bills to
the RIPE NCC and/or cannot be contacted by the RIPE NCC for a
significant period of time. Moreover, if an LIR consistently violates
they policies applicable in the RIPE NCC service region, then it might
have to be closed.
The RIPE NCC will determine which address space need to be returned to
the public pool of IP address space.
6.0 Glossary (NOTE: will be separate document)
7.0 References
To be completed
8.0 Appendices
I. RIPE Database Procedures
Registration of objects pertaining to an assignment in the RIPE
Database makes it possible to track the use of address space,
facilitate operational contacts.
These activities are essential for the effective administration and
operation of IP networks.
Submission of objects to the Database is the final and required step
in making an assignment. This step makes the assignment definite, and
makes public information regarding the assignment available to anyone
seeking it. Care should, therefore, be taken to assure the correctness
of the assignment and of all relevant data prior to completing this
step.
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 database object. The range of
addresses assigned to the 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 be something like: 193.1.192.0 - 193.1.195.255.
Unless up-to-date objects are already available in the RIPE Database,
in addition to the inetnum object, a person object must be submitted
for each person specified in the tech-c and admin-c fields of the
inetnum object. The person object is referenced from the inetnum by
its nic-handle.
The information should remain in the 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
Database.
The type of the assigned address space must be registered in the status
attribute of the inetnum object within the RIPE Database by the
assigning LIR. 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. Moreover, to improve registration of old
assignments, LIRs are encouraged to mark past assignments in the RIPE
Database with PA or PI as appropriate. This should be done in
collaboration with the End User to make sure the status of the address
space and the implications are understood by both sides.
Allocation Registration
The RIPE NCC registers all address space allocated to an LIR in the
RIPE whois database using inetnum objects.
Organisational information about the LIR is stored together with the
address space range and the type of the addresses. The range of the
addresses is stored in the inetnum field in dotted quad notation. The
type of address 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 receive this allocation
type.
These objects are maintained by the RIPE NCC. When hierarchical
authorisation is implemented, authorisation can be used for the
creation of inetnum objects "under" the allocation objects.
For information and instructions on the use of the RIPE Database,
please refer to the RIPE Document: "RIPE Database Reference Manual"
at:
http://www.ripe.net/ripe/docs/databaseref-manual.html
II. Assignment Window
As explained in Section 5.1.13, the Assignment Window is the maximum
number of addresses that can be assigned by the LIR to an End User
without prior approval by the RIPE NCC. The AW is expressed in prefix
notation.
Therefore, an LIR with an Assignment Window of /23 is allowed to
assign up to and including 512 addresses to an End User or the LIR's
own network without prior approval of the RIPE NCC. All new LIRs start
with an Assignment Window of "0". This means that every assignment
requires prior approval by the RIPE NCC before becoming effective.
Example 1: The LIR has an Assignment Window of "0". The LIR has to
send in every assignment to the RIPE NCC for approval.
Example 2: The LIR has an Assignment Window of /26. The LIR can assign
up to 64 addresses per customer in a 12 month period. Larger
assignments need to be sent to the RIPE NCC for approval. Any
additional assignments exceeding 64 addresses also need to be sent to
the RIPE NCC for approval.
The AW is regularly reviewed by the RIPE NCC Hostmasters.
Raising of the Assignment Window
As the proficiency of the LIR staff increases, the size of their
Assignment Window may be raised. This is determined based on whether
assignment documentation presented to the RIPE NCC is correctly
completed; whether good judgement is shown in the evaluation of
address space requests; whether past assignments have been properly
registered; and on the experience of the LIR with handling larger
assignments.
Lowering of the Assignment Window
An established LIR is responsible to train new staff to handle address
space assignments, according to the policies and procedures described
in this document. Sometimes, due to time constraints on experienced
LIR staff, the training is not performed sufficiently. As well, new
staff members of a well-established LIR may make errors both in
judgement and procedure before they are properly trained to make
assignments. If such errors are noticed by the RIPE NCC, the LIR will
be notified. If errors happen repeatedly, the Assignment Window of the
LIR may be decreased to prevent the new staff members from making
erroneous assignments involving large amounts of address space. 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.
In some cases, LIRs may request a temporary lowering of their
Assignment Window as a method to train new staff.
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
RIPE Documentation 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 advent of classless inter-domain
routing (CIDR) this classful restrictions are no longer valid. Address
space is now allocated and assigned on bit boundaries. The following
table illustrates this:
+----------------------------------------------+
|addrs bits pref class 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 1C 255.255.255 |
| 512 9 /23 2C 255.255.254 |
| 1K 10 /22 4C 255.255.252 |
| 2K 11 /21 8C 255.255.248 |
| 4K 12 /20 16C 255.255.240 |
| 8K 13 /19 32C 255.255.224 |
| 16K 14 /18 64C 255.255.192 |
| 32K 15 /17 128C 255.255.128 |
| 64K 16 /16 1B 255.255 |
| 128K 17 /15 2B 255.254 |
| 256K 18 /14 4B 255.252 |
| 512K 19 /13 8B 255.248 |
| 1M 20 /12 16B 255.240 |
| 2M 21 /11 32B 255.224 |
| 4M 22 /10 64B 255.192 |
| 8M 23 /9 128B 255.128 |
| 16M 24 /8 1A 255 |
| 32M 25 /7 2A 254 |
| 64M 26 /6 4A 252 |
| 128M 27 /5 8A 248 |
| 256M 28 /4 16A 240 |
| 512M 29 /3 32A 224 |
|1024M 30 /2 64A 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 normally is 2 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.
'class' The size of the address space in terms of classful network
numbers. 'mask' The network mask defining the routing prefix in
dotted quad notation. Throughout this document, we refer to the size
of allocation and assignments in terms of 'bits of address space' and
add the length of the route prefix in parentheses wherever
appropriate.
