IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region

Mirjam Kuehne
Paul Rendek
Sabrina Wilmot
Leo Vegoda

Document ID: ripe-324
Date: October 2004
Obsoletes: ripe-104, ripe-105, ripe-127, ripe-136, ripe-140, ripe-159, ripe-185, ripe-234, ripe-288

Abstract

This document describes the RIPE community's current IPv4 address
allocation and assignment policies. They were developed through a
bottom-up, consensus driven, open policy development process in the
RIPE Address Policy Working Group (AP WG). The RIPE Network
Coordination Centre (RIPE NCC) facilitates and supports this
process. These policies apply to the RIPE NCC and the Local Internet
Registries (LIRs) within the RIPE NCC service region.

Information on the Address Policy WG is available at:

http://www.ripe.net/ripe/wg/address-policy/index.html 

1.0 Introduction
1.1 Scope
2.0 IPv4 Address Space
3.0 Goals of the Internet Registry System
3.1 Confidentiality
3.2 Language
4.0 Registration Requirements
5.0 Policies and Guidelines for Allocations
5.1 First Allocation
5.2 Slow-start Mechanism
5.3 Additional Allocations
5.4 Sub-allocations
6.0 Policies and Guidelines for Assignments
6.1 Documentation for Assignments
6.2 Network Infrastructure and End User Networks
6.3 Utilisation Rates
6.4 Reservations Not Supported
6.5 Administrative Ease
6.6 Validity of an Assignment
6.7 Efficiency
6.8 Renumbering
7.0 Assignment Window
8.0 Assignments for Internetworking Experiments
9.0  PA vs. PI Address Space
10.0 Record Keeping
11.0 LIR Audit
12.0 Closing an LIR by the RIPE NCC

1.0 Introduction

The RIPE NCC is an independent association and serves as one of four
Regional Internet Registries (RIRs). Its service region incorporates
Europe, the Middle East, Central Asia and African countries located
north of the equator. The RIPE NCC is responsible for the allocation
and assignment of Internet Protocol (IP) address space, Autonomous
System Numbers (ASNs) and the management of reverse domain names
within this region. The distribution of IP space follows the
hierarchical scheme described in the document "Internet Registry
System" available from the RIPE NCC web site at:

http://www.ripe.net/info/resource-admin/rir-system.html

1.1 Scope

This document describes the policies for the responsible management of
globally unique IPv4 Internet address space in the RIPE NCC service
region. The policies documented here apply to all IPv4 address space
allocated and assigned by the RIPE NCC. These policies must be
implemented by all RIPE NCC member LIRs.

This document does not describe policies related to AS Numbers, IPv6,
Multicast, or private address space. Nor does it describe address
distribution policies used by other RIRs. The RIPE community's
policies for ASN assignment and IPv6 are published in the RIPE
Document Store at:

http://www.ripe.net/ripe/docs/internet-registries.html#policy 

2.0 IPv4 Address Space

For the purposes of this document, IP addresses are 32-bit binary
numbers used as addresses in the IPv4 protocol. There are three main
types of IPv4 addresses:

1.) Public IP addresses are assigned to be globally unique according
  to the goals described in Section 3 of this document.

2.) Some address ranges are set aside for the operation of private IP
  networks. Anyone may use these addresses in their private networks
  without registration or co-ordination. Hosts using these addresses
  cannot directly be reached from the Internet. Such connectivity is
  enabled by using the technique known as Network Address Translation
  (NAT). Private addresses restrict a network so that its hosts only
  have partial Internet connectivity. Where full Internet connectivity
  is needed, unique, public addresses should be used.

For a detailed description of "Address Allocation for Private
Internets" and the actual ranges of addresses set aside for that
purpose, please refer to RFC 1918 found at:

ftp://ftp.ripe.net/rfc/rfc1918.txt 

For information on the "Architectural Implications of NAT", please
refer to RFC 2993, found at:

ftp://ftp.ripe.net/rfc/rfc2993.txt 

3.) Some address ranges are reserved for special use purposes. These
  are described in RFC 3330 and are beyond the scope of this
  document. RFC 3330 can be found at:

ftp://ftp.ripe.net/rfc/rfc3330.txt 

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following
goals in mind:

Uniqueness: Each public IPv4 address worldwide must be unique. This is
an absolute requirement guaranteeing that every host on the Internet
can be uniquely identified.

