ripe-104++
- Date: Mon, 22 Jan 1996 18:53:45 +0100
Dear Local IR Working Group,
The document included below is the first part of a document intended
to replace ripe-104 and ripe-105. While we have made progress on the
latter half, it is not ready for review. You can see what will be
covered there if you read Section 1.
This will be the background for the discussion mentioned by Mike
Norris for the Local IR working group meeting next week.
A number of people, most notably Mike Norris, Wilfried Woeber
and Janos Zsako, have made useful comments and contributions to
the draft below. Any remaining problems are, however, the
responsibility of the authors.
While our aim was to write down current practices, we understand that
it may raise questions about policy. That's why we want to get it out
to you before the RIPE meeting next week.
Any errors you note can be sent directly to me (orange@localhost).
I look forward to meeting you all next week.
-- Carol
PS: Postscript follows in a separate message.
------------------------------------------------------------------------
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
European Internet Registry
Policies and Procedures
Version 0.1
C. Orange, M. Kuehne, D. Karrenberg
Document ID: ripe-104++
Obsoletes: ripe-104, ripe-105, ripe-127, ripe-128
ABSTRACT
The distribution of IP address space
follows the hierarchical scheme described
in RFC1466. For Europe and parts of the
surrounding area address space is allo-
cated by IANA to the RIPE NCC which acts
as a regional Internet registry. Address
space is allocated by the RIPE NCC to
local Internet Registries (IR), who assign
it to to end users. In this document, we
describe the policies and procedures asso-
ciated with address space management that
must be followed by local IRs. Moreover,
we present a number of services available
to local IRs to simplify the tasks associ-
ated with address space management.
1. Scope
This document describes the European Internet reg-
istry system for the distribution of globally unique
Internet address space and its operation. Particu-
larly it describes the rules and guidelines govern-
ing the distribution of this address space. The
rules set forth in this document are binding for all
address space allocated and assigned via the RIPE
NCC.
This document does not describe private Internet
address space and multicast address space. This
document does not describe local additions to the
European guidelines. While providing an overview
about the global Internet registry system this
____________________________________________________
ripe-104++.txt Page 1
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
document does not describe allocation and assignment
rules used by other regional registries.
1.1. Overview
The main body of this document comprises eight sec-
tions, with content as follows.
Section 2 (Internet Address Space and the Internet
Registry System) defines different types of IP
address space and their purposes. It explains the
goals used in assigning such addresses and outlines
the hierarchical nature of the Internet Registry
system used to achieve these goals. The important
distinction between Provider Aggregatable and
Provider Independent address space is also covered.
In Section 3 (Address Space Assignment Procedures),
the procedures to be followed by European IP reg-
istries when assigning IP addresses to users. The
importance of documentation is stressed, while the
various elements of information required are
explained in detail. Next, the criteria and stan-
dards of evaluation are dealt with. Finally, the
actual assignment of address space, of various
kinds, is described, as are the accompanying steps
which a registry must take.
Section 4 (Rules and Guidelines for Allocations)
explains how the RIPE NCC allocates IP address space
to registries in an efficient and equitable manner
and how the status and nature of such allocations
are made publicly available in the RIPE database.
Section 5 (DNS and Reverse Address Mapping) docu-
ments the role of the RIPE NCC in providing reverse
delegation, and explains how registries can manage
subsidiary reverse delegation of assigned address
space.
Section 6 (Internet Registry Operations) documents
operational procedures of IR. This includes informa-
tion on starting and closing an IR, communications,
record keeping, confidentiality, and policies on IR
operations. Moreover various resources and tools
for registry operation are described in that sec-
tion.
Section 7 (AS Number Assignment Procedures and Poli-
cies) describes how to manage a group of IP networks
as an autonomous system. Both the procedural and
technical issues involved in AS number management
____________________________________________________
ripe-104++.txt Page 2
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
are described.
Section 8 (Interdomain Routing Considerations)
describes the policies and procedures necessary to
originate routes for assigned address space.
We conclude with a glossary in which the key terms
used in this document are defined.
____________________________________________________
ripe-104++.txt Page 3
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
2. Internet Address Space and the Internet Registry System
2.1. Types of IP Addresses
IP addresses for the purposes of this document are
32-bit binary numbers used as addresses in the IPv4
protocols. There are three main types of IP
addresses
Public Addresses
The public IP addresses make up the Internet
address space. They are assigned to be glob-
ally unique according to the goals described
below. The main purpose of this address space
is to allow communication using IPv4 over the
Internet. A secondary purpose is to allow com-
munication using IPv4 over interconnected pri-
vate internets. One can currently distinguish
two kinds of public addresses: provider inde-
pendent (PI) and provider aggregatable (PA)
addresses; see below for more details.
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 net-
works without any registration or coordination.
Hosts using these addresses can not be reached
from the Internet. For a thorough description
of private address space, please refer to
RFC1597.
Special and Reserved Addresses
There are a number of address ranges reserved
for applications like multicasting. These are
described elsewhere [ref] and are beyond the
scope of this document.
____________________________________________________
ripe-104++.txt Page 4
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
2.2. Goals of Public Address Space Distribution
In the remainder of this document, we are primarily
concerned with the management of public Internet
address space, as defined in the previous section.
Every assignment of Internet addresses must guaran-
tee that the following restriction is met.
Uniqueness
Each public Internet address worldwide must be
unique.
This is an absolute requirement which guarantees
that every host on the Internet can be uniquely
identified.
In addition to the uniqueness requirement, public
Internet address space assignments should be made
with the following three goals in mind.
Aggregation
The distribution of public Internet addresses
in a hierarchical manner, permitting the aggre-
gation of routing information. This is neces-
sary to ensure proper operation of Internet
routing. This goal could also be called
"Routability".
Conservation
The fair distribution of public Internet
address space according to the operational
needs of the end users operating networks using
this address space. In order to maximize the
lifetime of the public Internet address space
resource, addresses must be distributed accord-
ing to need, and stockpiling must be prevented.
Registration
The provision of a public registry documenting
address space allocation and assignment. This
is necessary to ensure uniqueness and to pro-
vide information for Internet trouble shooting
at all levels.
It is in the interest of the Internet community as a
whole that the above goals are pursued. It is worth
noting that "Conservation" and "Aggregation" are
____________________________________________________
ripe-104++.txt Page 5
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
often conflicting goals, and therefore that each
assignment must be evaluated carefully. Moreover,
the above goals may occasionally be in conflict with
the interests of individual end users or Internet
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 Internet reg-
istries and end users in their search for good com-
promises.
____________________________________________________
ripe-104++.txt Page 6
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
2.3. The Internet Registry System
The Internet Registry system has been established to
achieve the above stated goals. It consists of
hierarchically organized Internet Registries (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 organizations operating networks
in which the address space is used. The address
space may, however, be requested by a consultant
(requester) acting on behalf of the end user. 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 local IRs
for future assignments to end users. To achieve
both the conservation and aggregation goals, only
IRs can hold allocations of address space.
IANA
The Internet Assigned Numbers Authority has author-
ity over all number spaces used in the Internet.
This includes IP address space. IANA allocates pub-
lic Internet address space to regional IRs according
to their established needs.
Regional IRs
Regional IRs operate in large geopolitical regions
such as continents. To date, three Regional IRs have
been established, namely the InterNIC serving North
America, the AP-NIC serving the Asian Pacific
region, and the RIPE NCC serving Europe and sur-
rounding areas. Since these do not cover all geo-
graphical areas, regional IRs also serve areas
around their core service areas. The number of
regional IRs is expected to remain small.
Regional IRs are established under the Authority of
IANA. This requires consensus within the Internet
community of the region. In particular, the ISPs in
the region under consideration should be involved in
the process. The duties of a regional IR include the
coordination and representation of the local IRs in
its region.
____________________________________________________
ripe-104++.txt Page 7
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
Local IRs
Local IRs are established under the authority of a
regional IR. Local IRs are typically operated by
ISPs and serve the customers of those ISPs as well
as the customers of smaller ISPs who are connected
to the rest of the Internet through the larger ISP.
Other organizations such as large international
Enterprises can also operate local IRs.
Much of this document is concerned with the respon-
sibility of the local IR in the assignment process.
In some cases, the local IR assigning the address
space is not run by the ISP that will provide con-
nectivity. It is important to note that maintenance
of the administrative information regarding the
assigned address space is the responsibility of the
IR that makes the assignment, and not of the ISP
providing the connectivity. Furthermore, only IRs
can hold address allocations.
End-Users
Strictly speaking end users are not part of the IR
system. They do, however, play an important role
with respect to the goals defined above. In order to
achieve the conservation goal, for example, end
users should plan their networks to use a minimum
amount of address space. They must document their
addressing and deployment plans to the IR and fur-
nish any additional information required by the IR
for making assignment decisions. To achieve the
aggregation goal, an end user should choose an
appropriate local IR. End users should be aware that
changing ISPs may require replacing addresses in
their networks. Finally end users must provide and
update registration data for the address space
assigned to them.
Requesters
In addition to these key players in the Internet
Registry System, there are often consultants who
setup and manage networks for end users. The consul-
tants may be the people actually submitting a
request for address space to an IR on behalf of an
end user. We refer to the person making the request
for an end user as a requester, whether that person
is employed by the organization, or is simply acting
on behalf of the organization with respect to the
address space request.
____________________________________________________
ripe-104++.txt Page 8
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
For Europe, the Internet Registry System hierarchy
consists of the following entities (from the top
down): IANA, the RIPE NCC, Local IRs. See Appendix A
the area covered by the RIPE NCC.
2.4. Provider Independent vs Provider Aggregatable Addresses
Provider Aggregatable Address Space
Local IRs operated by Internet service providers are
allocated Provider Aggregatable (PA) address space
which they assign to their end users. This is done
in such a way that routing information for many end
users of an ISP can be aggregated on the borders of
the provider's routing domain. This keeps the num-
ber of routes and state changes in the interdomain
routing system (between providers) at an acceptable
level. The cost of propagating a relatively small
number of aggregated routes is much lower than that
of propagating each end user's individual routes
throughout the entire interdomain routing system.
If an end user changes service providers, their PA
address space will have to be replaced. As a conse-
quence, all hosts and routers at the end user's
organization will have to be reconfigured. The end
user will need to obtain an assignment from the
local IR run by the new service provider, and return
the previously assigned address space to the local
IR run by the old service provider. To ensure the
address space is properly returned, a clear, prefer-
ably contractual, understanding is needed between
the service provider and the end user. The agreement
should state that the assignment of the address
space becomes invalid when the provider no longer
provides Internet connectivity to the end user or
shortly thereafter.
The goal of this arrangement is to minimize the load
on the interdomain routing system. If the end user
continued to use PA address space obtained from
their previous service provider when connecting to
another service provider, their routing information
could not be aggregated and would have to be propa-
gated separately throughout the whole interdomain
routing system.
____________________________________________________
ripe-104++.txt Page 9
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
Provider Independent Address Space
In contrast to PA address space, PI address space
can remain assigned to its user as long as the cri-
teria for the original assignment are met. The dura-
tion of the assignment is independent of the use of
a particular provider's services. The apparent
advantage of PI address space is that a user's hosts
and routers need not be reconfigured if the user
decides to change service providers. However, PI
addresses are expensive to route because no use can
be made of aggregation. All early Internet address
space assignments were provider independent. Many
assignments made by local IRs are also formally
provider independent due to a lack of prior agree-
ments between ISP and the end user that the assign-
ment will be terminated when the service is.
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 assign-
mnet is made for a specific purpose and the purpose
does no longer exist, also the assignment is no
longer valid. If an assignment is based on informa-
tion that turns out to be invalid so is the assign-
ment.
____________________________________________________
ripe-104++.txt Page 10
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
3. Address Space Assignment Procedures
3.1. Introduction
In this section, we describe the procedures to be
followed by local IRs when assigning address space
to their users. We start with a description of the
information to be gathered from the user. The pur-
pose of the information gathering is twofold. First,
the information is required to make address assign-
ment decisions, with respect to the aggregation and
conservation goals. Second, the information is
required for registration purposes.
We go on to describe how this information should be
evaluated to make appropriate assignments, and
introduce additional considerations that may be
essential in the assignment decision. Finally we
specify the procedures to be followed in the assign-
ment process.
Before going into the factors in the assignment pro-
cess, we start with some general background informa-
tion and policies that determine the information to
be gathered, and the procedures to be followed.
Address space is assigned by IRs to end users who
use it to operate the specific networks described in
an address space request. IRs guarantee that no
other end user will be assigned the same address
space during the validity of the assignment. An
assignment is valid as long as the criteria on which
it is based remain valid.
In accordance with the conservation goal, end users
are not permitted to reserve address space. Evalua-
tion of IP address space requests must be based on
the documentation provided for the following 24
months, as specified in the addressing plan and the
current address space usage described in the next
section. The amount of address space assigned must
be justified by this documentation. This means that
address space assigned in the past should be used to
meet the current request if possible. Once an orga-
nization has used its assigned address space, it can
request additional address space based on an updated
estimate of growth in its network.
____________________________________________________
ripe-104++.txt Page 11
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
3.2. Documentation
To make appropriate assignment decisions, informa-
tion must be gathered about the organization,
addressing requirements, network infrastructure,
current address space usage, and future plans of the
end user requesting address space. Some information
is essential to the assignment process, and is for-
mally required by the IR's. Other information is
very helpful in making assignment decisions, but is
not strictly required. The Local IR 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 a set of instructions to
fill them in. Although use of the forms provided
(or a local-language equivalent) is strongly encour-
aged, each local IR can obtain and manage this
information as it considers appropriate. Requests
requiring evaluation by the NCC must, however, be
submitted on a current version of the "IP Address
Space Request Form".
The information gathered in the assignment process
must be maintained permanently by the IR making the
assignment. It must be made available to the parent
registry immediately upon request. The IR is respon-
sible for protecting the end user's privacy. Aside
from the data specified in Section (database infor-
mation) below, which is published in the registry
database, the data gathered must be kept in strict
confidence. The IR is not authorized to provide the
information to anyone not representing the parent
registry.
In the subsections that follow, we outline the spe-
cific data to be gathered and the reasons for doing
so.
3.2.1. Required Information
The following set of information must be provided
with every request for an address assignment. The
data is essential both to properly assigning
addresses and to maintaining a global overview of
assignments. With the exception of the information
specified in Section (current address space usage),
all information refers to the currently requested
address space.
____________________________________________________
ripe-104++.txt Page 12
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
3.2.1.1. Overview of Organization
To properly assess the user's address space require-
ments, it is essential to understand the structure
of the organization to which the addresses are being
assigned, and which part of the organization will
make use of the addresses.
Consider the following situation. A bicycle manufac-
turer based in Belgium has a variety of departments.
Some, such as the Front Fork and Derailer depart-
ments, specialize in specific bike parts. Others,
such as the Sales and Development departments are
more general by nature. In such a company, the
departments Sales, Development, and Manufacturing
may fall directly under the top management, whereas
the subdepartments Derailer, Chain, Pedal, and Front
Fork fall under the Manufacturing department. If
someone submits a request for address space, we must
know which part of the organization will make use of
the assigned addresses. Suppose, for example, the
Manufacturing department is assigned address space
for use by all bike parts sub-departments. If
shortly thereafter, the Chain department requests
address space it is important that we know an
assignment has already been made to the organization
to meet the Chain department's needs. A similar
situation may occur if the Sales department has
groups of representatives in several countries. It
is essential to know if addresses being requested by
the central office will be used in Antwerp or in
Madrid. We want to prevent assignments being made
for the same subnet by two different parts of the
organization. In the case of a distributed sales
department, this must also be known to assure a
proper assignment with respect to aggregation.
The person responsible for making the assignment can
only be aware of this situation if an overview of
the organization, and the requester's role therein
is known. It is therefore important that a brief
overview of the organizational structure be pro-
vided. This should include details of the parent
company, subsidiaries and contact persons.
In the case of our bicycle manufacturer, one would
expect someone representing the Chain department to
produce general information about the structure of
the organization in Belgium, and contact persons for
the Manufacturing, Sales, and Development depart-
ments. We would not expect the same person to pre-
sent information on the structure within the Sales
____________________________________________________
ripe-104++.txt Page 13
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
department, such as who manages the office in Rome.
Clearly, the assignment process is greatly simpli-
fied if an organization coordinates its address
space management, and if all requests are made by a
single body representing the entire organization.
Contact Persons
To facilitate handling the request, contact informa-
tion is required for the person making the request
and for someone at the organization to which the
address space will be assigned. The information
should be entered on the Requester and User contact
templates, respectively. These templates contain
name, organization, country, phone, fax-no, and e-
mail fields. In each template, the appropriate per-
son's name should be specified in full. The organi-
zation refers to that in which this person works,
and the country refers to that in which the person's
office is located. The telephone and fax numbers
should include the country prefixes in the form
+code, and if the person can be reached by e-mail
from the Internet, the address should be specified.
The contact person information is only collected to
facilitate the address space request. It may or may
not include data for persons that will later be
entered in the RIPE database.
3.2.1.2. Current Assignment Space Usage
To meet the conservation goal in address space
assignments, one must have information regarding
address space assignments made to the user in the
past before new address space can be assigned. A
detailed description of how the address space is
currently being used is required. Using this infor-
mation, we can prevent assigning new address space,
where already assigned addresses can be employed to
meet the user's needs.
Each set of addresses already assigned to the orga-
nization must therefore be reported. The current use
of these addresses must be documented in a table
similar to that below. An entry must be included
for each physically separate subnet in the user's
network. Subnets are considered to be physically
separate if there is an IP router between them.
____________________________________________________
ripe-104++.txt Page 14
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
Each row in the table below contains an entry for a
subnet in the end user's organization.
Addresses Used
Prefix Subnet Mask Size Current 1yr 2yr Description
193.1.193.0 255.255.255.192 64 28 34 50 Derailer
193.1.193.64 255.255.255.224 32 10 12 15 Chain
193.1.193.96 255.255.255.224 32 8 13 17 Front Fork
193.1.193.128 128 Unused
193.1.194.0 255.255.255.0 256 132 170 210 Frame
193.1.195.0 255.255.254.0 512 317 350 380 Assembly
1024 495 579 672 Totals
Each entry in the table above is made up of the fol-
lowing fields which specify the current and pro-
jected use of the address space in the subnet. The
Description field is used to specify a short but
semantically meaningful description of the role of
the subnet in the user's organization. In our exam-
ple, we have descriptions corresponding to various
bike parts. Together with the size information,
this provides significant insight as to the network
structure in the organization.
The number of network interfaces currently used in
the subnet, along with the number expected to be
needed in the coming one and two years must also be
specified. These numbers are to be entered in the
Current, 1yr, and 2yr fields of the subnet entry,
and include the number of network interfaces to be
used, such as those for hosts, routers, gateways,
terminal concentrators, printers, and any other
machines requiring one or more network interfaces.
The Size field is used to specify the size of the
subnet, which determines the maximum number of net-
work interfaces that can be incorporated in the sub-
net. It must be a power of two, and of course should
be greater than or equal to the number specified in
the 2yr field. If it is smaller, this may be the
motivation for the address request, or it may be a
mistake in the requester's planning.
The Subnet Mask field is used to specify just that,
and finally, in the Prefix field, the position in
the assigned address space at which the addresses
for this subnet start is specified.
As in the example, entries should be made in the
____________________________________________________
ripe-104++.txt Page 15
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
table for assigned address space which is currently
not used.
3.2.1.3. Request Overview
The network overview is used to obtain a quick idea
about the scale of the request. This information
allows the IR processing the request to gain immedi-
ate insight as to the nature of the assignment
request. The exact information to be gathered is:
Size of Request To give the IR an immediate indica-
tion of the scale of the request, the total number
of Internet addresses being requested must be speci-
fied under request-size on the network overview
form. If the request-size is 512, the user speci-
fies a need for that number of Internet addresses.
Prior to the use of CIDR, the user would have asked
for two Class C networks. Because classless address-
ing is now used, the size of the request may be less
than 256 or fall between the class borders (e.g. 32,
288, 384).
Addresses to be Used To obtain an overview of the
structure of the requester's network, one must know
how many Internet addresses will actually be used at
different points in time. This corresponds to the
number of interfaces to the network, which often
will be slightly higher than the number of hosts.
In the network overview form, the fields addresses-
immediate, addresses-year-1, and addresses-year-2
are used to specify how many of the requested net-
work addresses will be used immediately following
the assignment, within 12 months, and within 24
months, respectively.
Number of Subnets In practice, the end user will
want to employ the requested addresses in one or
more subnets in an organization. The number of
physically separate subnets in which the requested
addresses will be used is an important factor in
making correct assignments. Together with the num-
ber of addresses to be used, this provides a global
picture of the requester's envisioned network
infrastructure. In the network overview form, the
fields subnets-immediate, subnets-year-1, and sub-
nets-year-2 are used to specify the number of sub-
nets in the requester's network plan to be
____________________________________________________
ripe-104++.txt Page 16
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
implemented immediately, within 12 months and within
24 months, respectively.
Internet Connection Prior to assigning address
space, it is essential to know if the end user
requesting IP addresses is already connected to the
Internet. If so, then the selection of appropriate
address space for this user may depend on which
provider(s) currently supplies connectivity. If the
user is not connected, but is planning to be, this
should also be taken into account. This information
is essential if the conservation and aggregation
goals of the public address space distribution are
to be met. The current and planned connectivity of
the user is specified in the inet-connect field of
the network overview form.
Country Finally, the country or countries in which
the addresses will be used must be specified using
the ISO 3166 two letter code. The country-net field
of the network overview form is reserved for this
purpose. If the ISO 3166 code is not known, the
full name of the country should be specified.
Private Address Space Using private addresses helps
to meet the conservation goal. For this reason,
users should always be informed that private
addresses might be a viable option. In particular,
private address space can be employed if not all
hosts require network layer access to the Internet.
Although users are not required to use private
address space even if it would satisfy their needs,
it is important that they have considered the possi-
bility. The private-considered field in the network
overview form should be checked after the requester
has indicated whether it is applicable for the
user's network.
Request Refused If a user's organization has had an
assignment request refused in the past, then it is
useful to know when and by which IR. Whatever the
case, it is useful to know if a request has been
refused, and why. This information should be speci-
fied in the request-refused field in the network
overview form.
PI Requested If provider independent address space
is requested by the user, special steps will have to
____________________________________________________
ripe-104++.txt Page 17
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
be taken by the local IR processing the request.
The PI-requested field in the network overview form
should be checked if this is a request for PI
address space.
3.2.1.4. Addressing Plan
To assess the suitability of assigning the requested
address space, an addressing plan is required. This
provides detailed information on the projected use
of the requested address space. Like the current
address space usage, the addressing plan is a table
in which every subnet is specified.
With few exceptions, the entries in the following
table are the same as those in the table of current
address space usage.
Relative Addresses Used
Prefix# Subnet Mask Size Immediate 1yr 2yr Description
0.0.0.0 255.255.255.192 64 8 16 30 Systems Group
0.0.0.64 255.255.255.224 32 17 22 26 Engineering
0.0.0.96 255.255.255.224 32 12 17 20 Manufacturing
0.0.0.128 255.255.255.224 32 10 15 20 Sales
0.0.0.160 255.255.255.240 16 5 9 12 Management
0.0.0.176 255.255.255.240 16 7 8 9 Finance
192 59 87 117 Totals
The number of network interfaces immediately
required in the subnet, along with the projected
need for the coming 12 and 24 months must be speci-
fied. These numbers are to be entered in the Immedi-
ate, 1yr, and 2yr fields of the subnet entry.
In the Relative Prefix field, we specify the rela-
tive position in the assigned address space at which
the addresses for this subnet will start. The rela-
tive position of the first subnet is always 0.0.0.0.
For each subsequent subnet, the start position is
selected to allow for the total number of hosts in
the Size fields of the subnets which precede it.
To conserve address space, the start positions of
the subnets should be selected to minimize padding
in the address space. In the example above, we
____________________________________________________
ripe-104++.txt Page 18
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
arrange the rows in decreasing order of the Size
field. This scheme can be applied in general to pre-
vent wasting address space between subnets. The
size of every valid request for address space will
be the sum of sizes of the subnets specified in the
addressing plan.
Current evaluation criteria assume that addressing
is classless. This means that all possible prefixes
of any length can be used. If there are technical
restrictions preventing the use of certain address
ranges or the choice of optimal subnet sizes, these
restrictions need to be explicitly documented. Doc-
umentation needs to include the precise nature of
the restriction, the make, model and version of the
hardware or software causing the restriction, and
its precise location in the network.
3.2.1.5. Database Information
For registration purposes, information is required
about the organization needing address space. Infor-
mation is also required about the persons involved
in the request and administration of the addresses.
request. Some of the information may be redundant
because the same person can play multiple roles.
However, every role can be filled by someone differ-
ent, so all information must be supplied in full.
The data specified below is to be gathered by the
local IR handling the assignment, and will be stored
in the registry database, at which point it becomes
publicly accessible.
Organization Some information about the organization
that will be using the addresses must be supplied
for maintenance of the RIPE database. The Network
Template is supplied for this purpose.
To help identify this assignment in the RIPE
database, a short, but semantically meaningful name
must be entered in the netname field. A short
description of the organization that will use the
assigned addresses is needed. The information is
specified using one or more descr fields in the Net-
work Template. If, for example, the assigned
addresses will be used by the Department of Neural
Surgery at Catatonic State University, then the
department and university names may be specified in
two descr fields. The ISO 3166 country code should
be specified in the country field. The full country
____________________________________________________
ripe-104++.txt Page 19
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
name can be used if the code is not known.
The admin-c and tech-c fields are used to specify
the IR handle (NIC handle) for the administrative
and technical contact persons, respectively. The
administrative person specified in the admin-c field
must be physically located at the site of the net-
work. The technical person specified in the tech-c
field may be a network support person located on
site, but could also be a consultant that maintains
the network for the organization. In both cases,
more than one person can be specified. The use of
NIC handles to specify each contact person is
required, as it assures each person has a unique
entry in the database. If the person doesn't have
an entry in the database, a unique NIC handle can be
acquired upon request.
Personal Data For every person involved in an
assignment request, we need a full set of personal
data. This data can only be omitted if up to date
information for the given person is already stored
in the RIPE database. If new data is provided for a
person with an entry in the database, it will be
viewed as an update upon submission, and overwrite
the current person data. Otherwise, the following
set of data must be specified in the Person Tem-
plate. The person's name should be specified in
full in the person field. The full postal address
is specified using multiple address fields. The
international telephone number which can be used to
reach the person at work must be entered in the
phone field, and the fax number should be entered in
the fax-no field. Of course, the NIC handle for this
person must be entered in the nic-hdl field to
uniquely identify this person in the database.
Submission Information
In both the Network Template and Person Template,
space is reserved to identify the person submitting
these entries to the registry database. The submit-
ter's e-mail address must be specified in the
changed field together with the date the template is
submitted.
Similarly, the source field is used to specify the
registry database where the requester information
can be found after an assignment is made. In this
____________________________________________________
ripe-104++.txt Page 20
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
case it will be RIPE, as the requester information
for this assignment will be stored in the RIPE
database.
3.2.2. Additional Information
In the assessment of an assignment request, the
additional information described below is always
useful. In some cases, IR's may require this data be
provided as part of the evaluation process.
Deployment Plan Suppose we are dealing with a new
corporation that wants to have access to the Inter-
net, and estimates an immediate need for 10,000
addresses. In such cases, a deployment plan may be
requested from the user. The plan should include a
list of events which will lead to the use of the
requested addresses, along with the dates that the
events will occur. This can be used to determine
how realistic the user is being, and if suitable to
phase the assignment process in according to the
user's plans.
Topological Map The old saying "a picture is worth a
thousand words" certainly holds in the case of net-
works. If a topological map of the current and
planned network infrastructure in the requesting
organization can be acquired, it can provide insight
on the network structure. Such maps are often avail-
able, and are quite useful when combined with the
addressing plan and current address space usage.
Special Circumstances Sometimes, due to the use of
old systems or special purpose hardware, the user is
unable to make use of assignments based on classless
addressing. If this is the case, information should
be gathered from the user as to the specific hard-
ware or software which presents a problem. Moreover,
it is useful to know how long the user will be using
the hardware or software which presents a problem.
Verification Information In working with a user who
hasn't had substantial network experience, it is
sometimes hard to determine whether the user's
request is based on a realistic plan. It can there-
fore be useful to request information which might
indicate the degree to which the user understands
network planning and management. First, one may ask
how accurate the user thinks the estimations in the
addressing plan are, and how they have been derived.
The corresponding name space plans provide another
____________________________________________________
ripe-104++.txt Page 21
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
indication of how well considered the user's plans
are.
3.3. Evaluation
Having collected the above information, we must now
determine a proper assignment with respect to the
conservation and aggregation goals stated in Section
1. Every request requires an individual evaluation
process that takes current assignment guidelines
into account.
Given the above documentation, one must determine if
IP addresses should be assigned, and if so, how many
and of what type. In the process, it is essential
that IR's work to prevent the stockpiling of address
space. The use of classless addressing will con-
tribute to the conservation of address space. Mean-
while, to enable proper routing, one must make
strategic decisions with regard to aggregation.
These concerns motivate the evaluation process out-
lined in this section.
Evaluation Steps
1. Current address space usage One should start by
comparing the current address space usage provided
by the requester with other information available to
the IR. After verifying the current address space
usage, one should check to see if the requested IP
addresses can be taken from those already assigned
to the user.
2. Network Overview Next, the size of the request,
specified in the Network Overview should be compared
with the number of addresses to be used immediately,
and within two years of the time the request is
made. Here we evaluate the utilization rates, that
is address space requested in relation to that to be
used. Unless there are special circumstances, imme-
diate utilization should be at least 25% of the
assigned address space, and the utilization rate one
year later should be at least 50%.
3. Private Address Space If private address space
might be suitable for this network, it must be
assured that the user is aware of this option and
has decided against it. Moreover users should be
aware that they will have more address space at
their disposal if they use private address space.
____________________________________________________
ripe-104++.txt Page 22
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
4. Very Small Enterprises (VSE's) An address space
user with a small number of hosts (currently <=32)
is referred to as a very small enterprise (VSE)
regardless of the size of the organization. Address
space for VSEs should be assigned in a classless
way. As with all address space requests, care
should be taken to avoid assigning more address
space than is required. See (Eidnes/deGroot) for
appropriate reverse delegation methods. VSEs that
do not intend to connect to the Internet should nor-
mally not be assigned PI space but referred to pri-
vate address space because the effort to renumber
into PA space at that point is normally minimal.
5. Addressing Plan In evaluating the addressing
plan, one should first check that the totals for the
number of addresses to be used immediately, in one
year, and in two years, correspond to those speci-
fied in the request overview. The validity of the
network masks should then be checked to see if they
are consistent with the size of the subnet. Some-
times address space can be saved by using different
subnet masks than specified by the user. If so, the
user should be requested to resubmit an addressing
plan with a more appropriate use of network masks.
In general, there should not be a large gap between
the number of addresses requested for a subnet
(size) and the number which will be used. This holds
even if the requester argues that network adminis-
tration will be greatly simplified by an addressing
scheme with lots of padding.
6. Additional Information If a deployment plan has
been provided, the addressing plan should be
reviewed to see if the two correspond. Likewise, one
should inspect the topology map if it is available
to see if it agrees with the addressing plan. Any
information gathered which can be used to check the
validity of the current address space usage and
addressing plans should be employed to do so.
7. Address Reservations 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. Such reservations are generally
fruitless because they turn out to be unnecessary or
insufficient for the user's needs.
8. Static Dialup Due to constraints on the available
free pool of IPv4 address space, the use of static
____________________________________________________
ripe-104++.txt Page 23
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
IP address assignments (e.g., one address per cus-
tomer) for dial-up users is strongly discouraged.
While it is understood that the use of static
addressing may ease some aspects of administration,
the current rate of consumption of the remaining
unassigned IPv4 address space does not permit the
assignment of addresses for administrative ease.
Organizations considering the use of static IP
address assignment are expected to investigate and
implement dynamic assignment technologies whenever
possible. If allocations for this purpose are
indeed made, special allocation and verificatin pro-
cedures apply. Please contact the RIPE NCC for
details.
9. Virtual Hosts Sometimes a single host is assigned
more than one IP address on the same interface and
physical network. Often this is used to circumvent
shortcomings in higher level protocols such as HTTP.
Large scale assignments for this purpose are dis-
couraged for the reasons mentioned in the paragraph
above. If allocations or assignments for this pur-
pose are indeed made, special allocation and verifi-
catin procedures apply. Please contact the RIPE NCC
for details.
3.4. Assignment Procedures
We now describe the specific procedures to be fol-
lowed in assigning address space. In the following,
we assume that the required information has been
gathered, and evaluated as outlined in the previous
subsections. The procedures described in this sub-
section lead to the assignment of specific address
space for the request under consideration.
3.4.1. Assignments within Allocations
Once an IR has assured that the address space
request merits the assignment of k addresses, the
actual set of addresses to be assigned must be
selected. If the addresses are to be assigned from
a range of address space allocated to the local IR
making the assignment, then care must be taken to
prevent fragmentation of the allocated space.
Specifically, each set of address space assigned
should start on a CIDR (bit) boundaries. This means
the start address for each set of assigned range
must be divisible by the size of the block to be
assigned. This helps to achieve the aggregation
____________________________________________________
ripe-104++.txt Page 24
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
goal in address space assignments.
Suppose a request can be satisfied with a number
small chunks of address space rather than one large
one. For example, if 384 addresses are sufficient
to satisfy a request, but no more than 256 will be
used in a single physical subnet, then the user can
be assigned a /24 and a /25 rather than a /23, which
results in saving a /25 for another user. Local IRs
are encouraged to assign multiple range of address
space, rather than a single range in accordance with
the conservation goal. Of course the effort to do so
should increase as the amount of address space that
can be saved in doing so increases.
Local IRs are always welcome to request advice from
the RIPE NCC in making assignment decisions. In some
cases, however, an assignment must be approved by
the RIPE NCC even if it is made from a block of
address space allocated to the local IR making the
assignment. In particular, if the size of the
assignment is larger than the local IR is permitted
to make, it must be approved by the RIPE NCC in
advance. The size of assignments a local IR is per-
mitted to make without prior approval is determined
by the local IR's assignment window, discussed in
Section (Assignment Window).
If the addresses are to be assigned from a block not
allocated to the local IR, the selection will be
made by the IR to which the the address space is
allocated. In general, this will be the regional IR.
3.4.2. PA vs PI Space
The criteria used to determine the amount of address
space and the registration requirements are identi-
cal for PA and PI address space. For example,
regardless of whether the assignment is for PA or PI
address space, an assignment with a prefix longer
than /24 can be made if the request can be satisfied
with less than 256 addresses.
Local IRs must make it clear to the user which type
of address space is assigned. Clear contractual
arrangements which specify the duration of the
address space assignment are mandatory for every
assignment of PA address space. Although not
strictly required, it is strongly recommended that
contractual arrangements are made when assigning PI
space as well.
____________________________________________________
ripe-104++.txt Page 25
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
With respect to aggregation, the clear advantages of
assigning PA space mandate that IRs recommend its
use whenever possible. End users should therefore
be advised to use PA space if it appears to be suf-
ficient for their situation.
The consequences of using PA or PI space must always
be made clear to the end user. In particular, to be
certain end users understand the consequences of
using PA space, the assigning IR must give each user
requesting PA space a warning similar to the follow-
ing:
Assignment of this address space is valid
as long as the criteria for the original
assignment are still met and only for the
duration of the service agreement between
yourself and ISP XXXX. ISP XXXX has the
right to re-assign the address space to
another user upon termination of the
agreement or following an agreed period
thereafter. If the address space assign-
ment becomes invalid, you may have to re-
configure the addresses of all equipment
using this address space. The reconfigura-
tion is only necessary if you continue to
require global uniqueness of the addresses
for that equipment. It is important to
realize that some Internet services do not
require globally unique addresses. For
example, services that can be accessed
through a NAT (network address translator)
or through an application layer gate-
way/firewall don't require the machines
which access them to have globally unique
addresses.
Of course, the consequences of using PI space must
also be made clear to the end user. This is accom-
plished by giving each user requesting PI space a
warning similar to the following:
Assignment of this address space is valid
as long as the criteria for the original
assignment are met. Note that the assign-
ment of PI address space does not imply
that it will be routable on any part of
the Internet. Users may have to pay a pre-
mium for routing of PI addresses (as
opposed to PA addresses). Eventually, it
____________________________________________________
ripe-104++.txt Page 26
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
may become impossible to get relatively
small amounts of PI space routed on most
of the Internet. We strongly suggest you
contact any prospective service providers
for information regarding the possibility
and pricing of service when using PI
addresses.
The type of assigned address space must be regis-
tered in the status attribute of the inetnum object
in the RIPE database by the assigning IR. The pos-
sible 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, IRs are encouraged
to mark past assignments in the registry database
with PA or PI as appropriate. Any assigned address
space without an explicit type in the status
attribute is assumed to be PI space. Priority
should therefore be given to marking PA space as
such.
In general, local IRs are provided with ranges of PA
space from which they can make assignments. If an
end user requests address space of a type which an
IR does not assign (typically PI), the IR must refer
the end user to a registry which can fulfill the
request. IRs that do not assign PI space must sup-
port an IR that does provide this service. This
includes aiding the end user in the preparation of a
properly documented request and furnishing back-
ground information to the assigning IR.
Local IRs which do not normally assign large amounts
of a particular type of address space do not need to
hold an allocation of that type of address space.
It can be acquired from the RIPE NCC as needed. In
general, such assignments will not be aggregatable
with other address space assigned by the local IR.
____________________________________________________
ripe-104++.txt Page 27
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
IRs have assigned address space in the past which is
aggregated in practice but is not formally of type
PA. Formally, address space is not of type PA unless
there are contractual agreements regarding the
assignment's termination. It is therefore recom-
mended that IRs ask end users to release non-PA
address space upon termination of service. Simi-
larly, if an end user moves to a new IR to obtain
Internet services, the new IR should encourage the
user to release any non-PA address space they hold,
and to request a new assignment (a process which the
new IR should be more than happy to support). To
minimize the use of non-PA space in the future, IRs
should work to make contractual arrangements to con-
vert aggregated address space to formal PA address
space.
3.4.3. Multihomed Users
An end user may have reason to obtain connectivity
through more than one service provider. If so, it
may be necessary to obtain address space assignments
from more than one IR to support different parts of
the user's network. In general, there is no problem
with users acquiring address space and service from
more than one IR. Such users are referred to as mul-
tihomed.
Because users can be multihomed, IRs must be espe-
cially careful in reviewing address space requests,
and the corresponding current address space usage
described in Section (Current Assignment Space
Usage). One must be sure that users are not acquir-
ing multiple assignments for the same purpose from
different IRs. Moreover, one must check that a sim-
ilar address space request has not been refused by
another IR for some valid reason.
3.4.4. Update the RIPE Database
Registration of objects pertaining to an assignment
in the RIPE database makes it possible to track the
use of address space, facilitate operational con-
tacts, and facilitate studies of address allocation.
These activities are essential to effective mainte-
nance of the Internet.
Submission of objects to the database is the final
step in making an assignment. This step makes the
assignment definite, and makes public information
regarding the assignment available to anyone seeking
____________________________________________________
ripe-104++.txt Page 28
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
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 user's organiza-
tion in the Network Template (see Section (Database
Information)), should be entered in 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 organization is assigned a /22 address set for
1024 network addresses, the range will be something
like: 193.1.192.0 - 193.1.195.255. And, as stated
above, the status field of the inetnum object is
used to specify whether the assigned addresses are
PI or PA.
In addition to the inetnum object, a person object
must be submitted for each of the people specified
in the tech-c and admin-c fields of the inetnum
object.
Assuming the assigning IR has properly stored infor-
mation gathered in the assignment process for future
reference, submission of the objects described above
completes the assignment process. The IR can now
provide the end user with the assigned address range
and any other data relevant to its use.
3.5. Assignment Window
It is essential that local IR staff follow the pro-
cedures for address space assignments and apply the
evaluation criteria used to determine assignment
sizes as discussed above. The procedures are
straightforward. The evaluation criteria however,
can be difficult to apply to new situations.
To assure the conservation, aggregation, and regis-
tration goals are met, we must be sure the assign-
ment criteria and procedures are properly applied.
In general, this means that local IRs with little or
no experience should receive maximal support in the
assignment process, whereas local IRs with more
experience should be allowed to make most assign-
ments without consulting the RIPE NCC. Large assign-
ments always require prior approval because of their
impact on the available address space.
To achieve this variation in support level, each
local IR is given an assignment window by the RIPE
NCC. The assignment window is the maximum number of
____________________________________________________
ripe-104++.txt Page 29
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
addresses that can be assigned by the local IR to an
end user without prior approval by the RIPE NCC. The
number of addresses is always expressed in /xx nota-
tion, so a local IR with an assignment window of /23
is allowed to assign up to 512 addresses to an end
user without prior approval of the RIPE NCC. As the
local IR staff gain experience, the window size is
increased.
Every assignment of address space which is larger
than the local IR's assignment window is invalid
prior to explicit approval by the RIPE NCC. Without
such approval, the address space should not be used
to address hosts with Internet connectivity. Use of
invalid address can result in a failure to meet the
uniqueness requirement for Internet addresses.
The assignment window is not only applied to indi-
vidual assignments, but to multiple assignments to
the same end user in a single year. If an local IR
makes combined assignments to an organization in the
course of a year, the total amount of address space
assigned may not exceed the local IR's assignment
window. Additional address space can only be
assigned to that organization after approval by the
RIPE NCC.
In general the assignment window for new registries
is 0. This means that every assignment requires
prior approval by the RIPE NCC before becoming
effective. This ensures that the local IR staff
become familiar with the evaluation criteria and
assignment procedures described in this document.
As the local IR staff become familiar with assign-
ment procedures, the assignment window can be
raised. In general, it will be raised to /24 the
first time, which means the local IR staff can make
assignments for up to 256 addresses. If the RIPE
NCC receives a request to raise the assignment win-
dow for a local IR, it will be evaluated based on
the proficiency of the local IR staff. 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 local IR with handling larger assignments.
Currently, the maximum size of the assignment window
for any local IR is 4096 addresses (/20). This means
that every assignment for more than this requires
approval of the RIPE NCC.
____________________________________________________
ripe-104++.txt Page 30
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
Sometimes new registration staff at a well estab-
lished local IR 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 assignment window for the local IR may be
decreased to prevent the staff from making erroneous
assignments involving a substantial amount of
address space. As the new staff members receive
training, and the proficiency level is again up to
par, the assignment window can be increased just as
it would be for a new local IR.
____________________________________________________
ripe-104++.txt Page 31
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
4. Rules and Guidelines for Allocations
In the previous section, we described the procedures
for handling requests for address space, including
the selection of a set of addresses for an end user.
In completing the assignment, address space is
selected from a range that has been allocated to the
local IR for this purpose. Of course, before a
local IR can select addresses to fulfill a request,
it must have a range of address space to choose
from. (If the local IR does not have sufficient
address space of the type to be assigned, then a
request can be submitted to the RIPE NCC.)
To meet this need, a range of addresses is made
available to a local IR by the RIPE NCC. Such an
address range is referred to as an allocation. In
Europe, the RIPE NCC is the only IR permitted to
allocate address space. A local IR is not allowed to
re-allocate part of its allocation to any other
organization. Moreover, without prior approval by
the NCC, local IRs are not permitted to exchange
allocated address space among themselves.
In some cases, a local IR acts as a transit provider
for an IP service provider which itself is not a
local IR. If a local IR allows another IP service
provider to make an assignment from its allocated
address space, the local IR is still responsible to
guarantee the assignment is made according to the
guidelines specified in this document.
If at some point, an IP service provider decides to
become a local IR rather than using an existing
local IR to obtain address space, then all subse-
quent assignments it makes should be from address
space allocated directly to it from the RIPE NCC.
Furthermore, address space already assigned by the
IP provider from transit providers' allocations
should be returned to the transit provider, and new
assignments should be made to the end users from the
new allocation.
In this section, we describe how a local IR can
obtain an allocation and how allocated address space
should be managed.
4.1. Slow Start of Allocations
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
____________________________________________________
ripe-104++.txt Page 32
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
idea is to allocate address space to local IRs at
the rate it will be assigned. The minimum allocation
is /19 (8192 addresses). The maximum size of an
individual allocation is /16 (65536 addresses). The
size of allocations is based solely on the rate that
previously allocated address space has been assigned
to end users. It will be increased or decreased
depending on the rate at which a local IR assigns
its space.
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 the previ-
ous section, 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 demon-
strated proficiency of the registry staff in evalu-
ating requests and processing 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
set at the minimum.
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 the previous sec-
tion, 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, or if a single request requires a
larger block of addresses than can be satisfied with
the currently 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
____________________________________________________
ripe-104++.txt Page 33
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
with assignments registered in the database and may
request further information to determine the need
for a new allocation. Additional address space will
be allocated after the information delivered with
the request has been verified, and a new allocation
has been deemed necessary.
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.
4.4. Allocation Registration
Allocations are registered in the RIPE Database by
the NCC using inetnum objects. Information about
the local IR, which is similar to that for an end
user receiving an assignment is stored together with
the range of allocated address space and its type.
The range of addresses is stored in the inetnum
field in dotted quad notation, and the 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 IR,
and all assignments made from it are provider
aggregatable. This is the most common alloca-
tion type for local IRs.
ALLOCATED PI
This address space has been allocated to an IR,
and all assignments made from it are provider
independent.
ALLOCATED UNSPECIFIED
This address space has been allocated to an IR,
and assignments made from it may be either
provider aggregatable or provider independent.
____________________________________________________
ripe-104++.txt Page 34
European IR - Policies and Procedures - Version 0.1
Orange, Kuehne, Karrenberg
____________________________________________________
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 authorization is implemented, autho-
rization can be implemented for creation of inetnum
objects "under" the allocation objects.
____________________________________________________
ripe-104++.txt Page 35
