European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
European Internet Registry
Policies and Procedures
S. Dolderer
D. Karrenberg
M. Kuehne
M. Norris
C. Orange
W. Woeber
J. Zsako
Document ID: ripe-136
Obsoletes: ripe-104, ripe-105
ABSTRACT
The distribution of IP address space
follows the hierarchical scheme described
in [Gerich93a]. For Europe and parts of
the surrounding area address space is
allocated 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 docu-
ment, we describe the policies and proce-
dures associated with address space man-
agement that must be followed by local
IRs. Moreover, we present a number of ser-
vices available to local IRs to simplify
the tasks associated 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
____________________________________________________
ripe-136.txt Page 1
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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 docu-
ment 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.
Section 3 (Address Space Assignment Procedures)
describes the procedures to be followed by European
IP registries 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.
We conclude with a glossary in which the key terms
used in this document are defined.
____________________________________________________
ripe-136.txt Page 2
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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 in
Section 2.2. The main purpose of this address
space is to allow communication using IPv4 over
the Internet. A secondary purpose is to allow
communication using IPv4 over interconnected
private internets. One can currently distin-
guish two kinds of public addresses: provider
independent (PI) and provider aggregatable (PA)
addresses; see Section 2.4 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
[96a].
Special and Reserved Addresses
There are a number of address ranges reserved
for applications like multicasting. These are
described elsewhere (cf [Deering89a]) and are
beyond the scope of this document.
____________________________________________________
ripe-136.txt Page 3
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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 these goals are pursued. It is worth
noting that "Conservation" and "Aggregation" are
____________________________________________________
ripe-136.txt Page 4
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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-136.txt Page 5
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
2.3. The Internet Registry System
The Internet Registry system has been established to
achieve the goals stated in Section 2.2. It con-
sists of hierarchically organized Internet Reg-
istries (IRs). Address space is typically assigned
to end users by local IRs. The address space
assigned is taken from that allocated to the local
IR by the regional IR. End users are those organi-
zations operating networks in which the address
space is used. 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 con-
servation 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-136.txt Page 6
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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-136.txt Page 7
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
For Europe, the Internet Registry System hierarchy
consists of the following entities (from the top
down): IANA, the RIPE NCC, and local IRs.
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 a new address space assign-
ment, and return the previously assigned address
space. To ensure the address space is properly
returned, a clear, preferably contractual, under-
standing is needed between the local IR 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.
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
____________________________________________________
ripe-136.txt Page 8
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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-
ment 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.
____________________________________________________
ripe-136.txt Page 9
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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
organisation has used its assigned address space, it
can request additional address space based on an
updated estimate of growth in its network.
____________________________________________________
ripe-136.txt Page 10
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
3.2. Documentation
To make appropriate assignment decisions, informa-
tion must be gathered about the organisation,
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 "European IP
Address Space Request Form" (e.g. ripe-137:
[Caslav96a]).
The information gathered in the assignment process
must be maintained permanently by the IR making the
assignment, and must be made available to the
regional registry immediately upon request. The IR
is responsible for protecting the end user's pri-
vacy. Aside from the data specified in Section
3.2.1.5, which is published in the registry
database, the information gathered must be kept in
strict confidence. The IR is not authorised to pro-
vide the information to anyone not representing IANA
or a regional registry, unless explicitly requested
to do so by the end-user.
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 3.2.1.2, all information refers
____________________________________________________
ripe-136.txt Page 11
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
to the currently requested address space.
3.2.1.1. Overview of Organisation
To properly assess the user's address space require-
ments, it is essential to understand the structure
of the organisation to which the addresses are being
assigned, and which part of the organisation 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, specialise 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 organisation 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 organisation
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
organisation. 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 organisation, and the requester's role therein
is known. It is therefore important that a brief
overview of the organisational 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 organisation in Belgium, and contact persons for
____________________________________________________
ripe-136.txt Page 12
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
the Manufacturing, Sales, and Development depart-
ments. We would not expect the same person to pre-
sent information on the structure within the Sales
department, such as who manages the office in Rome.
Clearly, the assignment process is greatly simpli-
fied if an organisation coordinates its address
space management, and if all requests are made by a
single body representing the entire organisation.
Contact Persons
To facilitate handling the request, contact informa-
tion is required for the person making the request
and for someone at the organisation 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, organisation, country, phone, fax-no, and e-
mail fields. In each template, the appropriate per-
son's name should be specified in full. The organi-
sation 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 organ-
isation 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
____________________________________________________
ripe-136.txt Page 13
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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.
Each row in the table below contains an entry for a
subnet in the end user's organisation.
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 organisation. 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 organisation.
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
____________________________________________________
ripe-136.txt Page 14
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
for this subnet start is specified.
As in the example, entries should be made in the
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 organisation. 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
____________________________________________________
ripe-136.txt Page 15
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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 imple-
mented 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 organisation 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.
____________________________________________________
ripe-136.txt Page 16
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
PI Requested If provider independent address space
is requested by the user, special steps will have to
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
____________________________________________________
ripe-136.txt Page 17
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
the subnets should be selected to minimise padding
in the address space. In the example above, we
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 organisation needing address space. Infor-
mation is also required about the persons involved
in the request and administration of the addresses.
Some of the information may be redundant because the
same person can play multiple roles. However, every
role can be filled by someone different, 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 pub-
licly accessible.
Organisation Some information about the organisation
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 organisation 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
____________________________________________________
ripe-136.txt Page 18
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
two descr fields. The ISO 3166 country code should
be specified in the country field. The full country
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 organisation. 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
____________________________________________________
ripe-136.txt Page 19
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
registry database where the requester information
can be found after an assignment is made. In this
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 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
organisation 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
____________________________________________________
ripe-136.txt Page 20
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
addressing plan are, and how they have been derived.
The corresponding name space plans provide another
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
whether 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 contribute to the conservation of address
space. Meanwhile, 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 utilisation rates, that
is address space requested in relation to that to be
used. Unless there are special circumstances, imme-
diate utilisation should be at least 25% of the
assigned address space, and the utilisation 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
established 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
____________________________________________________
ripe-136.txt Page 21
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
their disposal if they use private address space.
4. Very Small Enterprises (VSE's) An end user with a
small number of hosts (currently <=32) is referred
to as a very small enterprise (VSE) regardless of
the size of the organisation. 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.
VSEs that do not intend to connect to the Internet
should not be assigned public address space but
rather should be advised to use private address
space. This is especially the case for VSEs that
request PI space so they can easily arrange connec-
tivity at a later date. These enterprises should be
advised that for VSEs in general, the effort
required to renumber at a later date is 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.
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
____________________________________________________
ripe-136.txt Page 22
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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
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.
Organisations 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 verification
procedures 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-
cation 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 some amount of
address space, 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 allo-
cated space. Specifically, each set of address
____________________________________________________
ripe-136.txt Page 23
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
space assigned should start on a CIDR (bit) bound-
ary. This means the start address for each range of
addresses to be assigned must be divisible by the
size of the range. This helps to achieve the aggre-
gation goal in address space assignments.
Suppose a request can be satisfied with either a
number of small chunks of address space or with a
single 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. In accordance with the conservation goal,
local IRs are encouraged to assign multiple ranges
of addresses in such cases, rather than a single
large range. 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 3.6.
If the addresses are to be assigned from a range
which has not allocated to the local IR, the selec-
tion will be made by the IR to which the address
space has been allocated. In general, this will be
the regional registry.
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
____________________________________________________
ripe-136.txt Page 24
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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.
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
sure that 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
realise 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
____________________________________________________
ripe-136.txt Page 25
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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
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. If a local IR wants to assist one of its
customers in obtaining an assignment of address
space for which it does not hold an allocation, it
should support an IR that does provide this service.
This includes aiding the end user in the preparation
of a properly documented request and in furnishing
background information to the assigning IR as
____________________________________________________
ripe-136.txt Page 26
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
required. The local IR can of course refer the user
to a local IR which is able to make the assignment.
Local IRs which do not normally assign large amounts
of a given type of address space (again typically
PI) need not hold an allocation to handle address
space requests. The address space can be acquired
from the RIPE NCC as needed. In general, such
assignments are not aggregatable.
3.5. Replacing IP Addresses
Much of the address space assigned in the past is
aggregated in practice but formally is not of type
PA. Formally, address space is not of type PA unless
there are contractual agreements regarding the
assignment's purpose and term of validity. It is
therefore recommended that IRs ask end users to
release non-PA address space upon termination of
service. Similarly, 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 with which the new IR should be more than
happy to help). To minimise the use of non-PA space
in the future, IRs should work to make contractual
arrangements to formally convert aggregated address
space to PA address space.
While the procedures for numbering and renumbering
hosts in an IP network are becoming less trouble-
some, asking or forcing end users to renumber is
sometimes problematic. The renumbering process usu-
ally requires a considerable amount of time and
effort both on the part of the end users and on the
part of the ISPs and local IRs involved. In some
cases, there is a clear obligation to replace
address space assignments, and local IRs should be
prepared to support their customers in the process.
A more general and very important case is the (vol-
untary) replacement of PI address space which for
historical reasons has been randomly assigned and
cannot be aggregated with other PA assignments.
Such replacements can play a key role in containing
the growth of routing tables, and thus for the main-
tainability of the Internet as a whole. Because the
renumbering process is nontrivial, the Internet Reg-
istry System as a whole must support the process as
far as possible.
During the period in which end users migrate indi-
vidual services or parts of their networks to the
____________________________________________________
ripe-136.txt Page 27
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
new address space, complications may arise. In many
cases, they may need to be connected to more than
one ISP for the duration of the transition period,
and sometimes addresses from both the old range(s)
and the new might have to be managed and used in
parallel. With the goals of aggregation and conser-
vation in mind, as well as to minimise duplicate
logistics, this period should be kept as short as
possible.
IP Address Space Replacement Procedures:
In general, address space should be replaced on a
one-to-one basis. An assignment of PA space to
replace previously assigned PI space can be made if
the original assignment criteria are still met and
if the address space to be replaced is currently
used for the end user's network.
Only if a large percentage of the original assign-
ment is not in use (50% or more than 4096 addresses)
will an end user be required to submit the usual
documentation to the new registry. This part of the
request is then treated like any other request for
assignment of additional addresses.
The address space to be replaced (the individual
address ranges and the total size) must be properly
documented with the standard IP address space
assignment request forms. For address space that
was allocated by local IRs established within the
framework of the RIPE NCC, a copy of the documenta-
tion is forwarded to the registry or registries that
assigned the address space being replaced. Before
assigning the new address space, an agreement
(preferably contractual) should be reached regarding
the maximum period within which the previously
assigned addresses will be returned to the original
registry or to the regional registry for eventual
reassignment.
Whenever a large amount of addresses are to be
replaced (the equivalent of a /20 or more) the
regional IR must be informed about the intended
replacement and the agreements on the maximum period
of parallel assignments. In complex cases, the
regional IR may decide to provide guidance in the
process of managing the address space replacement.
In general a period of 3 months should be allowed
for the end user to complete the transition to the
new addresses. For exceptional cases, where the end
____________________________________________________
ripe-136.txt Page 28
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
user requests to keep both assignments for more than
6 months, approval should be obtained for the pro-
posed time frame from the RIPE NCC.
For those addresses that have not been assigned by a
local IR, or which were assigned by an IR that has
since closed, the regional IR will act in lieu of
the original registry.
3.5.1. 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. Their networks are then referred
to as multihomed.
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 3.2.1.2. One must be sure that
users are not acquiring multiple assignments for the
same purpose from different IRs. Moreover, one must
check that a similar address space request has not
been refused by another IR for some valid reason.
3.5.2. 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
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 user's organisa-
tion in the Network Template (see Section 3.2.1.5)
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
____________________________________________________
ripe-136.txt Page 29
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
dotted quad notation. For example, if an organisa-
tion 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.
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.
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.6. 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
addresses that can be assigned by the local IR to an
end user without prior approval by the RIPE NCC.
This is expressed in /nn notation. Therefore, a
local IR with an assignment window of /23 is allowed
to assign up to and including 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.
____________________________________________________
ripe-136.txt Page 30
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
Every assignment of address space which is larger
than the local IR's assignment window is formally
invalid until explicit approval is acquired from the
RIPE NCC. Without this approval, the address space
can not be used as it may result in a failure to
meet the uniqueness requirement for Internet
addresses at a later date.
The assignment window is not only applied to indi-
vidual assignments, but to multiple assignments to
the same end user in a 12 month period If a local IR
makes more than one assignment to an organisation in
any 12 month period, the total amount of address
space assigned may not exceed the local IR's assign-
ment window. Additional address space can only be
assigned to that organisation 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.
As the local IR staff become familiar with assign-
ment procedures, the assignment window can be
raised. In general, it will first be raised to /24.
At this point, the local IR staff can make assign-
ments for up to and including 256 addresses without
prior approval from the RIPE NCC. If the RIPE NCC
receives a request to raise the assignment window
for a local IR, it will be evaluated based on the
proficiency of the local IR staff. This is deter-
mined based on whether assignment documentation pre-
sented 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 a /19. Therefore, every assign-
ment involving more than 8192 addresses requires the
approval of the RIPE NCC.
An established local IR 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 registry staff the training is not per-
formed sufficiently, and new staff members of a well
established local IR may make errors both in judge-
ment and procedure before they are properly trained
to make assignments. If such errors are noticed by
the RIPE NCC, the local IR will be notified, and if
____________________________________________________
ripe-136.txt Page 31
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
it happens repeatedly, the assignment window for the
local IR may be decreased to prevent the new staff
members from making erroneous assignments involving
large amounts of address space. The assignment win-
dow can again be increased based on the criteria
stated above.
____________________________________________________
ripe-136.txt Page 32
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
4. Rules and Guidelines for Allocations
In Section 3, we described the procedures for han-
dling requests for address space, including the pro-
cess used to determine which addresses should be
assigned to an end user. In most cases, the address
space will be 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 for an (additional) allocation 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
organisation. 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 makes address space
assignments for the customers of another IP service
provider which itself does not operate a local IR.
The local IR is of course responsible for all
assignments from its allocation, even if there is an
agreed involvement of staff from the other IP ser-
vice provider. Whereas staff of the other IP ser-
vice provider can and should be involved in process-
ing the end user's request, local agreements about
shared responsibility in the registration process
are not recognised by the regional registry and are
strongly discouraged.
If at some point, an IP service provider decides to
establish 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 to it from the RIPE NCC. Further-
more, any address space used by the ISP's customers
which was acquired from a transit provider's alloca-
tions should be returned to the transit provider as
soon as possible, and new assignments should be made
to the end users from the ISP's allocated address
space.
In the following subsections, we describe how a
local IR can obtain an allocation and how allocated
address space should be managed.
____________________________________________________
ripe-136.txt Page 33
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
4.1. The Slow Start Mechanism
To prevent allocating large blocks of address space
that won't be assigned, the RIPE NCC has introduced
the concept of a slow start for allocations. The
idea is to allocate address space to local IRs at
the rate it will be assigned. The minimum size of an
individual address space allocation is /19 (8192
addresses), and the maximum size is /16 (65536
addresses). The size of an allocation to a particu-
lar local IR is based solely on the rate that the IR
has assigned previously allocated address space to
end users.
The slow start mechanism implements a consistent and
fair policy for every local IR with respect to allo-
cations. Although the mechanism is similar to the
assignment window mechanism described in Section
3.6, the policy it implements is different. The
size of further allocations depends exclusively on
the assignment rate of the local IR concerned while
the assignment window depends on the proficiency of
the registry staff in evaluating requests and pro-
cessing assignments.
4.2. First Allocation
When a new local IR starts up, it has no address
space allocated to it. The first allocation will be
made automatically by the RIPE NCC, generally upon
receipt of the first assignment request from the
local IR. Because there is no information about the
rate at which a new IR will make address assign-
ments, the size of the first allocation is always a
/19 (8092 addresses).
Remember that the amount of space allocated does not
determine the size of assignments a local IR can
make. As discussed at the end of Section 3, a new
local IR must have every assignment approved by the
RIPE NCC until its assignment window is increased.
4.3. Further Allocations
A local IR can obtain additional allocations as
required. A request should be submitted to the RIPE
NCC when the currently allocated address space is
nearly used up, or if a single assignment will
require a larger set of addresses than can be satis-
fied with the allocated address space. To obtain a
new allocation, a local IR should submit a request
____________________________________________________
ripe-136.txt Page 34
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
to the RIPE NCC which includes a complete list of
the assignments made from all of their allocations.
The RIPE NCC will check this information, compare it
with assignments registered in the database and may
request further information to determine the need
for a new allocation. Additional address space will
be allocated after the information supplied 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,
____________________________________________________
ripe-136.txt Page 35
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
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, authori-
sation can be used for the creation of inetnum
objects "under" the allocation objects.
____________________________________________________
ripe-136.txt Page 36
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
5. DNS and Reverse Address Mapping
Applications such as ftp, e-mail, and telnet allow
users to specify an Internet host as a domain name,
such as "ns.ripe.net". With this notation, the full
name of a host is determined in a hierarchical fash-
ion. In this example, net is one of the top level
domains in the system, ripe is the name of a subdo-
main defined in the net domain, and ns is the name
of a host in the "ripe.net" domain. This hierarchy
is similar to the UNIX file system, and it enables
unique naming of hosts on the Internet.
Before an application can send IP packets to a given
destination, however, its IP address must be deter-
mined. The Domain Name System (DNS) is a dis-
tributed hierarchical directory service which makes
it possible to obtain the IP address for a host
given its symbolic name specified in the domain name
notation described above. The inverse procedure
which produces the domain name from the IP address
is called reverse address mapping, and is the focus
of this section.
We begin with a brief introduction to the DNS
because reverse address mapping is simply a specific
application thereof. Detailed information on the
DNS can be found in [Albitz94a]. In this section, we
aim to provide a sufficient basis to understand the
procedures involved in making reverse address map-
ping possible for address space allocated by the
RIPE NCC.
5.1. Forward Name Mapping
The DNS is a client/server system. If data is prop-
erly administered on the domain name servers, then
every public IP address in use has exactly one
domain name associated with it. The IP address which
corresponds to a given domain name can be extracted
with a resolver, which works as follows. If a
machine needs the IP address for a host identified
by its symbolic name, and it cannot be obtained
locally, the resolver is used, first to inspect the
domain name, and then to determine what name server
should be able to provide the IP address that corre-
sponds to it. The resolver then sends a request to
the appropriate name server which either returns the
required IP address, or the address of a server that
should be able to provide more details. If the lat-
ter, the resolver repeats its request to the new
server. This continues until the IP address is found
____________________________________________________
ripe-136.txt Page 37
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
(or the host is reported to be unknown). This pro-
cedure is called forward mapping or resolution.
Of course, before a host can be identified with the
DNS, it must be registered with a server. The
responsibility for name registration is hierarchi-
cal. The administration of a subset of the DNS name
space is delegated to a representative of an organi-
sation by the party which holds responsibility for
the name space it falls under. In the example above,
the administration of the top level domain net is
performed by the InterNIC. The InterNIC delegated
the subdomain ripe to a representative of the RIPE
NCC, who chose to use the name ns to refer to one of
the hosts in its network. After the name ns has
been properly specified in the name server for
ripe.net, the domain name ns.ripe.net can be used to
find the Internet host with IP number 193.0.0.193.
The suffix of each domain name corresponds to a top
level domain (TLD) in DNS, and authority to adminis-
ter it is delegated by IANA. Generally, this will
be an ISO 3166 two letter country code such as "nl"
for The Netherlands, "fr" for France, or "us" for
the United States. These codes have been delegated
by IANA as country specific TLDs. (The only excep-
tion is the domain ".uk" which has been delegated to
Great Britain; "gb" is in fact the ISO code.) The
administration of each country specific TLD is dele-
gated to a representative residing in the country.
If responsibility for a country specific TLD has yet
to be delegated, then a resident can request permis-
sion from IANA to manage it. Responsibility for the
TLD will be delegated to that person if the guide-
lines specified in [Postel94a] are agreed to and if
no objections are made within some short period
after the possible delegation is announced.
When the DNS was first implemented, a small number
of "generic" three letter codes were defined as
TLDs. These domains are administered by the InterNIC
and are still in wide spread use within the US. His-
torically, organisations have selected TLDs based on
their primary business. For example academic insti-
tutions usually have names that end in "edu", mili-
tary organisations in "mil", and companies in "com".
Delegation policies are up to the party responsible
for the administration of the domain from which del-
egations are made. For example, policies regarding
delegation of second level domain names ending in
"edu" are determined by the InterNIC. Delegation
policies for third level domain names, however, are
____________________________________________________
ripe-136.txt Page 38
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
determined by the body to which the corresponding
second level domain name has been delegated. For
example, a representative of Catatonic State Univer-
sity may be responsible for the delegation of subdo-
mains which fall under "cat.edu". In general, the
delegation policies applied by DNS domain adminis-
trators are expected to remain within the guidelines
outlined in [Postel94a].
In mapping a domain name to an IP address, the name
servers administered by those responsible for the
associated domains must provide the information suf-
ficient to resolve it. Suppose a request is
received for the IP address of a host named
"bite.dog.cat.edu". Because the InterNIC is respon-
sible for all delegations in the TLD "edu", the
request can first be passed to InterNIC's name
server. If the domain "cat.edu" has been delegated
to the Catatonic State University name server, the
InterNIC's name server will probably pass the
request to the university's name server, which in
turn might pass it on to the appropriate depart-
ment's name server. If all name server files are in
order, the department's name server should provide
the IP address for the domain name in question.
This is a simplified model of how name resolution
occurs. It ignores caching and other alternatives
that are used to optimise the DNS. It does, how-
ever, give a realistic view of which parties are
responsible to provide which information in the res-
olution process.
5.2. Reverse Address Delegation and Mapping
Just as it is necessary to obtain the IP number for
a host with a given domain name, it is often neces-
sary to do the reverse, that is to obtain the domain
name associated with a specific IP address. Autho-
risation checks used by some Internet applications
some diagnostic services need the fully qualified
domain name associated with an address, for example.
Given an IP address, the procedure used to obtain
the domain name associated with it is called reverse
mapping.
In the DNS, a pseudo domain called "in-addr.arpa" (a
historical abbreviation for "inverse addresses in
the Arpanet") has been defined, to make this possi-
ble. Delegations in this domain are made by IRs,
because they allocate and assign address space. For
example, the RIPE NCC has been delegated the domain
____________________________________________________
ripe-136.txt Page 39
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
"193.in-addr.arpa", because it is responsible for
allocations and assignments in 193/8 (among others).
The RIPE NCC delegates authority for names within
the domain "193.in-addr.arpa", after the correspond-
ing address space has been allocated and assigned.
Given the IP address 193.3.20.100 in dotted quad
notation, suppose its domain name is required.
First, a pseudo domain name "100.20.3.193.in-
addr.arpa" is generated by reversing the order of
the address components and adding the suffix ".in-
addr.arpa". This name is then used to find the
domain name corresponding to the IP address with
reverse mapping. Once the name as been generated in
the pseudo domain, the reverse mapping mechanism is
technically equivalent to the forward mapping mecha-
nism.
Although the mechanisms used for forward and reverse
mapping are equivalent, authority of the domain
hierarchies is different. In particular, while dele-
gation in the generic and country specific TLDs fol-
lows the organisational structure described in the
previous section, delegation in the pseudo domain
"in-addr.arpa" involves those responsible for the
allocation and assignment of the corresponding
address space.
The term reverse delegation refers to the delegation
of IP address names in the pseudo domain "in-
addr.arpa".
For example, the inverse domain name "193.in-
addr.arpa" has been reverse delegated to the RIPE
NCC, which is therefore responsible to supply infor-
mation which can lead to domain names corresponding
with assigned IP addresses in the 193/8 range. It
is important to note that reverse delegation of
address names in the pseudo domain does not occur
automatically either upon allocation or upon assign-
ment of address space. Rather, for all allocations
and assignments from the address space managed by
the RIPE NCC, reverse delegation only occurs in
response to an explicit request submitted to the
RIPE NCC. This is of course a prerequisite if
reverse mapping is to be used for IP address to
domain name translations.
As described above, pseudo domain names are gener-
ated in terms of dotted quad notation for IP
addresses. This requires that reverse delegation
take place on octet boundaries. Suppose the RIPE NCC
allocates a /17 to a local IR named Eye-Pea, for
____________________________________________________
ripe-136.txt Page 40
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
example, 193.1.0/17. Then no reverse delegation of
the name "1.193.in-addr.arpa" will be made to Eye-
Pea, because it is only responsible for a subset of
the address space corresponding to the inverse
domain "1.193.in-addr.arpa". The RIPE NCC therefore
remains responsible for the inverse domain name
"1.193.in-addr.arpa" and all reverse delegations
that fall under it.
On the other hand, suppose a /16 allocation is made
to a local IR called Aye-Queue, for example
193.2/16. Then, the zone "2.193.in-addr.arpa" can be
reverse delegated to Aye-Queue upon request because
that IR is responsible for all assignments in the
address range 193.2.0.0 - 193.2.255.255. Subse-
quently, Aye-Queue will be expected to provide
pointers to reverse domain name information for
addresses in the range 193.2.0.0 - 193.2.255.255.
Note that if the request is granted, Aye-Queue is
said to have authority over the "2.193.in-addr.arpa"
zone.
Following the procedures specified in Section 3 of
this document, Aye-Queue may then assign a /24, for
example 193.2.40.0 - 193.2.40.255 to some organisa-
tion called Organiser. Subsequently Aye-Queue can
make a reverse delegation for "40.2.193.in-
addr.arpa" so that requests for domain names associ-
ated with addresses in the range 193.2.40.0 -
193.2.40.255 will be forwarded to Organiser.
Note that with the classless scheme, both address
space allocations and assignments may take place on
non-octet boundaries, whereas reverse delegations
must occur on octet boundaries because the the
reverse domain name is specified in terms of dotted
quad notation for the IP address. This means that
allocations and assignments made on non octet CIDR
boundaries, a slightly different delegation strategy
is required, that will be explained in this section.
The basic system, however, remains unchanged.
The RIPE NCC together with the local IRs act
together to assure that reverse delegation is cor-
rectly performed. This allows reverse mapping to be
used to find the domain names corresponding to IP
addresses from the range managed by the RIPE NCC.
The role of both parties is covered in the following
subsections.
____________________________________________________
ripe-136.txt Page 41
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
5.3. Local IRs and Reverse Delegations
If a local IR obtains reverse delegations for the
address space it assigns, it is able to efficiently
provide expected services, namely IP number to
domain name mapping, for the end users it services.
In this section, we describe how reverse delegations
can be obtained.
We start with a description of the responsibilities
which accompany authority over inverse address
domain name zones. We then discuss the proper dis-
tribution and maintenance of the reverse address
database when CIDR address space allocations and
assignments are made. The specific procedures used
to obtain reverse delegations are described.
Finally we consider issues relevant to local IRs
regarding PA versus PI address space assignments.
5.3.1. Responsibilities
Prior to the delegation of domain name zones (e.g.
"cat.edu"), the person or organisation to whom
authority over the zone is delegated agrees to pro-
vide some key services necessary to support domain
names extending from the zone. Similar agreements
are of course necessary for reverse delegations if
DNS is to provide accurate mappings from IP
addresses to domain names.
When a reverse domain zone is delegated to a local
IR, care should of course be taken in the proper
construction of the DNS configuration files for the
zone. Known pitfalls and some useful tips for
avoiding them can be found in [Beertema93a].
For each zone, a secondary server must be set up to
improve the reliability of the database under
adverse conditions. To increase the probability
that the secondary server can be reached if the pri-
mary server becomes unavailable, the secondary
server is required to be on a subnet physically sep-
arated from the primary server. For reverse delega-
tions corresponding to /16 allocations to local IRs,
an additional secondary server is provided by the
RIPE NCC. This does not replace the required sec-
ondary, but rather provides extra reliability for
these substantial delegations. It is customary for
local IRs and other organisations managing reverse
domain names to provide secondary services for one
another.
____________________________________________________
ripe-136.txt Page 42
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
As is required for top level domain name servers,
both the primary and secondary reverse domain name
servers must be directly reachable from the Inter-
net.
If a local IR is given authority over a reverse
domain name zone, it is responsible for subsequent
reverse delegations in that zone. This means the
local IR must assure that an organisation to which
authority is delegated satisfies the requirements
described in this section for its zone. In Section
5.4, we describe the services provided by the RIPE
NCC to assure proper working of the reverse domain
name system. Local IRs should use this as a refer-
ence for the services they provide to end users to
whom they make reverse delegations.
5.3.2. CIDR and Reverse Delegations
As mentioned above, making allocations and assign-
ments on CIDR boundaries, rather than on traditional
class (octet) boundaries, requires a slight varia-
tion on the reverse delegation scheme. Basically, if
an allocation or an assignment is made on a nonoctet
boundary, authority over the corresponding reverse
domain zone must not be delegated, but must be main-
tained by the IR that makes the address space allo-
cation or assignment.
5.3.2.1. Allocations and Reverse Delegations
If an allocation smaller than a /16 is made to a
local IR, such as the 193.1.0/17 allocation to Eye-
Pea in our example, then authority for an immediate
subdomain of 193.in-addr.arpa cannot be granted,
because a subset of the corresponding address space
may be allocated to another local IR.
For any single allocation under /16 in the 193/8
address range, the RIPE NCC will maintain authority
for the immediate subdomain of 193.in-addr.arpa, and
reverse delegations will be made upon request if
preceded by corresponding address space assignments.
This of course holds for reverse delegations corre-
sponding to any /8 address space allocations managed
by the RIPE NCC.
If at some point, the remainder of the block (in
this example 193.1.128/17) happens to be allocated
to Eye-Pea, a request (accompanied by a domain
database object) can be submitted for a reverse
____________________________________________________
ripe-136.txt Page 43
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
delegation of 1.193.in-addr.arpa. When a reverse
delegation is made to a local IR, the RIPE NCC will
forward all the relevant data and the responsibility
for any reverse delegated zones to the local IR. In
this example, if 1.193.in-addr.arpa is delegated to
Eye-Pea, all past and future delegations made from
that domain fall under the authority of Eye-Pea.
Suppose, on the other hand that a /16 has been allo-
cated to the local IR in the first place, such as
the 193.2/16 allocated to Aye-Queue in the example
above. Then Aye-Queue (e.g. the local IR receiving
the allocation) may immediately request authority
for a subdomain of 193.in-addr.arpa, in this case
2.193.in-addr.arpa. Because Aye-Queue is responsi-
ble for all address space corresponding to the
reverse domain name 2.193.in-addr.arpa, the reverse
delegation can be granted.
5.3.2.2. Assignments and Reverse Delegations
With respect to reverse delegations, we can distin-
guish two address space assignment categories,
namely those assignments that involve an integral
number of /24's, and those that do not. We begin
with the latter.
We first consider an assignment made by a registry
holding a full /16 allocation. Continuing with our
example, suppose that Aye-Queue has been allocated
193.2/16 and has a reverse delegation for 2.193.in-
addr.arpa. Aye-Queue might assign the 64 addresses
in 193.2.0/26 to an end user, say Use-IQ. Following
the reasoning applied for the /17 allocation to Eye-
Pea above, Use-IQ cannot obtain a reverse delegation
for 0.2.193.in-addr.arpa, because some of the corre-
sponding address space may be assigned to other end
users.
To address this problem, Aye-Queue can essentially
delegate 0.2.193.in-addr.arpa to itself, and main-
tain the IP address to domain name information for
Use-IQ and any other end users to whom the corre-
sponding address space is assigned. Such a delega-
tion to the same organisation is of course not nec-
essary, but it can be helpful in easing the adminis-
tration of multiple domains. When a local IR makes
a reverse delegation to itself for address space it
assigns, it is recommended, but not strictly
required that a domain object be submitted to the
RIPE database to register the reverse delegation.
____________________________________________________
ripe-136.txt Page 44
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
Suppose a similar assignment is made by Eye-Pea from
the 193.1.0/17 address space allocated to it. If
Eye-Pea assigns 193.1.0.0/26 to an end user, say
Use-IP, the problem arises again. Moreover, because
Eye-Pea does not have authority for 1.193.in-
addr.arpa, it cannot delegate 0.1.193.in-addr.arpa
to itself. Rather Eye-Pea can receive a reverse del-
egation for 0.1.193.in-addr.arpa upon request, after
at least one assignment has been made from the cor-
responding /24 address space. The procedures to
obtain a reverse delegation are outlined in Sections
5.3.3 and 5.5 below.
Of course, Use-IQ could have been assigned an inte-
gral number of /24's. For example, suppose it was
assigned 768 addresses in the range
193.2.0.0-193.2.2.255. Then Aye-Queue can make
reverse delegations of {0,1,2}.2.193.in-addr.arpa to
Use-IQ. The procedures Aye-Queue should follow in
making reverse delegations and the services it
should provide to its end users are described in
Sections 5.4 and 5.5.
Suppose now that Eye-Pea assigns the 256 addresses
in the range 193.1.0.0 - 193.1.0.255 to Use-IP. Then
Eye-Pea need not manage the reverse domain
0.1.193.in-addr.arpa, because Use-IP is the only
end-user with addresses assigned from the corre-
sponding address space. In this case, Eye-Pea should
support the end user in requesting a reverse delega-
tion (using the inetnum object) from the RIPE NCC,
and provide secondary database and other services as
necessary. See the next section for more informa-
tion.
In summary, after an assignment which is smaller
than /24 has been made. a local IR should obtain a
reverse delegation for the reverse name correspond-
ing to the assigned address space. It should main-
tain the reverse mapping entries to reflect IP
address to domain name information provided by the
end user. More information on management of inverse
mappings when allocations and assignments are made
on non-octet CIDR boundaries is available in
[Eidnes96a].
5.3.3. Obtaining a Reverse Delegation
We now describe the procedures to be followed by a
local IR, requesting a reverse delegation from the
RIPE NCC. As can be concluded from the previous sec-
tion, a local IR can obtain authority for a /16
____________________________________________________
ripe-136.txt Page 45
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
following its allocation, or for a /24 after one or
more assignments have been made from it. The two
procedures are very similar. However, in this sec-
tion we describe only the steps to be taken for a
/16 reverse delegation, while the procedures for a
/24 are described in Section 5.5. To acquire
authority over the reverse domain name zones corre-
sponding with the address space involved, the fol-
lowing steps should be taken.
1. Configure the DNS configuration files for
the zone for which the delegation is requested.
Following the findings in [Beertema93a], for a
direct subdomain of the domains under RIPE NCC
authority (193.in-addr.arpa, etc.), the follow-
ing settings are strongly recommended:
Refresh = 8 hours (28800 seconds)
Retry = 2 hours (7200 seconds)
Expire = 7 days (604800 seconds)
Time To Live = 1 day (86400 seconds)
We recommend a lower retry level if connectiv-
ity is unstable.
2. Install the configuration files on the pri-
mary and secondary servers.
3. Gather information required for a RIPE
database domain object. The name of the domain
requested, for example "1.193.in-addr.arpa"
must be entered in the domain field. A
description of the organisation to maintain the
zone under consideration should be included in
one or more descr fields. The admin-c, tech-c,
and zone-c fields should specify the persons
who are responsible for administration at the
site of the primary server, technical support
for the site, and authority over the zone,
respectively. The nserver fields, of which
there must be at least three, specify the
domain names of the primary, secondary, and
RIPE NCC reverse name servers. Finally, as for
all RIPE database objects, there is a changed
and source field used to specify the e-mail
address of the person making the request and
the database source "RIPE", respectively.
4. Submit a request for a reverse delegation to
<auto-inaddr@ripe.net>. This step implies the
requirements described in Section 5.3.1 have
been satisfied. The domain object described
____________________________________________________
ripe-136.txt Page 46
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
above should be included in the request, as
well as zone file entries for the zone above
the one requested. For example if a reverse
delegation is requested for 1.193.in-addr.arpa,
the relevant zone file entries should be
included for 193.in-addr.arpa, whereas if a
reverse delegation is requested for 2.2.193.in-
addr.arpa, the zone file entries should be
included for 2.193.in-addr.arpa. (This is one
request to <auto-inaddr@ripe.net> for which the
X_NCC_RegID field may be omitted, but the omis-
sion will result in the a low priority for the
request.)
As described below, the RIPE NCC will test the
proper working of the primary and secondary servers.
If the local IR making the request has been allo-
cated the address space corresponding to the reverse
domain name zone for which the request has been sub-
mitted, and the servers are running properly, the
request for delegation will be granted. In the next
section, the services provided by the RIPE NCC are
described.
5.3.4. Side Effects for PA/PI Assignments
End users have a right to reverse mapping services.
An end user holding non-PA address space from a zone
that has been reverse delegated to one service
provider is permitted to keep the address space, and
obtain connectivity services from another provider.
Because the address space falls in the reverse dele-
gation zone of the initial local IR, that IR is
required to continue to provide reverse mapping ser-
vices for the address space assigned to the end
user. Moreover, the local IR has to provide this
service under the same conditions it applies to its
other end users (e.g. extremely high fees for this
service are unacceptable - unless they are applied
to all end users.)
For PA addresses, contractual agreements confine the
provision of reverse mapping services directly to
the time period for which the assignment is valid.
Clearly this is one reason why converting non-PA
address space to PA address space is in the best
interests of the assigning local IRs and their cus-
tomers.
____________________________________________________
ripe-136.txt Page 47
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
5.4. The RIPE NCC Services for Reverse Delegation
Because the RIPE NCC allocates address space to
local IRs from 193/8 and other /8's allocated to it
by IANA, it is responsible for reverse delegations
that correspond to the address space. Requests to
resolve reverse mappings for address space assigned
from that allocated by the RIPE NCC should therefore
be sent to the RIPE NCC. If a reverse mapping is
required for an address, and one is not sure which
regional IR the address originated from, a request
can be sent to the RIPE NCC; if the address space
originated from one of the other regional reg-
istries, its contact details will be returned. Of
course, one cannot perform reverse mappings for IP
addresses that have not either been allocated (/16)
or assigned and registered (/24).
Upon receiving a request for a reverse delegation of
an immediate subdomain of 193.in-addr.arpa or
194.in-addr.arpa, the RIPE NCC will first check if
all of the corresponding address space has been
allocated to the requesting IR. If the request is
for a /24, then a check will be made as to whether
some or all of the address space has been assigned.
If the required allocation (assignment) has been
made, the following services will be performed:
1. Access to the primary and secondary servers
specified in the domain object will be tested.
2. Data for any already registered reverse
zones in the corresponding address space will
be forwarded to the requesting organisation,
for inclusion in the newly defined reverse zone
files. (If the reverse delegation is made, fur-
ther responsibility for past delegations is
transferred to the requesting organisation.)
3. The reverse domain name server will be
tested using the information provided in the
request.
For a /16 reverse delegation, the next two tasks are
also performed:
4. If the reverse delegation request is to be
granted, the RIPE NCC will set up secondary
server for the reverse domain on ns.ripe.net,
and notify the local IR.
5. Once the reverse delegation has been made,
requests made to the RIPE NCC for reverse
____________________________________________________
ripe-136.txt Page 48
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
delegations for address space corresponding to
the delegated zone will be forwarded to the
mailbox specified in the SOA RR field of the
reverse zone configuration file, and to the
person specified in the zone-c field of the
domain object.
All requests for reverse delegations at the RIPE NCC
are now being handled by an automatic procedure.
Zone information for the request described above
will be checked automatically upon receipt in the
<auto-inaddr@ripe.net> mailbox. If the zone is set
up properly, the request will be evaluated by a RIPE
NCC staff member, and if everything is in order, the
request will be granted.
Reverse delegations allow a local IR to administer
reverse mapping services for IP addresses assigned
to its end users. The end users can then be sure
they can be identified quickly and easily from hosts
on the network having only access to the IP address.
Because of the distributed nature of the database,
its proper working depends on the correct adminis-
tration of all zones. On some rare occasions, an
organisation managing a delegated zone proves unable
to correctly perform the required services. If
repeated complaints are made regarding the adminis-
tration of a zone delegated by the RIPE NCC, the
RIPE NCC may revoke the delegation, as a final ser-
vice to support efficient and correct reverse map-
ping.
5.5. Making Reverse Delegations to End Users
Up to this point, we have been concerned with the
procedures surrounding the reverse delegation of a
zone to a local IR. Because the reliability of the
data distributed with the DNS increases as the dis-
tance to the data source decreases, reverse delega-
tions of a zone can also be made to end users for
each /24 they are assigned. In this context a /22
assignment is simply a multiple /24 assignment, for
which multiple reverse delegations should be
requested.
A local IR should always support end users request-
ing reverse delegations corresponding to address
space (one or more /24's) which has been assigned to
them from address space allocated to the local IR.
The end user must be made aware of the means to
acquire a reverse delegation and the responsibili-
ties that go with it.
____________________________________________________
ripe-136.txt Page 49
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
Basically, the same criteria hold in the case of
reverse delegations to end users as hold for local
IRs. The end user requesting authority for a partic-
ular zone must agree to fulfill the responsibilities
described in Section 5.3.1. There is a slight varia-
tion of the procedures described in Section 5.3.3.
While the end user is responsible for the reverse
delegation and therefore for the procedures sur-
rounding it, local IRs traditionally support end
users in obtaining and in maintaining reverse dele-
gations for their address space. For example, it is
common for the assigning local IR to provide a sec-
ondary server for the reverse delegation.
If a local IR such as Eye-Pea has an allocation for
a /19, /18, or a /17 address range, then the reverse
delegation must be made by the RIPE NCC rather than
the local IR. In this case, an inetnum database
object (rather than a domain object) should be sub-
mitted to the RIPE database and with the request
sent to <auto-inaddr@ripe.net>.
On the other hand, if a local IR such as Aye-Queue
has a /16 allocation, it may make the reverse dele-
gation itself, but is encouraged to submit an inet-
num object to the RIPE database to register the
reverse delegation.
In both cases the local IR is expected to perform
services similar to those performed by the RIPE NCC
to assure the requested delegation is appropriate
and properly administered. For example, the
assigned address space must correspond to the zone
requested, and the primary and secondary servers
must be tested to assure that they are reachable and
properly configured.
Acknowledgements
The authors would like to thank the staff of the
RIPE NCC for reviewing multiple versions of this
document.
____________________________________________________
ripe-136.txt Page 50
European Internet Registry Policies and Procedures
Dolderer, Karrenberg, Kuehne, Norris, Orange, Woeber, Zsako
____________________________________________________
References
96a. Y. Rekhter , R. Moskowitz, D. Karrenberg, G. de
Groot , and E. Lear, Address Allocation for
Private Internets, RFC 1918 (02/1996).
Albitz94a.
Paul Albitz and Cricket Liu, DNS and BIND,
O'Reilly & Associates, Inc., Sebastopol, CA
(1994).
Beertema93a.
P. Beertema, Common DNS Data File Configuration
Errors, RFC 1537 (10/1993).
Caslav96a.
P. Caslav, M. Kuehne, and C. Orange, European
IP Address Space Request Form, ripe-137
(05/1996).
Deering89a.
S. Deering, Host Extensions for IP Multicast-
ing, RFC 1112 (08/1989).
Eidnes96a.
H. Eidnes and G. de Groot, Classless in-
addr.arpa delegation, Internet Draft (05/1996).
Gerich93a.
E. Gerich, Guidelines for Management of IP
Address Space, RFC 1466 (05/1993).
Postel94a.
J. Postel, Domain Name System Structure and
Delegation, RFC 1591 (03/1994).
____________________________________________________
ripe-136.txt Page 51