Aggregation: Distributing IPv4 addresses in an hierarchical manner
permits the aggregation of routing information. This helps to ensure
proper operation of Internet routing.

Conservation: Public IPv4 address space must be fairly distributed to
the End Users operating networks. To maximise the lifetime of the
public IPv4 address space, addresses must be distributed according to
need, and stockpiling must be prevented.

Registration: The provision of a public registry documenting address
space allocations and assignments must exist. This is necessary to
ensure uniqueness and to provide information for Internet
troubleshooting at all levels.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their
registrants. Information passed to an IR must be securely stored and
should not be distributed wider than necessary within the IR. When
necessary, the information may be passed to a higher-level IR under
the same conditions of confidentiality.

3.2 Language

Please note that all communication with the RIPE NCC must be in English.

4.0 Registration Requirements

All assignments and allocations must be registered in the RIPE
Database. This is necessary to ensure uniqueness and to support
network operations.

Only allocations and assignments registered in the RIPE Database are
considered valid. Registration of objects in the database is the final
step in making an allocation or assignment. Registration data (range,
contact information, status etc.) must be correct at all times
(i.e. they have to be maintained).

5.0 Policies and Guidelines for Allocations

An allocation is a block of IPv4 addresses from which assignments are taken.

All LIRs receiving address space from the RIPE NCC must adopt a set of
policies that are consistent with the policies formulated by the RIPE
community and described in this document.

If an LIR is planning to exchange or transfer address space it needs
to contact the RIPE NCC so that the changes can be properly
registered. Please note that the LIR always remains responsible for
the entire allocation it receives from the RIPE NCC until the
allocation is transferred to another LIR or returned. The LIR must
ensure that all policies are applied.

5.1 First Allocation

The RIPE NCC's minimum allocation size is /21. 

The minimum allocation size for countries in Africa is /22.

Details of how to join the RIPE NCC can be found in the RIPE document
"Procedure for Becoming a Member of the RIPE NCC" found at:

https://lirportal.ripe.net/newmember/index.html

Members can receive an initial IPv4 allocation when they have
demonstrated a need for IPv4 address space.

5.2 Slow-start Mechanism
  
The slow-start mechanism was put into place to ensure a consistent and
fair policy for all LIRs with respect to allocations.

Address space is allocated to LIRs at the rate that the addresses are
sub-allocated and assigned by the LIRs. An allocation larger than the
minimum size can be made if a need is demonstrated. The size of future
allocations is based on the usage rate of previous allocation(s).


5.3 Additional Allocations

An LIR may receive an additional allocation when about eighty percent
(80%) of all the address space currently allocated to it is used in
valid assignments or sub-allocations. A new allocation can be made if
a single assignment or sub-allocation requires a larger set of
addresses than can be satisfied with the address space currently held
by the LIR.

Reservations are not considered valid assignments or
sub-allocations. It may be useful for internal aggregation to keep
some address space free for future growth in addition to the actual
assignment. However, the LIR must be aware that these internal
reservations are not counted as valid usage. The space must be
sub-allocated or assigned before the LIR can request another
allocation.

To obtain a new allocation, an LIR should submit a request to the RIPE
NCC using the "IPv4 Additional Allocation Request Form" available from
the RIPE Document Store at:

http://www.ripe.net/ripe/docs/add-allocation.html 

Additional address space will only be allocated after the information
supplied with the request has been verified and a new allocation
deemed necessary.

The RIPE NCC will do its best to allocate contiguous address space in
order to support aggregation. This cannot be guaranteed as it depends
on factors outside the RIPE NCC's influence (e.g. the number of new
LIRs and the time needed to utilise the allocation).

5.4 Sub-allocations

Sub-allocations are intended to aid the goal of routing aggregation
and can only be made from allocations with a status of "ALLOCATED
PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED"
allocations may be able to convert them to PA allocations if there are
no ASSIGNED PI networks within it. The meanings of the various
"status:" attribute values are described in Section 9.0.

LIRs wishing to convert their allocations to PA status should contact
the RIPE NCC via e-mail at <lir-help@ripe.net>.

The minimum size of a sub-allocation is /24. This is the smallest
prefix length that can be reverse delegated and allows for a
reasonable number of small assignments to be made by a downstream
network operator.

