- Legend
- Added
- Deleted
Introduction
Abstract
This document describes the procedures for the delegation of au-
thority of zones in the 193.in-addr.arpa domain. As of March
16th 1993 the RIPE NCC has been delegated the authority for the
193.in-addr.arpa domain from the root. Due to the fact that in
the 193.x.y address space blocks of 256 class C network numbers
are further delegated to local registries , the possibility ex-
ists to also delegate the zone for these blocks in the 193.in-
addr.arpa domain.
Information on the Address Policy WG is available at:
http://www.ripe.net/ripe/groups/wg/ap Link: /community/wg/active-wg/ap/
Contents
1.1 Scope Link: #11
2.0 IPv4 Address Space Link: #2
3.0 Goals of the Internet Registry System Link: #3
4.0 Registration Requirements Link: #4
5.0 Policies and Guidelines for Allocations Link: #5
5.1 Allocations made by the RIPE NCC to LIRs Link: #51
5.2 Unforeseen circumstances Link: #52
5.3 Address Recycling Link: #53
5.5 Transfers of Allocations Link: #55
6.0 Policies and Guidelines for Assignments Link: #6
6.1 Assignments to Internet Exchange Points Link: #61
6.2 Network Infrastructure and End User Networks Link: #62
6.3 Validity of an Assignment Link: #63
6.4 Transfers of PI space Link: #64
7.0 Types of Address Space Link: #7
9.0 Closing an LIR by the RIPE NCC Link: #9
1.0 Introduction
The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. 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 Link: /community/internet-governance/internet-technical-community/the-rir-system/ ".
1.1 Scope
This document describes some guidelines andprocedures for this type of delegation and the delegation of re-
verse zones for individual class C networks in 193.x.y.
A bit more explained
With the assignment of class C network numbers following the CIDR
(RFC 1338) model, in which large chunks of the address space are
delegated to one region, and within that region blocks of class C
network numbers are delegated to service providers and non-
provider registries, some hierarchy in
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/policy Link: http://www.ripe.net/ripe/docs/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:
Public IP addresses are distributed to be globally unique according to the goals described in Section 3 of this document. The two types of IPv4 address described in this documents are Provider Aggregatable (PA) and Provider Independent (PI).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 Link: 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 Link: ftp://ftp.ripe.net/rfc/rfc2993.txtSome 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 Link: 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.Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.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.
5.1 Allocations made by the RIPE NCC to LIRs
Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC Link: /membership/member-support/become-a-member/ "
On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
The size of the allocation made will be exactly one /22.The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).The LIR must confirm it will make assignment(s) from the allocation.
In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.
5.2 Unforeseen circumstances
A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it.
In the event that this /16 remains unused at the time the remaining addresses covered by this policy have been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document.
5.3 Address Recycling
Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1.
This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.
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 7.0.
LIRs wishing to convert their allocations to PA status should contact the RIPE NCC by email at [email protected] Link: mailto:[email protected] .
LIRs may make sub-allocations to multiple downstream network operators.
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.
created, similar to the hierarchy in the domain name space. Due
to this hierarchy the reverse Domain Name System mapping can also
be delegated in a similar model as used for the normal Domain
Name System. For instance, the RIPE NCC has been assigned the
complete class C address space starting with 193. It is there-
fore possible to delegate the 193.in-addr.arpa domain completely
to the RIPE NCC, instead of each and every reverse mapping in the
193.in-addr.arpa domain to be registered with the INTERNIC. This
implies that all 193.in-addr.arpa resistrations will be done by
the RIPE NCC. Even better, since service providers receive com-
plete class C network blocks from the RIPE NCC, the RIPE NCC can
delegate the reverse registrations for such complete blocks to
these local registries. This implies that customers of these
service providers no longer have to register their reverse domain
mapping with the root, but the service provider have authority
over that part of the reverse mapping. This decreases the work-
load on the INTERNIC and the RIPE NCC, and at the same time in-
crease the service a provider can offer its customers by improve
response times for reverse mapping changes . However there are
some things that need to be examined a bit more closely to avoid
confusion and inconsistencies. These issues are covered in the
next section.
Procedures for the delegation of direct subdomains of 193.in-
addr.arpa
1. A secondary nameserver at ns.ripe.net is mandatory for all
blocks of class C network numbers delegated in the 193.in-
addr.arpa domain.
2. Because of the increasing importance of correct reverse ad-
dress mapping, for all delegated blocks a good set of secondaries
must be defined. There should be at least 2 nameservers for all
blocks delegated, excluding the RIPE NCC secondary.
3. The delegation of a class C block in the 193.in-addr.arpa
domain can be requested by sending in a domain object for the
RIPE database to <[email protected]> with all necessary contact
and nameserver information. The RIPE NCC will then forward all
current reverse zones inside this block to the registry, and
after addition of these by the registry, the NCC will check the
working of the reverse server. Once everything is setup proper-
ly, the NCC will delegate the block, and submit the database ob-
ject for inclusion in the database. An example domain object can
be found at the end of this document.
4. All reverse servers for blocks must be reachable from the
whole of the Internet. In short, all servers must meet similar
connectivity requirements as top-level domain servers.
5. Running the reverse server for class C blocks does not imply
that one controls that part of the reverse domain, it only im-
plies that one administers that part of the reverse domain.
6. Before adding individual nets, the administrator of a reverse
domain must check wether all servers to be added for these nets
are indeed setup properly.
7. There are some serious implications when a customer of a ser-
vice provider that uses address space out of the service provider
class C blocks, moves to another service provider. The
5.5 Transfers of Allocations
Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System.
Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC.
Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.
LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.
The RIPE NCC will record the change of allocation after the transfer.
The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.
The list will contain information about approved and non-approved transfers.
The following information will be published for approved transfers:
the name of the transferring party,the block originally held by the transferring party,the name(s) of the receiving party or parties,each subdivided prefix (each partial block derived from that original block) transferred,the date each prefix was transferred.
Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published
the number of requested transfers not approved after the RIPE NCC's evaluation,the sum of the number of addresses included in the requested transfers.Neither the blocks nor the organizations involved will be identified in these statistics.
Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied.
Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.
6.0 Policies and Guidelines for Assignments
6.1. Assignments to Internet Exchange Points
A /16 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive one number resource (/24 to /22) according to the following:
This space will be used to run an IXP peering LAN; other uses are forbidden.Organisations receiving space under this policy must be IXPs and must meet the definition as described in section two of the RIPE document "IPv6 Address Space for Internet Exchange Points".IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment.New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined.IP space returned by IXPs will be added to the reserved pool maintained for IXP use.Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN.
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 Users.
An explanation of how to register objects in the database can be found in the "RIPE Database User Manual: Getting Started" found at:
6.3 Validity of an Assignment
An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database. Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid. An assignment that was based on information that turns out to be incorrect is no longer valid.
6.4 Transfers of PI space
Any holder of Provider Independent (PI) address space is allowed to re-assign complete or partial blocks of IPv4 address space that were previously assigned to them by the RIPE NCC.
Address space may only be re-assigned in accordance with the RIPE Policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region Link: http://www.ripe.net/ripe/docs/contract-req ”.
Re-assignments must be reflected in the RIPE Database. This re-assignment can either be on a permanent or non-permanent basis.
Parties that receive a re-assignment from another party cannot re-assign complete or partial blocks of the same address space to another party within 24 months of receiving the re-assignment.
The RIPE NCC will record the change of PI assignment after the transfer.
The RIPE NCC will publish a separate list of all PI assignments transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.
The list will contain information about approved and non-approved transfers.
The following information will be published for approved transfers:
The name of the transferring partyThe block originally held by the transferring partyThe name(s) of the receiving party or partiesEach subdivided prefix (each partial block derived from that original block) transferredThe date each prefix was transferred
Non-approved transfers will be published in aggregate statistics. In the statistics the following information will be published:
The number of requested transfers not approved after the RIPE NCC's evaluationThe sum of the number of addresses included in the requested transfers
Neither the blocks nor the organizations involved will be identified in these statistics.
Please note that the transferring party always remains responsible for the entire assignment it receives from the RIPE NCC until the transfer of address space to another party is completed or if the address space is returned.
Re-assigned blocks are no different from PI assignments made directly by the RIPE NCC and so must be used by the receiving party according to the policies described in this document.
7.0 Types of Address Space
service provider cannot force its ex-customer to change network
addresses, and
Clear contractual arrangements are mandatory for PA space. End Users requesting PA space should be given this or a similar warning:
delegation records for reverse mapping of these addresses, even
though it they are no longer belonging to a customer.
8. The registration of the reverse zones for individual class C
networks will usually be done by the registry administering the
class C block this network has been assigned from. The registry
will make the necessary changes to the zone, and update the net-
work objects in the RIPE database for these networks, to reflect
the correct "rev-srv" fields. In case the RIPE NCC receives a
request for the reverse zone of an individual class C network out
of a block that has been delegated, the request will be forwarded
to the zone contact for this reverse block.
9. The NCC advises the following timers and counters for direct
subdomains of 193.in-addr.arpa: 8 hours refresh (28800 seconds),
2 hours retry (7200 seconds), 7 days expire (604800 seconds) and
1 day Time To Live (86400 seconds). The retry counter should be
lowered where connectivity is unstable.
Above procedures are defined to ensure the necessary high availa-
bility for the 193 reverse domains, and to minimize confusion.
The NCC will ensure fast repsonse times for addition requests,
and will in principle update the 193.in-addr.arpa domain at least
once per working day.
Example domain object to request a block delegation
domain: 202.193.in-addr.arpa
descr: Pan European Organisations class C block
admin-c: Daniel Karrenberg
tech-c: Marten Terpstra
zone-c: Marten Terpstra
nserver: ns.eu.net
nserver: sunic.sunet.se
nserver: ns.ripe.net
changed: [email protected] 930319
source: RIPE
Procedures for the delegation of individual network zones by the
RIPE NCC.
The registration of the reverse zones for individual class C net-
works will usually be done by the registry administering the
class C block this network has been assigned from. In case the
zone corresponding to the class C block
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.
the RIPE NCC will automatically add the reverse nameserver as
specified in the "rev-srv" attribute of the RIPE database object
for this network, using the following procedures:
1. Because of the increasing importance of correct reverse ad-
dress mapping, for all delegated networks a good set of secon-
daries must be defined. There should be at least two nameservers
for all networks delegated.
2. The "rev-srv" field should ONLY contain one fully qualified
domain name of a nameserver which is authoritative for the re-
verse zone for this network.
3. If a network has or is going to have any external connectivi-
ty, it is strongly recommended that it has at least one reverse
nameserver that can be reached from all of the Internet.
4. The checking and addition of the reverse zones for single net-
works is completely automated at the RIPE NCC. Although we do
our best to check the setup of the nameservers, these does not
receive the same level of scrutiny as nameservers for blocks of
class C network numbers. It is the responsibility of the network
contacts to ensure proper operation.
5. Any problems regarding the reverse zones in 193.in-addr.arpa
should be directed to <[email protected]>.
The NCC also suggests that similar procedures are set up for the
delegation of reverse zones for individual class C networks from
the registries to individual organisations.
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 for a specific purpose. It cannot be used to make further assignments to other parties.
ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services.
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.
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.
The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.
8.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 Audit Activity" found at: http://www.ripe.net/ripe/docs/audit Link: http://www.ripe.net/ripe/docs/audit
9.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 NCCthe LIR cannot be contacted by the RIPE NCC for a significant period of timethe LIR consistently violates the RIPE community's policies
The RIPE NCC takes on responsibility for address space held by closing LIRs.