An LIR may sub-allocate IPv4 space up to 400% of its Assignment Window
(AW) to an organisation every twelve months. Thus, an LIR with an AW
of /26 may make a /24 sub-allocation. LIRs with an AW smaller than /26
may not make sub-allocations as the minimum sub-allocation size is
/24. The AW policy is described in Section 7.0.

LIRs may make sub-allocations to multiple downstream network operators.

Downstream network operators efficiently using a /22 sub-allocation
qualify to receive a /20 PA allocation from the RIPE NCC if they
decide to become an LIR themselves.

The maximum size of a sub-allocation is /20 even if this is less than
400% of the LIR's AW. For example, an LIR with a /21 AW may not
sub-allocate a /19 to a downstream network. However, downstream
network operators may receive sub-allocations totalling more than a
/20 from more than one LIR.

The LIR is contractually responsible for ensuring the address space
allocated to it is used in accordance with the RIPE community's
policies. It is recommended that LIRs have contracts requiring
downstream network operators to follow the RIPE community's policies
when those operators have sub-allocations.

The RIPE NCC considers sub-allocated space as "used" when evaluating
requests from the LIR for an additional IPv4 allocation. LIRs are
still required to demonstrate about 80% usage for all their
allocations. Where an LIR has made many sub-allocations with little
assigned within them, the RIPE NCC will ask the LIR to justify the
reasons for the sub-allocations.

LIRs should note that evaluating a request for an allocation is
different from evaluating a request for an assignment. With
assignments, the evaluator can see the network plans for a single
organisation. With allocations, the evaluator is often presented with
sales and marketing plans. The addressing requirements of individual
organisations cannot be examined.

It is recommended that LIRs make use of a slow-start mechanism when
making a sub-allocation for a downstream network operator. There are
two main advantages to this: the LIR can ensure that the address space
it sub-allocates is used efficiently; also the LIR can determine the
ability of the downstream organisation to operate within the policies
set by the RIPE community.

Sub-allocations form part of an LIR's aggregatable address space. As
such, an LIR may want to ensure that the address space is not retained
by a downstream network if the downstream network operator ceases to
receive connectivity from the LIR's network. LIRs not wishing to lose
address space in this way are responsible for ensuring that the status
of the sub-allocation is clear in any contracts between the LIR and
the downstream network operator.

6.0 Policies and Guidelines for Assignments

Conservation and aggregation are often conflicting goals. When the
Internet Registry System goals are in conflict with the interests of
individual End Users or service providers, careful analysis and
judgement is necessary to find an appropriate compromise. The rules
and guidelines in this document are intended to help LIRs and End
Users in their search for equitable compromises.

Please note that LIRs must request approval from the RIPE NCC for
assignments that are larger than the LIR's AW (Section 7.0). LIRs are
always welcome to approach the RIPE NCC for a second opinion on
requests even if they fall within the LIR's AW.

6.1 Documentation for Assignments

In order to determine the address space requirements for a network,
relevant information must be gathered. The details needed for
justification of each End User organisation's assignments include the
addressing requirements, network infrastructure and future plans. The
current address space usage of the organisation should also be
determined to ensure that an existing assignment is not duplicated.

This information is essential in making the appropriate assignment
decisions. Balancing the overall goals of the Internet Registry System
(Section 3.0) with the requirements of the network in question is
needed for every network. The level of detail is dependent on the
complexity of the network. The LIR must ensure that the necessary
information is complete before making an assignment.

The RIPE NCC provides forms for gathering the required
information. The information requested in the forms must be collected
by the LIR. LIRs may use these forms for their customers' requests or
develop their own forms. Local forms can be used if they record all
the required data. This is very important when an LIR makes
assignments using its AW.

If a request needs to be approved by the RIPE NCC or if information is
required in the event of an audit, the information must be submitted
on the version of the request form in place at the time of the
assignment. The current versions of all request forms can be found at:

http://www.ripe.net/ripe/docs/internet-registries.html#request 

6.2 Network Infrastructure and End User Networks

IP addresses used solely for the connection of an End User to a
service provider (e.g. point-to-point links) are considered part of
the service provider's infrastructure. These addresses do not have to
be registered with the End User's contact details but can be
registered as part of the service provider's internal
infrastructure. When an End User has a network using public address
space this must be registered separately with the contact details of
the End User. Where the End User is an individual rather than an
organisation, the contact information of the service provider may be
substituted for the End User's.

An explanation of how to register objects in the database can be found
in the "RIPE Database User Manual: Getting Started" found at:

http://www.ripe.net/ripe/docs/db-start.html 

6.3 Utilisation Rates

Assignments' immediate utilisation should be at least 25% of the
assigned space. After one year, this should be at least 50% of the
space unless special circumstances are defined. Assignments may only
be based on realistic expectations recorded in the documentation.

6.4 Reservations Not Supported

End Users are not permitted to reserve address space based on
long-term plans. This violates the goal of conservation and fragments
the address space when initial forecasts are not met. Evaluation of IP
address space requests must be based on a demonstrated need. Unused,
or inefficiently used address space assigned in the past should be
used to meet the current request, or returned. 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.

6.5 Administrative Ease

The current rate of consumption of the remaining unassigned IPv4
address space does not permit the assignment of addresses for
administrative ease. Examples of this include, but are not limited to,
ease of billing administration and network management.

6.6 Validity of an Assignment

All assignments are valid as long as the original criteria on which
the assignment was based are still valid and the assignment is
properly registered in the RIPE Database. If an assignment is made for
a specific purpose and that purpose no longer exists, the assignment
is no longer valid. If an assignment is based on information that
turns out to be invalid, the assignment is no longer valid.

For these reasons it is important that LIRs make sure that assignments
approved by the RIPE NCC are properly registered in the database. The
inetnum object or objects for approved assignments must use the
netname(s) approved by the RIPE NCC and not be larger than the
approved size. Additionally, the date in the first "changed:"
attribute must not be earlier than the date of the approval message
from the RIPE NCC.

The RIPE NCC reviews assignments made by LIRs when evaluating requests
for additional allocations (see 5.3). It also runs consistency checks
as part of the auditing activity requested by the community as
described in the RIPE document "RIPE NCC Consistency and Auditing
Activity" found at:

http://www.ripe.net/ripe/docs/audit.html 

6.7 Efficiency

Where large amounts of address space are assigned for a purpose that
is often satisfied with smaller amounts (e.g. transient connections or
virtual server hosting), the RIPE NCC may verify the existing usage
before approving additional assignments.

6.8 Renumbering

In general, addresses can be replaced on a one-to-one basis. Valid
assignments can be replaced with the same number of addresses if the
original assignment criteria are still met. The addresses to be
replaced must still be in use. End Users are required to submit a new
request if more than half the original assignment is not in use. When
the renumbering request exceeds the new LIR's AW (see Section 7.0) the
request needs to be sent to the RIPE NCC for approval.

The RIPE community generally accepts that a period of three months is
enough time to migrate a network to new address space. Where the End
User wants to keep both assignments for more than three months, an
agreement should be obtained from the RIPE NCC for the proposed time
frame.

Once a network has been renumbered, the old assignment must be removed
from the RIPE Database.

7.0 Assignment Window

An AW refers to the maximum number of addresses that can be assigned
by the LIR without prior approval from the RIPE NCC, either to their
own network or to an End User's network. The size of the AW is
expressed in CIDR notation.

The AW policy was developed to achieve various levels of support based
on the level of experience of the LIR. The RIPE NCC may review
assignments made with the LIR's AW to ensure that the LIR is assigning
address space according to the RIPE community's policies. This is
important to assure the fair distribution of address space and to meet
the goals of aggregation, conservation and registration. Documentation
for assignments made with an AW need to contain the same information
as in a completed request form found at:

http://www.ripe.net/ripe/docs/internet-registries.html#request 

All new LIRs start with an AW of zero (0). This means that every
assignment requires prior approval from the RIPE NCC.

The AW is applied differently depending on whether the assignment is
for an End User or for the LIR's infrastructure.

There is no constraint on how often the LIR uses its AW for its own
infrastructure. These assignments may not exceed the LIR's AW. This
means that an LIR with a /25 AW can make numerous individual /25
assignments to its own network infrastructure without having to send
each request to the RIPE NCC.  However, where a single assignment
would exceed a /25 the LIR would need to request approval for that
assignment from the RIPE NCC.

LIRs must specify which assignments to their own infrastructure have
used the AW. Such assignments must have a "remarks:" attribute with
the value <INFRA-AW> in the inetnum object registered in the RIPE
Database. It is important that a separate "remarks:" attribute is used
solely for this purpose.

An AW can be applied to an End User network once per 12-month
period. This means an LIR can make more than one assignment to an End
User in any 12 month period but the total amount of address space
cannot be larger than the LIR's AW. An LIR's AW is refreshed on the
anniversary of an assignment. When an LIR has made several assignments
to an organisation over the period of a year their AW for that
organisation will be fully restored on the anniversary of the last
assignment. The LIR may only assign additional addresses to the same
End User after approval from the RIPE NCC.

AWs are regularly reviewed by the RIPE NCC Hostmasters. LIRs may
approach the RIPE NCC for an evaluation of its AW at any time. Please
note that LIRs are always welcome to approach the RIPE NCC for a
second opinion on requests even if they fall within the LIR's AW.

As the proficiency of the LIR contacts increases, the size of their AW
may be raised. This is determined based on:
  
* correctly completed documentation presented to the RIPE NCC
* good judgement shown in the evaluation of address space requests
* past assignments have been properly registered

An established LIR is responsible for training its new LIR contacts to
handle address space assignments according to the policies described
in this document and their procedures. Less experienced LIR contacts
may make errors both in judgement and procedure. If errors happen
repeatedly, the AW of the LIR may be decreased to prevent the LIR from
making invalid assignments. The AW may again be increased based on the
criteria stated above.

The AW may also be lowered after or during an audit if invalid
assignments are noted.


8.0 Assignments for Internetworking Experiments

Organisations often require deployment tests for new Internet services
and technologies. These require numbering resources for the duration
of the test. The policy goal of resource conservation is of reduced
importance when resources are issued on a temporary basis.

An organisation receiving numbering resources must document the
experiment. This may be in the form of a current IETF Experimental RFC
(http://www.ietf.org/rfc/rfc2026.txt Sec. 4.2.1) or an "experiment
proposal" detailing the resources required and the activities to be
carried out.

The assignment size will be equal to the existing minimum allocation
size on the date the request is received. Where the experiment
requires a variation to this rule it should be noted in the resource
request.

The experiment proposal must be made public (e.g. published on web
site), upon registration of the resources by the RIPE NCC. Following
the conclusion of the experiment the results must be published free of
charge and free from disclosure constraints.

Resources issued must not be used for commercial purposes during or
following the conclusion of the experiment.

The resources will be issued on a temporary basis for a period of one
year. Renewal of the resource's registration is possible on receipt of
a new request that details continuation of the experiment during the
extended period.

The RIPE NCC will register the resources issued in the RIPE Whois Database. 

The request must be made by an LIR using the appropriate request
form. Details of the experiment should be noted in the form found at:

http://www.ripe.net/ripe/docs/internet-registries.html#request 

9.0 PA vs. PI Address Space

LIRs are allocated PA address space. They sub-allocate and assign this
to downstream networks. If a downstream network or End User changes
its service provider, the address space assigned or sub-allocated by
the previous service provider will have to be returned and the network
renumbered.

In contrast, PI address space cannot be aggregated. It can remain
assigned to a network as long as the criteria for the original
assignment are met. However, PI addresses are expensive to route as no
use of aggregation can be made. They might not be globally routable.

The use of PA address space should always be recommended.

LIRs must make it clear to End Users which type of address space is
assigned. Clear contractual arrangements are recommended and are
mandatory for PA space. In the past, some LIRs assigned address space
that was de facto aggregated but not formally PA because there were no
clear contractual arrangements for termination of the assignment. LIRs
must ask leaving customers to voluntarily release this address space
upon termination of service. Where possible, LIRs should work to make
contractual arrangements to convert PI addresses into PA addresses.

End Users requesting PA space should be given this or a similar warning: 

Assignment of this IP space is valid as long as the criteria for the
original assignment are met and only for the duration of the service
agreement between yourself and us. We have the right to reassign the
address space to another user upon termination of this agreement or an
agreed period thereafter. This means that you will have to
re-configure the addresses of all equipment using this IP space if you
continue to require global uniqueness of those addresses.

End Users requesting PI space should be given this or a similar warning: 

Assignment of this IP space is valid as long as the criteria for the
original assignment are still met. However, assignment of address
space does NOT imply that this address space will be ROUTABLE ON ANY
PART OF THE INTERNET. It is expected that users will have to pay a
premium for actual routing of PI addresses as opposed to PA
addresses. It may eventually become impossible to get relatively small
amounts of PI space routed on most of the Internet. We strongly
suggest you contact any prospective service provider for information
about issues related to service when using PI addresses.

LIRs will register the type of any assigned address space using the
"status:" attribute of the inetnum object in the RIPE Database. The
possible values of this attribute are:

ALLOCATED PA: This address space has been allocated to an LIR and no
assignments or sub-allocations made from it are portable. Assignments
and sub-allocations cannot be kept when moving to another provider.

ALLOCATED PI: This address space has been allocated to an LIR or RIR
and all assignments made from it are portable. Assignments can be kept
as long as the criteria for the original assignment are
met. Sub-allocations cannot be made from this type of address space.

ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR
or RIR. Assignments may be PA or PI. This status is intended to
document past allocations where assignments of both types exist. It is
avoided for new allocations. Sub-allocations cannot be made from this
type of address space.

SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR
to a downstream network operator that will make assignments from
it. All assignments made from it are PA. They cannot be kept when
moving to a service provided by another provider.

LIR-PARTITIONED PA: This allows an LIR to document distribution and
delegate management of allocated space within their
organisation. Address space with a status of LIR-PARTITIONED is not
considered used. When the addresses are used, a more specific inetnum
should be registered.

LIR-PARTITIONED PI: This allows an LIR to document distribution and
delegate management of allocated space within their
organisation. Address space with a status of LIR-PARTITIONED is not
considered used. When the addresses are used, a more specific inetnum
should be registered.

EARLY-REGISTRATION: This is used by the RIPE Database administration
when transferring pre-RIR registrations from the ARIN Database. The
value can be changed by database users (except for ALLOCATED PA). Only
the RIPE Database administrators can create objects with this value.

NOT-SET: This indicates that the registration was made before the
"status:" attributes became mandatory for inetnum objects. The object
has not been updated since then. New objects cannot be created with
this value. The value can be changed by database users.

ASSIGNED PA: This address space has been assigned to an End User for
use with services provided by the issuing LIR. It cannot be kept when
terminating services provided by the LIR.

ASSIGNED PI: This address space has been assigned to an End User and
can be kept as long as the criteria for the original assignment are
met.

The creation of an inetnum object with a status of "ASSIGNED PA" or
"ASSIGNED PI" is only possible if there is no less specific or more
specific inetnum object with an "ASSIGNED" status.

Address space without an explicit type in the "status:" attribute is
assumed to be PI. LIRs must clearly mark all new assignments in the
RIPE Database with either "PA" or "PI" as appropriate.

The RIPE NCC no longer allocates PI address space. Consequently, many
LIRs do not have PI allocations from which to make PI assignments. If
an LIR has an End User that requires PI address space they are able to
support them by sending these requests to the RIPE NCC on behalf of
the End User. This support includes helping End Users prepare a
properly documented request. The RIPE NCC will make PI assignments
when justified.

10.0 Record Keeping

All documentation related to an IP address request and sub-allocation
or assignment must be maintained by the LIR for future reference. This
data is needed for the evaluation of subsequent requests for the same
organisation, for audits by the RIR, and for the resolution of any
questions that may arise regarding assignments. The records must
include:

* The original request
* All supporting documentation
* All related correspondence between the LIR and the End User
* The assignment decision, including the reasons behind any unusual decision
* The details of the person responsible for making the decision
  
The history of events and the people responsible should be clearly
recorded. In order to help the exchange of information, it is strongly
recommended that documents are kept electronically and are readily
accessible. If requested, any of this information should be made
available to the RIPE NCC in English.

11.0 LIR Audit

The RIPE community asked the RIPE NCC to audit LIR operations and
ensure consistent and fair implementation of the community's
policies. Details of this activity are described in the RIPE document
"RIPE NCC Consistency and Auditing Activity" found at:

http://www.ripe.net/ripe/docs/audit.html 

12.0 Closing an LIR by the RIPE NCC

The RIPE NCC may close an LIR for any of the following reasons:

* the LIR does not pay money owed to the RIPE NCC
* the LIR cannot be contacted by the RIPE NCC for a significant  period of time
* the LIR consistently violates the RIPE community's policies 

The RIPE NCC takes on responsibility for address space held by closing LIRs. 



Information on training courses and training material can be found at:

http://www.ripe.net/training/