This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. It was developed through joint discussions among the APNIC, ARIN and RIPE communities.

Contents

1. Introduction
1.1. Overview
2. Definitions
2.1. Internet Registry (IR)
2.2. Regional Internet Registry (RIR)
2.3. National Internet Registry (NIR)
2.4. Local Internet Registry (LIR)
2.5. Allocate
2.6. Assign
2.7. Utilisation
2.8. HD-Ratio
2.9. End Site
3. Goals of IPv6 address space management
3.1. Goals
3.2. Uniqueness
3.3. Registration
3.4. Aggregation
3.5. Conservation
3.6. Fairness
3.7. Minimised Overhead
3.8. Conflict of Goals
4. IPv6 Policy Principles
4.1. Address space not to be considered property
4.2. Routability not guaranteed
4.3. Minimum Allocation
4.4. Consideration of IPv4 Infrastructure
5. Policies for allocations and assignments
5.1. Initial allocation
5.1.1. Initial allocation criteria
5.1.2. Initial allocation size
5.2. Subsequent allocation
5.2.1. Subsequent allocation criteria
5.2.2. Applied HD-Ratio
5.2.3. Subsequent Allocation Size
5.3. LIR-to-ISP allocation
5.4. Assignment
5.4.1. Assignment address space size
5.4.2. Assignments shorter than a /48 to a single End Site
5.4.3. Assignment to operator's infrastructure
5.5. Registration
5.6. Reverse lookup
5.7. Existing IPv6 address space holders
6. Anycasting TLD and Tier 0/1 ENUM Nameservers
7. IPv6 Provider Independent (PI) Assignments
7.1. IPv6 Provider Independent (PI) Assignments for LIRs
8. References
9. Appendix A: HD-Ratio
10. Appendix B: Background information
10.1. Background
10.2. Why a joint policy?
10.3. The size of IPv6's address space
10.4. Acknowledgment

1. Introduction

1.1. Overview

This document describes policies for the allocation and assignment of globally unique Internet Protocol version 6 (IPv6) address space.

[RFC 4291] designates 2000::/3 to be global unicast address space that the Internet Assigned Numbers Authority (IANA) may allocate to the RIRs. In accordance with [RFC 4291], IANA allocated initial ranges of global unicast IPv6 address space from the 2000::/3 address block to the RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies. All bits to the left of /64 are in scope.

This policy is subject to future review and potential revision, subject to continuing experience in the administration of IPv6.

2. Definitions

[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]

The following terms and their definitions are of particular importance to the understanding of the goals, environment and policies described in this document.

Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below.

2.1. Internet Registry (IR)

An Internet Registry is an organisation that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.

2.2. Regional Internet Registry (RIR)

Regional Internet Registries are established and authorised by respective regional communities and recognised by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions.

2.3. National Internet Registry (NIR)

A National Internet Registry primarily allocates address space to its members or constituents, which are generally LIRs organised at a national level. NIRs exist mostly in the Asia Pacific region.

2.4. Local Internet Registry (LIR)

A Local Internet Registry is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.

2.5. Allocate

To “allocate” means to distribute address space to IRs for the purpose of subsequent distribution by them.

2.6. Assign

To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.

2.7. Utilisation

The actual usage of addresses within each assignment may be low when compared to IPv4 assignments. In IPv6, "utilisation" is only measured in terms of the bits to the left of the efficiency measurement unit (/56). In other words, "utilisation" effectively refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual End Site assignments.

Throughout this document, the term "utilisation" refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual subnets within those End Sites.

2.8. HD-Ratio

The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an adaptation of the H-Ratio originally defined in [RFC 1715] and is expressed as follows:

      Log (number of allocated objects)
HD = ----------------------------------------------
      Log (maximum number of allocatable objects)

where (in the case of this document) the objects are IPv6 site addresses assigned from an IPv6 prefix of a given size.

2.9. End Site

An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:

• that service provider assigning address space to the End User
• that service provider providing transit service for the End User to other sites
• that service provider carrying the End User's traffic
• that service provider advertising an aggregate prefix route that contains the End User's assignment

3. Goals of IPv6 address space management

3.1. Goals

IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the Internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.

3.2. Uniqueness

Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.

3.3. Registration

Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users.

The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.

3.4. Aggregation

Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs and to limit the expansion of Internet routing tables.

This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.

IPv6 address policies should seek to avoid fragmentation of address ranges.

Further, RIRs should apply practices that maximise the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.

3.5. Conservation

Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.

3.6. Fairness

All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor.

3.7. Minimised overhead

It is desirable to minimise the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.

3.8. Conflict of goals

The goals described above will often conflict with each other, or with the needs of individual IRs or End Users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.

In IPv6 address policy, the goal of aggregation is considered to be the most important.

4. IPv6 Policy Principles

To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below.

4.1. Address space not to be considered property

It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.

The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license.

RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment.

4.2. Routability not guaranteed

There is no guarantee that any address allocation or assignment will be globally routable.

However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.

4.3. Minimum allocation

The minimum allocation size for IPv6 address space is /32.

4.4. Consideration of IPv4 infrastructure

Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure.

5. Policies for Allocations and Assignments

5.1. Initial allocation

5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an organisation must:

a) be an LIR;

b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.

5.1.2. Initial allocation size

Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary.

Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure.

5.2. Subsequent allocation

Organisations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below.

5.2.2. Applied HD-Ratio

The HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilisation for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilisation value for a given address block size.

5.2.3. Subsequent allocation size

When an organisation has achieved an acceptable utilisation for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.

If an organisation needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.

5.3. LIR-to-ISP allocation

There is no specific policy for an organisation (LIR) to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.

5.4. Assignment

LIRs must make IPv6 assignments in accordance with the following provisions.

5.4.1. Assignment address space size

End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).

5.4.2. Assignments shorter than a /48 to a single End Site

When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level.

Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.

5.4.3. Assignment to operator's infrastructure

An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.

5.5 Registration

When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database.

These registrations can either be made as individual assignments or by inserting a object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users.When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'.

In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR' in such a way the RIR is able to calculate and verify the actual HD-ratio.

5.6. Reverse lookup

When an RIR/NIR delegates IPv6 address space to an organisation, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organisation should properly manage its reverse lookup zone. When making an address assignment, the organisation must delegate to an assignee organisation, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.

5.7. Existing IPv6 address space holders

LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without providing further documentation. 

The RIPE NCC should allocate the new address space contiguously with the LIRs’ existing allocations and avoid allocating non-contiguous space under this policy section.

6. Anycasting TLD and Tier 0/1 ENUM Nameservers

The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /48 prefixes per TLD and four /48 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC 4786.

Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".

Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services any longer.

7. IPv6 Provider Independent (PI) Assignments

To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.

The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets.

Additional assignments may also be made when the need is demonstrated and documented based on address usage, or because different routing requirements exist for additional assignments. When possible, these further assignments will be made from an adjacent address block.

Assignments will be made from a separate 'designated block' to facilitate filtering practices.

The PI assignment cannot be further assigned to other organisations.

7.1 IPv6 Provider Independent (PI) Assignments for LIRs

LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.

The LIR must return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid.

If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both.

8. References

[RFC 1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, ftp://ftp.ripe.net/rfc/rfc1715.txt

[RFC 2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC ftp://ftp.ripe.net/rfc/rfc2026.txt see Sec. 4.2.1

[RFC 2462] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T. Narten, 1998, ftp://ftp.ripe.net/rfc/rfc2462.txt

[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt

[RFC 2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000 ftp://ftp.ripe.net/rfc/rfc2928.txt

[RFC 3194] "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, ftp://ftp.ripe.net/rfc/rfc3194.txt

[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt

[RFC 4786] "Operation of Anycast Services",  J. Abley, K. Lindqvist. December 2006, ftp://ftp.ripe.net/rfc/rfc4786.txt

9. Appendix A: HD-Ratio

The utilisation threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6 prefix P, can be calculated as:

T = 2^((56-P)*HD)

Thus, the utilisation threshold for an organisation requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilisation refers to the use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.

In accordance with the recommendations of [RFC 3194], this document adopts an HD-Ratio of 0.94 as the utilisation threshold for IPv6 address space allocations.

The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94.

10. Appendix B: Background information

10.1. Background

The impetus for revising the 1999 provisional IPv6 policy started with the APNIC meeting held in Taiwan in August 2001. Follow-on discussions were held at the October 2001 RIPE and ARIN meetings. During these meetings, the participants recognised an urgent need for more detailed, complete policies. One result of the meetings was the establishment of a single mailing list to discuss a revised policy together with a desire to develop a general policy that all RIRs could use. This document does not provide details of individual discussions that lead to policies described in this document; detailed information can be found in the individual meeting minutes at the www.apnic.net, www.arin.net, and www.ripe.net web sites.

In September 2002 at the RIPE 43 Meeting in Rhodes, Greece, the RIPE community approved the policy allowing Internet experiments to receive temporary assignments. As a result, Section 6 was added to this document in January 2003.

10.2. Why a joint policy?

IPv6 addresses are a public resource that must be managed with consideration to the long-term interests of the Internet community. Although regional registries adopt allocation policies according to their own internal processes, address policies should largely be uniform across registries. Having significantly varying policies in different regions is undesirable because it can lead to situations where "registry shopping" can occur as requesting organisations request addresses from the registry that has the most favorable policy for their particular desires. This can lead to the policies in one region undermining the efforts of registries in other regions with regards to prudent stewardship of the address space. In cases where regional variations from the policy are deemed necessary, the preferred approach is to raise the issue in the other regional registries in order to develop a consensus approach that all registries can support.

10.3. The size of IPv6's address space

Compared to IPv4, IPv6 has a seemingly endless amount of address space. While superficially true, short-sighted and wasteful allocation policies could also result in the adoption of practices that lead to premature exhaustion of the address space.

It should be noted that the 128-bit address space is divided into three logical parts, with the usage of each component managed differently. The rightmost 64 bits, the Interface Identifier [RFC 4291], will often be a globally unique IEEE identifier (e.g., mac address). Although an "inefficient" way to use the Interface Identifier field from the perspective of maximizing the number of addressable nodes, the numbering scheme was explicitly chosen to simplify Stateless Address Autoconfiguration [RFC 2462].

The middle bits of an address indicate the subnet ID. This field may often be inefficiently utilised, but the operational benefits of a consistent width subnet field were deemed to be outweigh the drawbacks. This is a variable length field, determined by each LIR's local assignment policy.

10.4. Acknowledgment

The initial version of this document was produced by the JPNIC IPv6 policy drafting team consisting of Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this team, who worked over a holiday in order to produce an initial document quickly.

An editing team was then organised by representatives from each of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of the RIPE IPv6 Working Group).

The editing team would like to acknowledge the contributions to this document of Takashi Arano, John Crain, Steve Deering, Gert Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Wittbrodt and Wilfried Woe

Additionally, part of the RIPE NCC’s role is to guarantee that no other party aside from the resource holder can modify, delete or add registration information. Therefore, the RIPE NCC will deny any LEA’s request to modify, delete or add registration information, or to restrict a resource holder’s ability to do so, without a court order or other legally enforceable order or request under Dutch law.

When the RIPE NCC receives any such order or request, the RIPE NCC will examine it on its own merits and will inform those members it relates to, unless the order or request expressly forbids this from happening.

This document outlines the procedure the RIPE NCC will follow with regards to:

• Requests for information about individual members by LEAs
• Requests or orders by LEAs for specific action to be taken by the RIPE NCC
• Seizure of the RIPE NCC’s equipment or property as part of an LEA’s investigation

1. Requests for Information

The RIPE NCC distinguishes between the following two types of information:

• RIPE NCC member information that is publicly available
• RIPE NCC member information that is not publicly available, including members’ personal and organisational information and any other non-public information

1.1. RIPE NCC Member Information that is Publicly Available

RIPE NCC member information that is public can always be accessed by third parties, including LEAs. Such publicly available information may be any information that is accessible through the RIPE NCC website, including information or records that are public on the RIPE Database at the time of the request.

Upon request, an LEA will be directed to this information. In cases where the provision of this information to LEAs is critical for the understanding of the public registry and RIPE NCC operations in general, this information will be given directly by the RIPE NCC to the requesting party.

1.2. RIPE NCC Member Information that is not Publicly Available

The RIPE NCC does not provide member information that is not publicly available to LEAs on a voluntary basis.

Non-publicly available member information will only be provided to LEAs, if a Dutch court order or other legally binding order is presented by a Dutch LEA.

There are other Dutch authorities with the supervisory and investigative powers to request information from the RIPE NCC (such as the Dutch Data Protection Authority, the Netherlands Competition Authority, the Independent Post and Telecommunications Authority, the Public Prosecution Department, the Police, the Fiscal Intelligence and Investigation Service).

LEAs and other organisations operating outside of the Netherlands are required to follow the applicable mutual legal assistance treaties (MLAT) procedures.

The RIPE NCC will evaluate each order on its own merits. If an order is considered illegal or of a non-obligatory nature, the RIPE NCC will not comply with it and will challenge it either before the authority giving the order or before a civil or criminal court, depending on the specific circumstances.

A request may be served by email, fax, in person or by registered mail to the RIPE NCC’s legal address:

RIPE NCC
Singel 258
1016 AB Amsterdam
The Netherlands
Email: ncc@ripe.net
Fax: +31 20 535 4445

It is the RIPE NCC’s policy to notify members of requests (or other orders) for their data unless it is prohibited from doing so by statute or court order.

2. Requests or Orders for a Specific Action  

The RIPE NCC may be asked by LEAs to perform a specific action, for example a modification in the registration of specific Internet number resources. The RIPE NCC will not voluntarily comply with such requests.

The RIPE NCC will only comply with such requests if a Dutch Court order is served by a Dutch LEA, as well as a binding order from law-enforcement or regulatory authorities that are operating as required under Dutch criminal and administrative law (such as the Public Prosecution Department, the Police, the Fiscal Intelligence and Investigation Service).

Both law enforcement and other national authorities operating outside the Netherlands must follow the applicable mutual legal assistance treaties (MLAT) procedures.

Each order will be evaluated on its own merits. If an order is considered illegal or of a non-obligatory nature, the RIPE NCC will not comply with it and will challenge it either before the authority giving the order or before a civil or criminal court, depending on the specific circumstances.

An order may be served by email, fax, in person or by registered mail to the RIPE NCC’s legal address (as above).

It is the RIPE NCC’s policy to notify members of orders related to their data, unless it is prohibited from doing so by statute or court order.

3. Seizure of RIPE NCC Equipment or Property as Part of an Investigation

LEAs may order the seizure of equipment or property belonging to the RIPE NCC as part of an investigation.

In such cases, the RIPE NCC will examine the legitimacy of the investigation and the authorisation of the persons conducting the investigation or seizure (examining judge, public prosecutor or investigation officers).

The RIPE NCC will strive to ensure that the seizure is conducted in a manner that is the least detrimental to its operations and those of its members.

The RIPE NCC will immediately lodge a complaint with the court and will seek to secure an agreement from the authority ordering the seizure that it will await the outcome of the complaint before carrying out the seizure.

 This document outlines policies for temporary direct assignments of IPv4/IPv6 address space and Autonomous System (AS) Numbers in the RIPE NCC service region.

Contents

1.0 Introduction

2.0 Internet Registry Number Resource Pool Reservation

2.1 RIPE NCC Assignment Procedures

3.0 End User Term and Limitations

3.1 Assignment Time Limits

3.2 Realistic Expectations

3.3 IPv4 Address Utilisation Rate

3.4 Compliance with Other RIPE NCC Assignment Policies

4.0 Attribution

1.0 Introduction

This policy allows the RIPE NCC to assign number resources for temporary direct assignment purposes and, for this purpose, to reserve pools of IPv4/IPv6 addresses, AS Numbers and any other numbers for which it acts as Regional Internet Registry (RIR).

2.0 Internet Registry Number Resource Pool Reservation

The RIPE NCC is authorised to reserve pools of IPv4 addresses, IPv6 addresses, 16-bit AS Numbers and 32-bit AS Numbers for the purpose of direct assignment under this policy.

2.1 RIPE NCC Assignment Procedures

The RIPE NCC may assign number resources to End Users on a temporary deployment basis for a specific time-limited purpose. Examples of specific purposes include, but are not limited to, academic research and experimental purposes, conferences and other types of events which require network connectivity for short periods of time, and other strictly time-limited projects such as deployment tests for new Internet services and technologies.

Resources issued for temporary assignments must not be used for purposes other than those specified in the application, and they may be returned to the RIPE NCC at any time during the approved assignment period. The number resources will be automatically de-registered and returned to the appropriate reservation pool at the end of the approved assignment period.

The RIPE NCC will register the issued number resources in the RIPE Database for the duration of the assignment and will note the start and end dates of the assignment period for each database object.

3.0 End User Terms and Limitations

3.1 Assignment Time Limits

Depending on the specified purpose of the assignment request, different upper time limits may apply. For conferences and other events of short, fixed duration, the maximum assignment time period will be one month longer than the scheduled length of the conference/event but no longer than two months in any case.

For longer term projects and research purposes, the number resources may be issued on a temporary basis for a period of up to six calendar months, or one month longer than the expected life of the project/research/experiment, whichever is shorter.

In the case where an End User requires number resources for research purposes, and where the research project details are made public upon registration of the number resources by the RIPE NCC, and where the End User commits to making public the results of their research project free of charge and free from disclosure constraints, then the requested number resources may be issued for a period of up to one calendar year.

At the RIPE NCC’s discretion renewal of the registration of the resources may be possible in exceptional circumstances on receipt of a new request that details continuation of the End User's requirements during the extended period. Should this request be denied by the RIPE NCC, an appeal may be made using the RIPE NCC Conflict Arbitration Procedure.

3.2 Realistic Expectations

Assignments may only be based on realistic expectations recorded on the request form. The RIPE NCC may require the End User to provide documentation or other evidence supporting the End User's assignment request.

3.3 IPv4 Address Utilisation Rates

The utilisation rate of an assignment must be such that at least 50% of the total space applied for at the time of the assignment will be concurrently used at peak periods during the assignment.

3.4 Compliance with Other RIPE NCC Assignment Policies

In all respects not covered by this document, temporary assignment policies are subject to all other RIPE NCC policies regarding standard direct assignment of number resources.

4.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Nick Hilliard

% Temporary Internet Number Assignment Request Form
% RIPE NCC members (LIRs) can use this form to request
% a Temporary Internet Assignment. Please see "Supporting Notes for the Temporary
% Internet Assignment Request Form" for instructions on how to complete this form.
% http://ripe.net/ripe/docs/temp-assign-support 
%
% Please note that an End User should have a signed "Temporary Independent 
% Assignment Request and Maintenance Agreement" with a sponsoring LIR.
% http://ripe.net/lir-services/resource-management/temp-assign-agreement

#[GENERAL INFORMATION]#
% Please add your RegID.

request-type: temp-assign
form-version: 1.1
x-ncc-regid: 

#[ASSIGNMENT USER]#
% Who will use the requested assignment?
legal-organisation-name:      
organisation-location: 
website-if-available: 

% Is this request being sent by a sponsoring LIR on behalf of 
% an End User? (yes/no)

end-user-of-sponsoring-lir: 

% If yes, please confirm that the "Temporary Independent Assignment Request and
% Maintenance Agreement" contains all of the elements listed in paragraph 2.0 of
% "Contractual Requirements for Provider Independent Resource Holders in the 
% RIPE NCC Service Region".(yes/no) 
% Please also attach a copy of the signed agreement and the company registration
% papers of the End User.  

confirmation:

#[INITIAL INFORMATION]#

% Which type of assignment is the End User requesting? (IPv4/IPv6/ASN)

type-of-assignment:

% Why do you need this temporary assignment? 

why:

% The End User should be aware that this resource will be for a specific time      
% period and will be automatically de-registered at the end of the approved         
% assignment period. 
% Please add more information on the purpose (Event/Research) and duration of this  
% request. 

purpose: 
website-if-available:

% The date should be in the following format: yyyymmdd

start-date:
end-date:

% The next three sections (IPv4, IPv6 and ASN) will give us an overview of the      
% detailed usage of the resources. Please fill in only the relevant      
% sections as per the resource being requested and remove the sections that are not    
% applicable.

#[IPv4 section]#
% 
% Why is PI address space required rather than PA address space?

why-pi-v4:

% Is the End User requesting extra address space for routing and/or 
% administrative reasons? If yes, explain why.

why-routing-v4:

% Please confirm if the End User is aware of the consequences and disadvantages 
% of PI address space? (yes/no)
% For details, you can refer to section 8.0 “PA vs. PI Address Space” of the IPv4  
% Address Allocation and Assignment Policies.

confirmation-v4:

% ADDRESSING PLAN
% How will the End User use this IPv4 address space?
% 
%       Subnet       Immediate    Intermediate  Entire   Purpose
%       size (/nn)   Requirement  Requirement   Period
subnet:
subnet:
totals:
number-of-subnets: 

#[IPv6 section]#
%
% Why is PI address space required rather than PA address space?

why-pi-v6:

% Is the End User requesting extra address space for routing and/or 
% administrative reasons? If yes, explain why.

why-routing-v6:

% Please confirm if the End User is aware of the consequences and disadvantages 
% of PI address space? (yes/no)
% For details, you can refer to section 8.0 “PA vs. PI Address Space” of the IPv4  
% Address Allocation and Assignment Policies.

confirmation-v6:

%ADDRESSING PLAN
% How will the End User use this IPv6 address space?
% 
%       Subnet       Immediate    Intermediate  Entire   Purpose
%       size (/nn)   Requirement  Requirement   Period
subnet:
subnet:
totals:
%

#[ASN section]#

%[ADDRESS SPACE TO BE ANNOUNCED]%
% If this ASN will originate other prefixes than are requested 
% in this request, please list these below.

prefix-asn:
 
% If you require a 16-bit AS Number instead of a 32-bit AS Number, 
% please indicate this below and tell us why. For more information,
% see http://www.ripe.net/news/asn-32-guide.html

as-number-type: 32-bit [change as required]
why-16-bit:

% Please list the Autonomous System Numbers and email contact addresses
% of the peering partners.

peering-asn:
peering-asn:

#[SUPPORTING DOCUMENTATION]#

% Please add more information if you think it will help us understand
% this request. You can attach a network diagram or other relevant
% supporting documentation.

%<add more information>
#[DATABASE TEMPLATE IPv4]#
%
% If you are requesting IPv4, complete this IPv4 database template.
% If you are not requesting IPv4, please remove this IPv4 database template. 

inetnum:        <leave empty>
netname:        <add netname>
descr:          <add End User organisation name>
country:        <add country code>
org:            <add org-ID>
admin-c:        <add nic-handle of administrative contact>
tech-c:         <add nic-handle of technical contact>
status:         ASSIGNED PI
remarks:       Temporary assignment
              ===========================================
               Duration of assignment:
              ===========================================
                Start date:
                End date:
              ==========================================
mnt-by:         RIPE-NCC-END-MNT
mnt-lower:      RIPE-NCC-END-MNT
mnt-by:         <add mntner name>
mnt-routes:     <add mntner name>
mnt-domains:    <add mntner name>
changed:        hostmaster@ripe.net
source:         RIPE 

#[DATABASE TEMPLATE IPv6]#
%
% If you are requesting IPv6, complete this IPv6 database template.
% If you are not requesting IPv6 please remove this IPv6 database template. 

inet6num:        <leave empty>
netname:        <add netname>
descr:          <add End User organisation name>
country:        <add country code>
org:            <add org-ID>
admin-c:        <add nic-handle of administrative contact>
tech-c:         <add nic-handle of technical contact>
status:         ASSIGNED PI
remarks:       Temporary assignment
              ===========================================
               Duration of assignment:
              ===========================================
                Start date:
                End date:
              ==========================================
mnt-by:         RIPE-NCC-END-MNT
mnt-lower:      RIPE-NCC-END-MNT
mnt-by:         <add mntner name>
mnt-routes:     <add mntner name>
mnt-domains:    <add mntner name>
changed:        hostmaster@ripe.net
source:         RIPE 

#[DATABASE TEMPLATE ASN]#
%
% If you are requesting ASN, complete this ASN database template.
% If you are not requesting ASN, please remove this ASN database template. 

aut-num:       ASNEW 
as-name:       <add name for the AS>
descr:         <add AS Number User name>
org:           <add org-ID>
import:        <specify the outgoing routing policy for the first peer>
export:        <specify the incoming routing policy for the first peer>  
import:        <specify the outgoing routing policy for the second peer>
export:        <specify the incoming routing policy for the second peer>   
admin-c:       <add nic-handle of administrative contact>
tech-c:        <add nic-handle of technical contact>
remarks:       Temporary assignment
              ===========================================
               Duration of assignment:
              ===========================================
                Start date:
                End date:
             ============================================
mnt-by:        RIPE-NCC-END-MNT
mnt-by:        <add mntner name>
mnt-routes:    <add mntner name>
changed:       hostmaster@ripe.net
source:        RIPE

#[END of REQUEST]#

The instructions are based on the following policy documents:

1. IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region
2. IPv6 Address Allocation and Assignment Policy
3. Autonomous System (AS) Number Assignment Policies
4. Temporary Internet Number Assignment Policies
5. Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region

• General Information
• Assignment User
• Initial Information
• IPv4 Section
• IPv6 Section
• ASN Section
• Supporting Documentation
• Database Template(s)
• End of Request

General Information

#[GENERAL INFORMATION]#
% Please add your RegID.
request-type: temp-assign
form-version: 1.1
x-ncc-regid: nl.bluelight

Please do not change the value of the "request-type:" and "form-version:" fields.

Enter your Registry Identifier (RegID) in the "x-ncc-regid:" field. RegIDs have the following format: <country code>.<name>. If you do not know your RegID, please contact ncc@ripe.net.

Assignment User

#[ASSIGNMENT USER]#
% Who will use the requested address space?
legal-organisation-name: North SantaBank
organisation-location: Santa City, NN
website-if-available: http://www.nsb.nn
% Is this request being sent by a sponsoring LIR on behalf of 
% an End User? (yes/no)

end-user-of-sponsoring-lir: Yes

% If yes, please confirm that the "Temporary Independent Assignment Request and
% Maintenance Agreement" contains all of the elements listed in paragraph 2.0 of
% "Contractual Requirements for Provider Independent Resource Holders in the 
% RIPE NCC Service Region".(yes/no) 

% Please also attach a copy of the signed agreement and the company registration
% papers of the End User.  

confirmation:Yes

Enter the legal name and primary location of the organisation that will use this PI address space in the "legal-organisation-name" and "organisation-location" fields. If this End User has a website, enter the URL in the "website-if-available" field. Otherwise, enter "none" in this field.

If you are an LIR sending this request on behalf of an End User, you should answer "Yes" in the "end-user-of-sponsoring-lir" field.

If you answered "Yes" you should also confirm that all of the elements of paragraph 2.0 of "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" are listed in the “End User Assignment Agreement” that is signed by the End User and the sponsoring LIR. For all temporary assignments that are requested through a sponsoring LIR for an End User, we need to receive a copy of "Temporary Independent Assignment Request and Maintenance Agreement" and the company registration papers of the End User.

You can find an example agreement at: 
http://ripe.net/lir-services/resource-management/temp-assign-agreement

You can send us an agreement in your local language or use the English version.

If the request is for an LIR, you should also answer with "No".

Initial Information

#[INITIAL INFORMATION]#

% Which type of assignment is the End User requesting? (IPv4/IPv6/ASN)

type-of-assignment: IPv4/IPv6/ASN

% Why do you need this temporary Assignment? 
why: Assignment is needed for our annual banking conference and exhibition that will take place end of this month in Geneva. The conference and exhibition will take place simultaneously at the same location.

% The End User should be aware that this resource will be for a specific time
% limit. It will be automatically de registered at the end of the approved
% assignment period. 
% Please add more information on the purpose(Event/Research) and duration of this
% request. 

purpose: Event
website-if-available: http://www.nsb.nn/conference/2012

% The date should be in the following format: yyyymmdd

start-date: 20120325
end-date: 20120329

In the type of assignment field, you should indicate all the different resources you are requesting for your End User with this request.

In the "Why:" field, you need to tell us why you are requesting this temporary assignment as well as explain the detailed technical requirements of the requested resources/size.

You should also indicate the purpose of the assignment, including the website of the mentioned event/research and the start and end dates of the event/research.

IPv4 section

#[IPv4 section]#
%
% Why is PI address space required rather than PA address space? 

why-pi-v4: North Santa will be multihomed. We cannot use PA address space because our uplinks do not allow their address space to be announced by other Autonomous Systems.

% Is the End User requesting extra address space for routing and/or 
% administrative reasons? If yes, explain why?

why-routing-v4:

% Please confirm if the End User is aware of the consequences and disadvantages 
% of PI address space? (yes/no)
% For details, you can refer to section 8.0 “PA vs. PI Address Space” of the IPv4
% Address Allocation and Assignment Policies.

confirmation-v4: Yes

In the "why-pi:" field, explain why PA address space cannot be used for this assignment. Remember that you should encourage the use of PA address space where possible.

If the End User is requesting extra address space for routing and/or administrative reasons, then you need to explain how much address space is being requested due to this and explain the reasons behind it.

You must ensure that the End User understands and accepts that PI address space may be more difficult or more expensive to route than PA address space and then confirm this in the "confirmation:" field. You can find more details on the consequences and disadvantages of PI address space in the document "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region" under section 8.0 “PA vs. PI Address Space”.

% ADDRESSING PLAN
% How will the End User use this IPv4 address space?
% 
%       Subnet      Immediate    Intermediate  Entire      Purpose
%       size (/nn)  Requirement  Requirement   Period
subnet: /24,/25,/26 /24,/25,/26  /24,/25,/26  /24,/25,/26 Laptops/wifi-enabled devices
subnet: /26         /26          /26           /26         Servers, Routers, Switches, firewalls and Workstations
totals: /23         /23          /23           /23 

number-of-subnets: 2

The addressing plan shows how the End User will use the requested IPv4 address space. Please note that during peak periods, at least 50% of the total address space applied for must be used at the same time.

You can repeat the "subnet" row as many times as needed. Delete any empty "subnet" fields before you send the request. In the "Subnet size (/nn)" column, enter a slash notation prefix for each subnet. Each entry should be large enough to contain the number of addresses needed for that subnet over the next time period. In order to demonstrate the predicted growth of the network, you must provide an estimate of the address space you will require over three distinct periods: Immediate, Intermediate and the Entire period.

Your estimates should include interfaces used for hosts, routers, gateways, terminal concentrators and any other machines requiring one or more network interfaces. These columns can either contain numbers (for example, 64) or slash notation prefixes (for example, /26). Multiple slash notation prefixes must be separated by comma(s) with no blank spaces (for example, /24,/25,/26). In the "Purpose" column, write a short description of each subnet. In the "totals" row, add the totals of each column. The total of the "Subnet size (/nn)" column should be the total amount of address space you are requesting for this assignment. In the "number-of-subnets" field, enter the total number of subnets listed in the addressing plan.

IPv6 section

#[IPv6 section]#
%
% Why is PI address space required rather than PA address space? 

why-pi-v6: North Santa will be multihomed. We cannot use PA address space because our uplinks do not allow their address space to be announced by other Autonomous Systems.

% Is the End User requesting extra address space for routing and/or 
% administrative reasons? If yes, explain why.

Why-routing-v6:

% Please confirm if the End User is aware of the consequences and disadvantages 
% of PI address space. (Yes/No)
% For details, you can refer to section 8.0 “PA vs. PI Address Space” of the IPv4
% Address Allocation and Assignment Policies.

confirmation-v6: Yes

In the "why-pi:" field, explain why PA address space cannot be used for this assignment. Remember that you should encourage the use of PA address space where possible. If the End User is requesting extra address space for routing and/or administrative reasons, then you need to explain how much address space is being requested due to this and explain the reasons behind it. You must ensure that the End User understands and accepts that PI address space may be more difficult or more expensive to route than PA address space and then confirm this in the "confirmation:" field. You can find more details on the consequences and disadvantages of PI address space in the document "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region" under section 8.0 “PA vs. PI Address Space”.

% ADDRESSING PLAN
% How will the End User use this IPv6 address space?
% 
%       Subnet       Immediate    Intermediate  Entire   Purpose
%       size (/nn)   Requirement  Requirement   Period
subnet: /60          /60          /60           /60      Servers for Banking applications
totals: /60          /60          /60           /60

The addressing plan shows how the End User will use the requested address space. You can repeat the "subnet" row as many times as needed. Delete any empty "subnet" fields before you send the request. Enter the size of each subnet in the "Subnet size (/nn)" column using IPv6 slash notation (for example, /60). In the "Purpose" column, write a short description of each subnet. In the "totals" row, add the totals of each column.

The smallest IPv6 PI assignment size issued by the RIPE NCC is /48.

ASN section

#[ASN section]#

%[ADDRESS SPACE TO BE ANNOUNCED]%
% If this ASN will originate other prefixes than are requested in this request,
% please list these below.

prefix-asn:
 

If you are not requesting temporary address space for this End User in this ticket, please specify all address prefixes using slash notation (for example, x.x.x.x/xx ). The address space must be a valid assignment to the organisation that will use the AS number.

% If you require a 16-bit AS Number instead of a 32-bit AS Number 
% please indicate this below and tell us why. For more information,
% see http://www.ripe.net/news/asn-32-guide.html

as-number-type: 16-bit 
why-16-bit: Our routers are not 32-bit enabled

As of 1 January 2009, all AS Numbers assigned by the RIPE NCC will be 32-bit by default. If you require a 16-bit AS Number, change the default entry "32-bit" to "16-bit" and explain why you require a 16-bit AS Number. If you require further clarification, please see:
http://www.ripe.net/news/asn-32-guide.html

% PEERING CONTACTS
% Please list the Autonomous System Numbers and email contact addresses of the
% peering partners.

peering-asn: AS64532, noddy@grottoinvestments.nn
peering-asn: AS64518, mary@northernbanking.nn

You must list the email addresses and ASN of at least two peering partners in the "peering:" fields. You can repeat the "peering:" field as many times as needed.

Supporting Documentation

#[SUPPORTING DOCUMENTATION]#
% Please add more information if you think it will help us understand this request.
% You can attach a network diagram or other relevant supporting documentation.
% <add more information> 
There are already 350 participants that have registered for the conference and address space is needed for their laptops and other devices (ipads, smart phones etc). We also need addresses for network devices like switches, firewalls, routers, 10 servers (2 IPs each). There will also be an Internet cafe with 25 workstations in the exhibition area for exhibition attendees only. 

As IPv6 is the future of the Internet, we would like to use it for few servers where we will host certain banking/financial applications.

If you would like to include additional information on the technical requirements, deployment plan, detailed usage or total users/equipment count, you can use this section.
A network diagram (topology map) can help us to understand the set-up of the network and its addressing needs. For information on “Submission of topology maps”, refer to: http://www.ripe.net/lir-services/resource-management/submission-of-topology-maps

Database Template(s)

#[DATABASE TEMPLATE IPv4]#
%
% If you are requesting IPv4, complete this IPv4 database template. If you are not
% requesting IPv4, please remove this IPv4 database template. 

inetnum:     <leave empty>
netname:     NSB-NET-v4
descr:       North SantaBank
country:     NN
org:         ORG-NS31-RIPE
admin-c:     ACM2-RIPE
tech-c:      HOHO1-RIPE
status:      ASSIGNED PI
remarks:     Temporary assignment
             ===================
             Duration of assignment:
             =====================
             Start date:
             End date:
             =====================
mnt-by:      RIPE-NCC-END-MNT
mnt-lower:   RIPE-NCC-END-MNT
mnt-by:      SANTA-MNT
mnt-routes:  SANTA-MNT
mnt-domains: SANTA-MNT
changed:     hostmaster@ripe.net
source:      RIPE

#[DATABASE TEMPLATE IPv6]#
% If you are requesting IPv6, complete this IPv6 database template. If you are not
% requesting IPv6 please remove this IPv6 database template. 

inet6num:    <leave empty>
netname:     NSB-NET-v6
descr:       North SantaBank
country:     NN
org:         ORG-NS31-RIPE
admin-c:     ACM2-RIPE
tech-c:      HOHO1-RIPE
status:      ASSIGNED PI
remarks:     Temporary assignment
             =====================
             Duration of assignment:
             =====================
             Start date:
             End date:
             =====================
mnt-by:      RIPE-NCC-END-MNT
mnt-lower:   RIPE-NCC-END-MNT
mnt-by:      SANTA-MNT
mnt-routes:  SANTA-MNT
mnt-domains: SANTA-MNT
changed:     hostmaster@ripe.net
source:      RIPE

#[ DATABASE TEMPLATE ASN]#
% If you are requesting ASN, complete this ASN database template. If you are not

% requesting ASN, please remove this ASN database template. 

aut-num:    ASNEW
as-name:    NSB-AS
descr:      North SantaBank
org:        ORG-NS31-RIPE
import:     from AS64532 accept ANY
export:     to AS64532 announce ASNEW
import:     from AS64518 accept ANY
export:     to AS64518 announce ASNEW
remarks:    Temporary assignment
            =====================
            Duration of assignment:
            =====================
            Start date:
            End date:
            =====================
admin-c:    ACM2-RIPE
tech-c:     HOHO1-RIPE
mnt-by:     RIPE-NCC-END-MNT
mnt-by:     SANTA-MNT
mnt-routes: SANTA-MNT
changed:    hostmaster@ripe.net
source:     RIPE 

If the End User is requesting IPv4, IPv6 and an ASN, please complete all templates. If not, you should complete the relevant template(s) and delete the rest when sending the request.

Leave the "inetnum/inet6num/aut-num" field empty as we will choose the address range or the ASN.

The "netname/as-name:" should be a short and descriptive name for the network and should reflect the organisation name of the End User.

Enter the End User's legal organisation name in the "descr:" field.

Use the ISO country code of the End User's location in the "country:" field. If the End User is multi-national, repeat the "country" field as many times as needed.

Enter the org-ID of the End User's organisation object in the "org:" field.

If they don't have an organisation object, you can create one for them using the LIR Portal (https://lirportal.ripe.net).

The nic-handle of the role or person object in the "admin-c:" field should reflect someone who is administratively responsible for the network.

The nic-handle of the role or person object in the "tech-c:" field should reflect someone who has technical knowledge of the network.

The "status:" field must be ASSIGNED PI.

The "import:" and "export:" fields should contain the complete routing policy. Both fields may be repeated as many times as needed.

Basic syntax entries are as follows:

import: from <peer1> accept <filter>
export: to <peer1> announce <filter>
import: from <peer2> accept <filter>
export: to <peer2> announce <filter> 

For further details of language specifications, please refer to RFC 2622.

The “remarks” fields will contain details of this temporary assignment and will be completed by the RIPE NCC.

The "mnt-by:" and "mnt-lower:" fields must contain RIPE-NCC-END-MNT.

The second "mnt-by: " field shows which maintainer authenticates object updates.

The "mnt-routes:" and "mnt-domains:" fields show which maintainers authenticate the creation of route and domain objects.

The RIPE Database must contain all of the objects that you use.

The "changed:" field must be hostmaster@ripe.net.

The "source:" field must be RIPE.

End of Request

Best Regards,
Jan Janssen, Bluelight Admin

Please write your full name below the "#[END of REQUEST]#" header.

The instructions are based on the “IPv4 Address Allocation and Assignment Policy for the RIPE region”.

LIRs should send separate “Provider Aggregatable (PA) Assignment Request” forms for each End User.

• General Information
• Address Space User
• Addressing Plan
• Equipment Description
• Network Description
• Network Diagram
• End of Request

General Information

#[GENERAL INFORMATION]#
%
% Please add your RegID.
%
% request-type: pa-ipv4
form-version: 1.3
x-ncc-regid:  nl.bluelight

Please do not change the value of the “request-type:” and “form-version:” fields.

Enter your Registry Identifier (RegID) in the “x-ncc-regid:” field. RegIDs have the following format: <country code>.<name>. If you do not know your RegID, please contact <ncc@ripe.net>.

Address Space User

#[ADDRESS SPACE USER]#
%
% Who will use the requested address space?
%
% legal-organisation-name: North SantaBank 
organisation-location:   Santa City, NN
website-if-available:    http://www.nsb.nn
%
%  Does this End User already have address space that can be
% used for this assignment? (Yes/No)
%
% space-available: No

Enter the legal name and primary location of the organisation that will use this address space in the “legal-organisation-name:” and “organisation-location:” fields. If this End User has a website, enter the URL in the “website-if-available:” field. Otherwise, enter “none” in this field.

If there is any address space assigned to this End User that is not in use, indicate this in the “space-available:” field. If you answer “yes”, you can explain why the End User needs another assignment of address space in the “Network Description” section at the end of this form.

Addressing Plan

#[ADDRESSING PLAN]#
% How will the End User use this address space?
%
%       Subnet       Immediate    Intermediate  Entire      Purpose
%       size (/nn)   Requirement  Requirement   Period

subnet: /26             32            64          64        Employee VPN Access
subnet: /26             18            34          64        Financial Services
subnet: /26             22            30          60        Workstations
subnet: /27             11            15          28        Public Services
subnet: /27              7            18          30        Operations
subnet: /24            176           192         240        Branch Offices
totals: /23            266           353         486                   

number-of-subnets: 6

% Will the End User return any address space?

address-space-returned: 85.118.187/24 to nl.bluelight in 3 months

The addressing plan shows how the End User will use the requested address space. You can repeat the "subnet" row as many times as needed. Delete any empty "subnet" fields before you send the request. In the "Subnet size (/nn)" column, enter a slash notation prefix for each subnet. Each entry should be large enough to contain the number of addresses needed for that subnet over the next time period.

In order to demonstrate the predicted growth of your network, you must provide an estimate of the address space you will require over three distinct periods: Immediate, Intermediate and the Entire period. Your estimates should include interfaces used for hosts, routers, gateways, terminal concentrators and any other machines requiring one or more network interfaces. These columns can either contain numbers (for example, 128) or slash notation prefixes (for example, /25). Multiple slash notation prefixes must be separated by comma(s) with no blank spaces (for example, /25,/27).

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.

In the “Purpose” column, write a short description of each subnet. If needed, you can write a more detailed description in the “Network Description” section at the end of this form.

In the “totals” row, add the total of each column. The total of the “Subnet size (/nn)” column should be the total amount of address space you are requesting for this assignment.

In the “number-of-subnets:” field, enter the total number of subnets listed in the addressing plan.

The “netname:” should be a short, descriptive name for the network and should reflect the End User’s organisation name. You should use the same “netname:” when you register this assignment in the RIPE Whois Database.

If there is any address space assigned to the End User that they will return, list each prefix in separate “address-space-returned:” fields. The expected time for renumbering is three months. You can use the following syntax: <x.x.x.x/xx> to <which LIR/ISP> in <time period> for this field.

Equipment Description

#[EQUIPMENT DESCRIPTION]#
%
% What equipment will be used and how will it use the 
% requested address space?
equipment-name:    Core switches
manufacturer-name: Cisco
model-number:      25xx
other-data:        3 units
equipment-name:    Servers
manufacturer-name: HP
model-number:      various
other-data:        40 units
equipment-name:    Firewalls
manufacturer-name: Cisco
model-number:      PIX 515 E
other-data:        2 units, 8 IP addresses
equipment-name:    Workstations
manufacturer-name: Dell
model-number:      GX150
other-data:        22 units, 1 IP address each
equipment-name:    Routers
manufacturer-name: Cisco
model-number:      3825
other-data:        2 units
equipment-name:    Routers
manufacturer-name: Cisco
model-number:      AS5300
other-data:        1 unit, 32 ports

The equipment description will help us (RIPE NCC) to understand the requirements listed in the addressing plan and can be repeated as many times as needed. Leave an empty line before each new “equipment-name:” field.

In the “equipment-name:” field, enter the type of equipment requiring address space from this assignment.

Enter the vendor name and model number for the piece of equipment in the “manufacturer-name:” and “model-number:” fields.

If you have any more information about how this piece of equipment will use the requested address space, add this in the “other-data:” field.

Network Description

#[NETWORK DESCRIPTION]#
%
% Please add more information if you think it will help us 
% understand this request.
We have 11 branches across Santa City linked by corporate fibre channels.
We will assign a /28 subnet for each branch. 
Each branch will have SMTP, WWW, file server, e-banking and dial-up pool.
Public Internet Services: SMTP (2 IP addresses), 
WWW (6 IP addresses, 2 servers), FTP (1 IP address), DNS (2 IP addresses)
Financial Services: 6 servers, 3 IP addresses each.
Operations network: Security, Monitoring, VPN, Proxy, DNS

You can use this space for additional information that you think will be helpful for us when we evaluate your request. A clearer understanding of the network and its addressing needs can help us to evaluate your request more quickly.

Network Diagram

#[NETWORK DIAGRAM]#
%
% Have you attached a network diagram to this request? (Yes/No)

diagram-attached: Yes                   

A network diagram (topology map) can help us to understand the set-up of the network and its addressing needs.

End of Request

#[END of REQUEST]#

Best Regards,
Jan Janssen, Bluelight Admin

Please write your full name below the “#[END of REQUEST]#” header.

% Provider Aggregatable (PA) Assignment Request Form


% RIPE NCC members can use this form to request a PA assignment. Please see 
% ripe-584 for instructions on how to complete this form.


#[GENERAL INFORMATION]#
%
% Please add your RegID.

request-type: pa-ipv4
form-version: 1.3
x-ncc-regid: 


#[ADDRESS SPACE USER]#
%
% Who will use the requested address space?

legal-organisation-name:      
organisation-location: 
website-if-available: 

% Does this End User already have address space that can be
% used for this assignment? (Yes/No)

space-available: 




#[ADDRESSING PLAN]#
% How will the End User use this address space?
%
%       Subnet       Immediate    Intermediate  Entire   Purpose
%       size (/nn)   Requirement  Requirement   Period        

subnet:
subnet:
totals:

number-of-subnets: 

% Which netname will you use for this assignment?

netname:

% Will the End User return any address space?

address-space-returned: 


#[EQUIPMENT DESCRIPTION]#
%
% What equipment will be used and how will it use the requested
% address space?

equipment-name:
manufacturer-name:
model-number:
other-data:

equipment-name:
manufacturer-name:
model-number:
other-data:


#[NETWORK DESCRIPTION]#
%
% Please add more information if you think it will help us understand
% this request.


<add more information>


#[NETWORK DIAGRAM]#
%
% Have you attached a network diagram to this request? (Yes/No)

diagram-attached:


#[END of REQUEST]#

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/groups/wg/ap

Contents

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

5.5 Transfers of Allocations

5.6 Use of last /8 PA 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

6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers

6.10 Provider Independent IPv4 Assignments for Multihoming

7.0 Assignment Window

8.0 PA vs. PI Address Space

9.0 Record Keeping

10.0 LIR Audit

11.0 Closing an LIR by the RIPE NCC

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".

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/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:

1. 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.
2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
3. 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.
4. 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.

The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months.

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 First Allocation

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

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

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

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 by email 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 up to an IPv4 /20 (4096 addresses) to a downstream network operator every twelve months.

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

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. 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.

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 either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC, following the policies set for receiving further allocations within RIPE region (see the Section 5.3 Additional Allocations of this document).

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 will be signed to establish the current allocation owner.

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.

5.6 Use of last /8 for PA Allocations

The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:

1. Allocations for LIRs from the last /8

   On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

   1. LIRs may only receive one allocation from this /8.  The size of the allocation made under this policy will be exactly one /22.
   2. LIRs receive only one /22, even if their needs justify a larger allocation.
   3. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application.
   4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

2. Assignments to Internet Exchange Points

A /16 from the final /8 will be held in reserve for exclusive use by Internet Exchange Points.  On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one number resource (/24 to /22) according to the following:

• This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.
• Organisations receiving space under this policy must be Internet Exchange Points 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 Internet Exchange points will be assigned a /24.  Internet exchange points may return this /24 (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment.
• IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use.
• Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN

3. 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 /8 covered by this policy has been distributed, it returns to the pool to be distributed as per clause 1.

4. Post-depletion Address Recycling

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.

1. Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in clause 1.

2. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary

5. Insufficient address space

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.

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/request-forms-supporting-notes

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:

http://www.ripe.net/data-tools/support/documentation/getting-started

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 Audit Activity” found at:

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

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.

6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers

The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /24 prefixes per TLD and four /24 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC 4786 (http://www.ietf.org/rfc/rfc4786.txt).

Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".

Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for authoritative TLD or ENUM Tier 0/1 DNS lookup services via anycast any longer.

6.10 Provider Independent IPv4 Assignments for Multihoming

The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24 if an End User demonstrates: 

• the need for Provider Independent (PI) IPv4 address space; and
• the intent to announce this address space for the purpose of multihoming to two or more Autonomous Systems which the End User does not own or control

Cumulatively, no more than 255 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined above.

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/request-forms-supporting-notes

All new LIRs start with an AW of zero (0). Their AW will automatically be set to a /21 (2048 addresses) six months after receiving their first allocation. This means that all new LIRs need to request approval before making each assignment until their AW has been raised.

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 or a downstream network operator as the user of a sub-allocation 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 RIPE NCC staff. LIRs may approach the RIPE NCC for an evaluation of their AW six months after receiving their first allocation and at any time after that. 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 judgment 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 judgment 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 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 must be returned and the network renumbered.

In contrast, Provider Independent (PI) address space is assigned to End Users directly from the address pools managed directly by the RIPE NCC. PI space cannot be re-assigned or further assigned to other parties. PI address space can only remain assigned to a network as long as the criteria for the original assignment are maintained.  Additionally, all new PI address space assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

As PI addresses are not assigned from LIR-allocated PA address blocks, they cannot be aggregated on the public Internet. Consequently, they are expensive to route, and therefore may 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 and is also subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

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.
• 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.

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.

9.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.

10.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

11.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/lir-services/training

Contents

1.0 Definition

2.0 Introduction

3.0 Reverse Delegation in the RIPE NCC Service Region

4.0 Procedures

5.0 References

6.0 Attribution

1.0 Definition

1.1 Reverse delegation: The process by which the authority for certain reverse DNS zones is assigned to a specific set of DNS servers.

1.2 Early registration: IPv4 address space assigned or allocated before the establishment of the Regional Internet Registries (RIRs).

2.0 Introduction

The RIPE NCC provides the necessary support to enable resolution of IPv4 and IPv6 address space into domain names. This service is implemented under the in-addr.arpa and ip6.arpa sub-domains described in [1] and [2].

3.0 Reverse Delegation in the RIPE NCC Service Region

The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC.

The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database.

Address space holders may delegate authority to another party.

4.0 Procedures

The procedures related to reverse delegation and information about the requirements the RIPE NCC enforces are published at:

http://www.ripe.net/reverse/

5.0 References

[1] [RFC 3172] "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"

[2] [RFC 3596] "DNS Extensions to Support IP Version 6", [RFC 3363] “Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System”, [RFC 3364] “Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version (IPv6)”

6.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed to this policy by making proposals through the RIPE Policy Development Process:

Olaf Kolkman
Leo Vegoda

History and Background

Analysis

Recommendations

References and Further Reading

Introduction

Route Flap Damping (RFD) [1] is a mechanism for BGP speaking routers that penalises prefixes that exhibit a large number of updates (‘flapping’), and suppresses a route when the accumulated penalty exceeds a given threshold.  The penalty decays over time until it reaches a lower threshold at which point the route is unsuppressed. RFD is intended to improve the overall stability of the Internet routing table and reduce the load on BGP speaking routers. In ripe-378 [2] it was stated that due to the dynamics of BGP, especially a phenomenon called ‘path hunting,’ the default configurations of flap damping can do more harm than good as it may suppress a prefix after it has only flapped a few times. Consequently RFD was deprecated due to the problem of over damping (see [2] for more details).

A small number of prefixes on the Internet continue to flap rapidly and cause a disproportionate number of updates to BGP and load on BGP speaking routers.  This document uses experimental data gathered from an operational environment to suggest changes to the RFD parameters to suppress the prefixes that flap the most, while minimising the suppression of other prefixes.

This document suggests parameters which would make RFD usable and is based around the work of Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush, and Keyur Patel presented at PAM2011[3].

History and Background

In the early 1990s the accelerating growth in the number of prefixes being announced to the Internet (often due to inadequate prefix aggregation), the denser meshing through multiple inter-provider paths, and increased instabilities started to cause significant impact on the performance and efficiency of some Internet backbone routers. Every time a routing prefix altered state because of a single line-flap, the withdrawal was advertised to the whole BGP-Speaking Zone (BSZ) and handled by every router that carried the full Internet routing table.

The load this processing placed on the control planes of routers caused further instability as the routers were not able to process other BGP updates or they dropped traffic transiting the device. This could produce cyclic crashing behaviour.

To overcome this situation RFD was developed in 1993 and has since been integrated into most router BGP software implementations. RFD is described in detail in RFC 2439[1].

When RFD was first implemented in commercial routers, vendor implementations had different default values and different characteristics. As this inconsistency would result in different rates of flap damping, and therefore introduce inconsistent path selection and behavior that was hard to diagnose, the operator community introduced a consistent set of recommendations for flap damping parameters, so that ISPs deploying RFD would treat flapping prefixes in the same way.

This call for consistency resulted in the RIPE Routing Working Group producing first ripe-178, then ripe-210, and finally the ripe-229 documents [2a].  The parameters documented in ripe-229 were considered, at  time of publication in 2001, the best current practice. In 2006, this was reviewed again and resulted in ripe-378 [2] which recommended to disable RFD because it created more harm than good.

Analysis

In the work by Pelsser et al [3], it is shown that 3% of all prefixes cause 36% of BGP updates, and just 0.01% of the prefixes cause 10% of the BGP updates.  The aim is to only penalise those prefixes with excessive numbers of updates.

The default values used in current implementations of RFD apply a penalty of 1000 each time a route flaps, and suppresses the prefix when the penalty exceeds a figure in the region of 2000 (Cisco IOS) or 3000 (Juniper JunOS).

The table shows the percentage of prefixes above the suppress threshold and the percentage reduction in BGP churn for various values of suppress threshold.  The current default suppress value of 2000 reduces BGP churn by 47%, but it suppressed 14% of the prefixes at some point over the lifetime of the experiment. Significantly larger values of suppress threshold such as 12000, 15000 or 18000 still reduced BGP churn, but suppressed far fewer prefixes which it is believed reduces the risk of penalising otherwise well-behaved prefixes.

Recommendations

In order to punish the biggest offenders - those prefixes that flap the most – yet without punishing others, the RIPE Routing-WG recommends vendors raise the maximum suppress threshold in router implementations to 50,000 and operators configure a suppress threshold value of at least 6,000.   The vendors might also change the default suppress threshold to 6,000.  But this might surprise operators who use the default.

This has a number of advantages:

• it is easy to implement
• it will reduce the churn compared to the situation we havenow where no RFD is applied
• it spares the smaller offenders.

Changing the default suppress threshold could result in an increase in forwarding table size or announcement rate for operators who use RFD with the default settings.  This warrants further discussion.

References and Further Reading

[1] Curtis Villamizar, Ravi Chandra, Ramesh Govindan

RFC2439: BGP Route-flap Damping (Proposed Standard)

ftp://ftp.ietf.org/rfc/rfc2439.txt

[2] Most recent RIPE Document

ftp://ftp.ripe.net/ripe/docs/ripe-378.txt

[2a] Older RIPE Documents

ftp://ftp.ripe.net/ripe/docs/ripe-178.txt

ftp://ftp.ripe.net/ripe/docs/ripe-210.txt

ftp://ftp.ripe.net/ripe/docs/ripe-229.txt

[3] Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush and Keyur Patel. "Route Flap Damping Made Usable". PAM 2011, March 2011.

http://www.iij-ii.co.jp/en/lab/researchers/cristel/publications/Pelsser-RFD-PAM2011.pdf

[4] Zhouqing Mao, Ramesh Govindan, George Varghese, Randy Katz

Route-flap Damping Exacerbates Internet Routing Congerence SIGCOMM 2002

http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf

[5] Randy Bush, Tim Griffin, Zhouqing Mao Route-flap Damping: Harmful?

NANOG 26

http://www.nanog.org/mtg-0210/ppt/flap.pdf

[6] Craig Labovitz, Abha Ahuja, Abhijit Bose, Farnam Jihanian

Delayed Internet Routing Convergence SIGCOMM 2000

http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf

1.0 Definitions

2.0 Introduction

3.0 Transfer of Internet Number Resource Records

3.1 Submission of the Request

3.2 If the Receiving Party is not yet a Member

3.3 Billing Issues

3.4 Internet Number Resource Registration and RIPE Database Issues

4.0 The Member Changes its Official Legal Name

1.0 Definitions

For the purposes of this document Internet Number Resource records refer to:

• The registered allocations and assignments of a Member
• The independent Internet Number Resources assigned through the Member as a “sponsoring LIR” to an End User

2.0 Introduction

In order for the RIPE NCC to maintain an accurate registry, it must hold accurate data concerning:

• The natural or legal persons holding the registration of Internet Number Resources
• The Internet Number Resource records that are registered to the natural or legal persons

This means that any transfer of Internet Number Resources from one party to another, or any change to the legal status of a party holding the registration of Internet Number Resources, must be communicated to the RIPE NCC.

The Member must inform the RIPE NCC if one or both of the following changes occurs:

1. Internet Number Resource records are transferred. Such transfers may take place:
   • Because of a change in the business structure of the Member, for example in the case of a merger or acquisition of the Member’s organisation; or
   • In the case of a pure transfer of an allocation from a Member to another Member according to RIPE Policies (section 5.5, IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region). Such a transfer may also be facilitated through the RIPE NCC Listing Service

1. The Member changes its official legal name. Such a change may occur, for example, because of a merger or acquisition of the Member’s organisation.

This document describes the procedures to be followed for such changes to be properly communicated to, and registered with, the RIPE NCC.

Note:

If a change in the Member’s official legal name is accompanied by a transfer of Internet Number Resource records, the Member must first inform the RIPE NCC of the name change and then of the transfer.

If a change in the Member’s business structure is not accompanied by a transfer of Internet Number Resource records or a change in the Member’s official legal name, then the RIPE NCC does not need to be informed of this change.

3.0 Transfer of Internet Number Resource Records

If a Member transfers their Internet Number Resource records to a third party for any reason, this transfer must be declared to, and approved by, the RIPE NCC.

3.1 Submission of the Request for Transfer

One of the involved parties must submit a request by email to the RIPE NCC for the transfer to be executed:

• If the transfer is due to a change in the business structure of the Member (e.g. merger or acquisition), the request must be submitted to ncc@ripe.net
• If the transfer is a transfer of allocation from one Member to another Member according to RIPE Policies (section 5.5, IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region), the request must be submitted to lir-help@ripe.net

A registered contact or an authorised person (e.g. senior manager, legal successor) must send the request.

The RIPE NCC will ask for the following information:

i. Information regarding the parties involved, including:

• The full official legal names of all parties involved
• Which party will transfer the Internet Number Resource records and which party will receive them
• Recent registration papers issued by the relevant national authorities for all involved parties

If the current official legal names of the involved Members are different from the ones in the relevant signed RIPE NCC Standard Service Agreement, then the procedure described under section 4.0 must be followed prior to the transfer of the Internet Number Resource records. The procedure described under section 4.0 is not necessary for the transferring Member if the RIPE NCC Standard Service Agreement of the transferring Member is terminated (see Closure of LIR and Deregistration of Internet Number Resources, section A.1.1. and section A.1.2.).

ii. A description of the reason for the transfer (for example, due to merger, acquisition, or transfer of allocation according to the RIPE policies)

If the transfer is taking place due to a change in the structure of the organisation(s) involved, a description of the changes among the organisation(s) is necessary. The description must be accompanied by all official legal documents proving/supporting the changes the request is based on.

iii. A list of the Internet Number Resource records that are requested to be transferred. If all of the transferring Member’s Internet Number Resource records registered are being transferred, a confirmation of this is requested.

The Member must also indicate any End User assignment agreements that are requested to be transferred.

If a Member transfers all of their Internet Number Resource records, the RIPE NCC Standard Service Agreement of the Member may be terminated (see Closure of LIR and Deregistration of Internet Number Resources, section A.1.1.).

iv. The correct contact details of all organisations involved

The RIPE NCC may ask the organisations involved to confirm the correctness of their contact details or to update them. The contact details include the billing contact details and the VAT number details.

v. A Transfer Agreement signed by both parties or by their legal successors

The RIPE NCC will make a template of the Transfer Agreement available. Either party may submit the Transfer Agreement to the RIPE NCC, signed by authorised persons for both parties. The RIPE NCC may ask the other party/parties to confirm their agreement to the transfer. The confirmation must be authorised (signed or sent) by a contact person or authorised person (e.g. senior manager, legal successor).

If the transferring party no longer exists by the time the RIPE NCC is being informed, the receiving party must send:

• An official document (issued by a national authority) confirming the closure of the transferring party; and
• A copy of an older signed agreement between the relevant parties mentioning the transfer of the Internet Number Resource records. If such an agreement is not available, the receiving party must send confirmation of the transfer to the RIPE NCC signed by an authorised person (e.g. senior manager, legal successor). The RIPE NCC reserves the right to reverse the transfer should another party object to this transfer and provide an agreement that proves that the Internet Number Resource records should have been transferred to them

vi. An overview of the utilisation of all allocations and of the status of all independent Internet Number Resource assignments

The RIPE NCC may ask for an overview of the utilisation of all Internet Number Resources registered to the Member and of all End User assignment agreements signed by the Member.

3.2 The Receiving Organisation is not yet a Member

Members may wish to transfer their Internet Number Resource records to another Member or to an organisation that is not yet a Member.

If the Internet Number Resource records are transferred to a non-Member, the receiving organisation can:

• Apply to be a Member by signing the RIPE NCC Standard Service Agreement before the transfer takes place (more information on how to become a Member is available); or
• Undertake all rights and obligations from the RIPE NCC Standard Service Agreement signed by the transferring Member. This might happen if all Internet Number Resource records are transferred. The transferring party is then no longer considered to be a Member

If the receiving organisation refuses to do either of the above, the RIPE NCC will not transfer the Internet Number Resource records to them.

The request for the transfer can be submitted as described in section 3.1.

3.3 Financial Consequences

All outstanding invoices and all outstanding financial obligations must be paid in full. If the RIPE NCC Standard Service Agreement is terminated in the course of the RIPE NCC financial year, the service fee for this Member must be paid for the full year. The payment is the responsibility of the receiving Member.

If the receiving organisation decides to sign the RIPE NCC Standard Service Agreement, then a sign-up fee must be paid (see RIPE NCC Charging Scheme).

3.4 Internet Number Resource Registration and RIPE Database Issues

The RIPE NCC will review the status of any IP address allocation or independent Internet Number Resource assignment maintained by the organisations involved in compliance with the RIPE Policies current at the time of the transfer.

The receiving Member must deregister from the RIPE Database any invalid or overlapping registrations or unused assignment approvals.

The RIPE NCC will update the registry, including all RIPE Database objects maintained by the RIPE NCC that are related to this transfer. The transferring Member must update all RIPE Database objects maintained by them that are related to this transfer.

4.0 The Member Changes its Official Legal Name

It is the obligation of the Member to inform the RIPE NCC immediately if any change in the Member’s official legal name occurs.

The Member must send an email to ncc@ripe.net informing the RIPE NCC of the name change. This email must include:

• New registration papers from the national authority; and
• The official legal documents supporting this change

The RIPE NCC will send a new RIPE NCC Standard Service Agreement for the Member to sign under the new official legal name. When the RIPE NCC receives the new RIPE NCC Standard Service Agreement properly signed by the Member, it will update the registry, including all RIPE Database objects maintained by the RIPE NCC that are related to this change. The Member must update all RIPE Database objects maintained by them that are related to this change.

Section B describes the valid reasons for deregistration of Internet number resources and the procedure that applies in each circumstance.

Table of Contents

A. Closure of Member – Termination of the RIPE NCC Standard Service Agreement

1. Grounds for termination and procedure in each case

1.1. Termination by the Member

1.2. Termination by the RIPE NCC

1.2.1. Termination with a three-month notice period

1.2.1.1. Violation of RIPE Policies and RIPE NCC procedures

a. Unresponsiveness

b. Allocations/assignments contravening RIPE Policies

c. Incorrect registration in the RIPE Database

d. Non-compliance with an arbiter ruling

1.2.1.2 Other reasons

1.2.2. Termination with immediate effect

a. Member files for bankruptcy, is liquidated, suspends its payments or becomes insolvent

b. Member damages the name, trademarks or intellectual property rights of the RIPE NCC

c. Member fails to submit to the RIPE NCC a valid extract from the Commercial Trade Register or equivalent register

d. The Member fails to observe any rule of applicable law

e. Non-payment

f. Termination of the RIPE NCC member status

g. Untruthful information

h. Non-compliance with RIPE NCC audit

i. Discontinuation of RIPE NCC services

2. Consequences

2.1. End of provision of RIPE NCC services

2.1.1. General services

2.1.2. Registration of distributed Internet number resources

2.1.3. Request for independent Internet number resources as a “sponsoring LIR”

2.2. End of RIPE NCC member status

B. Deregistration of Internet number resources

1. Reasons for deregistration of Internet number resources - Allocations and Independent Internet number resources assigned for the Member’s own network or assigned through a “sponsoring LIR”

a. Termination of the SSA

b. Invalidity of original allocation/assignment criteria

c. Incorrect registration of the allocation/assignment in the RIPE Database

d. Falsified/incorret information

e. Fraudulent request

f. Non-compliance with a RIPE NCC audit

g. Court order

h. Independent Internet number resources assigned through a “sponsoring LIR” without a valid contractual relationship

2. Procedures for deregistration of different types of Internet number resources

2.1. Allocations and Independent Internet number resources for Member’s own network

2.2. Independent Internet number resources assigned through a “sponsoring LIR”

A. Closure of Member - Termination of the RIPE NCC Standard Service Agreement

An organisation or an individual person can receive services from the RIPE NCC if they:

• Agree and sign the RIPE NCC Standard Service Agreement (SSA); and

• Conform to RIPE Policies.

An organisation or an individual person signing the SSA is called a “Member”. The RIPE NCC SSA is entered into for an indefinite period of time, unless terminated by either party.

1. Grounds for termination and procedure in each case

The SSA can be terminated by the Member (see section 1.1) or by the RIPE NCC. The termination by the RIPE NCC can either be with a notice period of three months (see section 1.2.1.) or for specific reasons with a shorter notice period and immediate effect (see section 1.2.2.).

1.1. Termination by the Member

According to Article 9.2 of the SSA, the Member can terminate the SSA with a notice period of three months. Possible reasons why Members might want to terminate their SSA include:

• The Member decides to close or to change their business

• The Member decides to merge with another Member and therefore they do not need to be Members themselves

• The Member decides to assign Internet number resources from another Member

Procedure

The notice will formally request the termination of the SSA.

It must be:

• Dated and signed by an authorised representative of the Member. A registered contact cannot give notice unless the registered contact is an authorised representative.

• Sent to the RIPE NCC by email to <ncc@ripe.net> or by postal mail to: RIPE NCC, Singel 258, 1016 AB Amsterdam, The Netherlands.

The RIPE NCC will send an acknowledgement of the receipt of the notice. Upon receipt of such notice, the progress of any open requests for RIPE NCC services is terminated.

The termination of the SSA will take place three months after the receipt of the notice by the RIPE NCC.

Billing issues

If the termination takes place in the course of a financial year, the annual contribution shall nevertheless remain due in full by the Member (see also paragraph 6.6 of the RIPE NCC Articles of Association (AoA) and the RIPE NCC Billing Procedure).

1.2. Termination by the RIPE NCC

1.2.1. Termination with a three-month notice period

According to Article 9.3 of the SSA, the RIPE NCC can terminate the SSA with a notice period of three months. Grounds for such termination may be the following:

1.2.1.1 Violation of RIPE Policies and RIPE NCC procedures

The Member must comply with RIPE Policies and RIPE NCC procedures (see Article 6 of the SSA). The RIPE NCC will terminate the SSA if the Member commits any of the following violations of RIPE Policies or RIPE NCC procedures:

1. Unresponsiveness

   The Member is unresponsive for a significant period of time.

   Members are considered to be unresponsive if they do not react to a specific email/request made by the RIPE NCC relating to an incorrect/ambiguous registration of Internet number resources, regardless of whether they are at the same time responsive to a different email/request from the RIPE NCC or they continue paying the RIPE NCC fees.

2. Allocations/assignments contravening RIPE policies

   Allocations or transfers of allocations and assignments are not made and used in accordance with the RIPE community’s policies.

3. Incorrect registration in the RIPE Database

   Registration data is repeatedly maintained incorrectly (allocations and assignments must be properly registered in the RIPE Database).

   Proper registration must be as follows:

   • The inetnum and the inet6num object(s) for approved assignments must use the netname(s) approved by the RIPE NCC and not be larger than the size approved by the RIPE NCC

   • The date in the first “changed:” attribute must not be earlier than the date of approval from the RIPE NCC

   • The data must be valid and must allow the RIPE NCC to contact the natural person referenced directly in the inetnum or inet6num object(s) or via the maintainers of the inetnum or inet6num object(s) within a reasonable time without having to get information from another source

4. Non-compliance with an arbiter ruling

   For more information, please see RIPE NCC Conflict Arbitration Procedure.

Procedure

If the RIPE NCC becomes aware of any of the aforementioned reasons for terminating the SSA, the RIPE NCC will:

• Send an email to the registered contact(s) indicating:

• the violation

• the Member’s obligation to stop/repair the violation

• the termination of the SSA in three (3) months if the violation continues

• Terminate the progress of any open requests for RIPE NCC services

If the Member does not comply within 30 days of the date of the email, the RIPE NCC will send a reminder email to the registered contact(s) indicating:

• The violation

• The Member’s obligation to stop/repair the violation

• The termination of the SSA in two (2) months if the violation continues

After 60 days from the date of the first email, if the Member still does not comply, the RIPE NCC will send a second reminder email and a reminder by postal mail to the registered email and email addresses indicating:

• The violation

• The Member’s obligation to stop/repair the violation

• The termination of the SSA in one (1) month if the violation continues

After 90 days from the date of the first email, if the Member continues not to comply, the RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

The RIPE NCC concludes the SSA and provides services to Members in good faith. The Member is in breach of good faith in the following cases:

1.2.1.2. Other reasons

Termination for any other reason by the RIPE NCC is only executed when the Member consents to the termination, unless the termination is for reasons above and beyond control of the RIPE NCC.

For example, such termination has taken place in the past in the case of the emergence of AfriNIC, the RIR for the African region, when, with the consent of the African Members, the SSAs with the RIPE NCC were terminated and new contracts with AfriNIC were signed.

Procedure

The notice will officially inform about the termination of the SSA, state the reasons for the termination and detail the planned arrangements regarding the Internet number resources that were distributed to the Member.

Unless otherwise required by the circumstances:

• The RIPE NCC will terminate the progress of any open requests for RIPE NCC services

• Section A.2. (Consequences of termination of the SSA) and section B (Deregistration of Internet number resources) of this document are applicable

The notice will be dated and signed by an authorised representative of the RIPE NCC.

Notice will be sent to the registered contact(s) of the Member by electronic and postal mail.

Upon receipt of such notice, the progress of any open requests for RIPE NCC services is terminated. The termination of the SSA will take place after three months from the date the RIPE NCC sends the notice, unless the Member requests a longer period and this is agreed upon.

Billing issues

All outstanding amounts for the full year must be settled unless otherwise agreed.

1.2.2. Termination with immediate effect

According to Article 9.4 of the SSA, the RIPE NCC is entitled to terminate the SSA with immediate effect in the following cases:

1. Member files for bankruptcy, is liquidated, suspends its payments or becomes insolvent

   Upon receipt of the documents stating the bankruptcy, liquidation, suspension of payments or insolvency of the Member

   by the relevant authority or by public announcement of the fact, the RIPE NCC will terminate the SSA. If the relevant national authority decides that the Member’s operations can continue, and provided that the Member fulfills the obligations coming from the SSA, the RIPE NCC will not terminate the SSA.

   Procedure

   The RIPE NCC will:

   • Send an email to the registered contact(s) and/or to the legal successor indicating:

     • The reason for termination of the SSA

     • The immediate termination of the SSA

   • Terminate the progress of any open requests for RIPE NCC services

   The RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the member) to all registered contacts of the Member or to the legal successor, both by electronic and registered postal mail.

2. Member damages the name, trademarks or intellectual property rights of the RIPE NCC

   Examples:

   • The Member pretends to be, or to act on behalf of, the RIPE NCC through misuse of the RIPE NCC name or logo

   • The Member unreasonably makes allegations against the RIPE NCC in order to damage the RIPE NCC’s reputation and operations, resulting in irreversible damage to the RIPE NCC

   Procedure:

   The RIPE NCC will

   • Send an email to the registered contact(s) indicating:

     • the violation

     • the Member’s obligation to stop/repair the violation

     • the termination of the SSA if the violation continues

   • Terminate the progress of any open requests for RIPE NCC services

   If the Member does not comply within 30 days of the date of the email, the RIPE NCC will send a reminder email to the registered contact(s) indicating the same as above.

   After 60 days from the date of the first email, if the Member still does not comply, the RIPE NCC will:

   • Send a second reminder email to the registered contact(s) indicating the same as above

   • Not approve any Internet number resource requests

   After 90 days from the date of the first email, if the Member continues not to comply, the RIPE NCC will:

   • Send a third reminder email and a reminder by postal mail to the registered email and postal addresses indicating the same as above

   • Stop providing any services to the Member

   After 120 days from the date of the first email, if the Member still does not comply, the RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

3. Member fails to submit to the RIPE NCC a valid extract from the Commercial Trade Register or equivalent register

   When initially signing the SSA, the Member must submit to the RIPE NCC an extract from the Commercial Trade Register or equivalent document providing the registration of the Member’s business with the national authorities (see Article 2.2 of the SSA).

   If the Member is a natural person, the RIPE NCC requires submission of any identification papers (passport, driving license or other official document proving the identity of the individual).

   If the Member is a legal person, identification papers are also required for the authorised person signing the SSA on behalf of the legal person.

   If there is any change in the Member’s business after signing the SSA (for example, the Member has merged with another company, has changed name, etc.) and, because of this change, the Member’s registration with the relevant register has been changed, then the Member is obliged to submit the updated registration papers to the RIPE NCC.

   If the Member does not submit the aforementioned documents within one month of them being requested by the RIPE NCC, the RIPE NCC will terminate the SSA (see Article 9.4.d of the SSA).

   Procedure

   The RIPE NCC will:

   • Send an email to the registered contact(s) indicating:

     • the Member’s obligation to submit the relevant documents

     • the termination of the SSA if the documents are not submitted

   • Terminate the progress of any open requests for RIPE NCC services

   If the Member does not comply within 15 days of the date of the email, the RIPE NCC will send a reminder email and a notification by postal mail to the registered email and postal addresses indicating the same as above.

   After 30 days from the date of the first email, if the Member continues not to comply, the RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

4. The Member fails to observe any rule of applicable law

   The SSA is exclusively governed by the laws of the Netherlands because the RIPE NCC is an association under Dutch law. The RIPE NCC is allowed to terminate the SSA of a Member with immediate effect, provided it receives a Dutch court order to do so.

   Procedure

   The RIPE NCC will:

   • Send an email to the registered contact(s) indicating:

     • The reason for termination of the SSA

     • The immediate termination of the SSA

   • Terminate the progress of any open requests for RIPE NCC services

   The RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

5. Non-payment.

   In case of non-payment, in accordance with the RIPE NCC Billing Procedure, the SSA is terminated after 120 days. For more information, please see the RIPE NCC Billing Procedure.

6. Termination of the RIPE NCC member status

   By signing the SSA, Members become members of the RIPE NCC association. If Members terminate their member status with the RIPE NCC association, the SSA is automatically terminated (see also Article 6 of the AoA).

   Procedure

   The RIPE NCC will:

   • Send an email to the registered contact(s) indicating:

     • The reason for termination of the SSA

     • The immediate termination of the SSA

   • Terminate the progress of any open requests for RIPE NCC services

   The RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

7. Untruthful information
   

   The RIPE NCC concludes the SSA and provides services to Members in good faith. The Member is in breach of good faith in the following cases:

   • Falsified/incorrect information

   If the Member repeatedly provides falsified data or information, or purposefully and/or repeatedly provides incorrect data or information (for example, falsified registration documents or IDs, incorrect/inaccurate contact details, etc.)

   • Fraudulent requests

   If the Member submits repeatedly fraudulent requests for Internet number resources (for example, providing incorrect purpose/need or falsified information about the network, etc.)

   Procedure

   The RIPE NCC will:

   • Send an email to the registered contact(s) indicating:

     • The reason for termination of the SSA

     • The immediate termination of the SSA

   • Terminate the progress of any open requests for RIPE NCC services

   The RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

8. Non-compliance with RIPE NCC audits
   

   Non-compliance with RIPE NCC audits includes repeated unresponsiveness to or failure to cooperate with the RIPE NCC auditors’ requests regarding registrations of Internet number resources for the Member’s own network. For more information about the audit procedure, please see RIPE NCC audit activity.

   Procedure

   The RIPE NCC will:

   • Send an email to the registered contact(s) indicating:

     • The reason for termination of the SSA

     • The immediate termination of the SSA

   • Terminate the progress of any open requests for RIPE NCC services

   The RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

9. Discontinuation of RIPE NCC services
   

   If the RIPE NCC cannot reasonably be required to continue the SSA for reasons that can not be attributed to the RIPE NCC and for which the RIPE NCC cannot be held accountable by virtue of law, a juridical act or generally accepted principles.

   Procedure

   The RIPE NCC will:

   • Send an email to the registered contact(s) indicating:

     • The reason for termination of the SSA

     • The immediate termination of the SSA

   • Terminate the progress of any open requests for RIPE NCC services

   The RIPE NCC Managing Director will send an official notification of termination of the SSA (i.e., closure of the Member’s account) to all registered postal and email addresses of the Member.

2. Consequences

Upon termination of the SSA, Members lose all rights to RIPE NCC services and their RIPE NCC member status.

2.1. End of provision of RIPE NCC services

2.1.1. General services

The RIPE NCC will stop providing RIPE NCC services, including:

• Distribution of Internet number resources

• Authority to maintain Internet number resource records in the RIPE Database

• Access to the LIR Portal

• Use of the RIPE NCC Certification Service

• Participation in RIPE NCC Training Courses

2.1.2. Registration of distributed Internet number resources

The RIPE NCC will deregister the relevant Internet number resource records. The procedure for deregistration is described in section B.2. The RIPE NCC will also revoke any certificates generated by the RIPE NCC Certification Service.

2.1.3. Request for independent Internet number resources as a “sponsoring LIR”

Members lose their right to request independent Internet number resources as a “sponsoring LIR”. For independent Internet number resources already assigned by them, see below at section B.2.2.

2.2. End of RIPE NCC member status

Members will also lose their RIPE NCC member status and all relevant rights, such as the right to attend and vote at RIPE NCC General Meetings.

B. Deregistration of Internet Number Resources

1. Reasons for deregistration of Internet number resources - Allocations and Independent Internet number resources assigned for the Member’s own network or assigned through a “sponsoring LIR”

1. Termination of the SSA

   For more information, see section A. For Independent Internet number resources through a “sponsoring LIR”, see Independent Internet Number Resources – Contractual Relationship Changes between Sponsoring LIR and End User.

2. Invalidity of original allocation/assignment criteria

   Internet number resources are allocated/assigned based on a specific need. When the original technical requirements or the business purpose for the use of the Internet number resources change, the allocation/assignment becomes invalid. If the RIPE NCC notices any change in the original technical criteria or the original business purposes for using the Internet number resources, the RIPE NCC is authorised to deregister the relevant Internet number resources.

3. Incorrect registration of the allocation/assignment in the RIPE Database

   If the allocation/assignment approved by the RIPE NCC is not properly registered in the RIPE Database, the RIPE NCC is authorised to deregister the relevant Internet number resources.

   Proper registration must be as follows:

   • The inetnum and the inet6num object(s) for approved assignments must use the netname(s) approved by the RIPE NCC and not be larger than the size approved by the RIPE NCC

   • The date in the first “changed:” attribute must not be earlier than the date of approval from the RIPE NCC

   • The data must be valid and must allow the RIPE NCC to contact the natural person mentioned directly in the inetnum or inet6num object(s) or via the maintainers of the inetnum or inet6num object(s) object within a reasonable time without having to get information from another source

4. Falsified/incorrect information

   If a Member has provided falsified data or information, or purposefully provided incorrect data or information (for example, falsified registration documents or IDs, incorrect/inaccurate contact details, etc.) regarding an allocation or an Independent resource, the RIPE NCC will deregister the relevant records.

5. Fraudulent request

   If a Member has submitted a fraudulent request for an allocation or an Independent resource (for example, by providing incorrect purpose/need or falsified information about the network, etc.), the RIPE NCC will deregister the relevant records.

6. Non-compliance with a RIPE NCC audit

   If a Member does not comply with a RIPE NCC audit regarding the registration of an Independent resource that the Member is responsible for as “sponsoring LIR”, the RIPE NCC will deregister the relevant records. Non-compliance includes, but is not limited to, unresponsiveness to or failure to cooperate with the RIPE NCC auditors’ requests. For more information about the audit procedure, please see RIPE NCC Audit Activity.

7. Court order

   The RIPE NCC is an association under Dutch law. In the event a Dutch court orders deregistration of specific Internet number resources, the RIPE NCC must and will comply.

8. Independent Internet number resources assigned through a “sponsoring LIR” without an valid contractual relationship

   See Independent Internet Number Resources – Contractual Relationship Changes between Sponsoring LIR and End User.

2. Procedures for deregistration of different types of Internet number resources

2.1 Allocations and independent Internet number resources for Member’s own network

The RIPE NCC will send an official notification by email to all registered contacts stating that the allocation/independent Internet number resources will be deregistered, explaining the reasons for this deregistration and the procedure of the deregistration. The Member will not be able make any further assignments from the allocations.

Should the Member respond within four weeks, the RIPE NCC will provide a timeframe of three months for the Members to take care of any actions necessary for the deregistration of the Internet number resources. In the case of allocations, Members are responsible for requesting that their customers renumber immediately and for providing them with all available options. In particular, Members must refer their customers to the list of other Members. This list is available at:

http://www.ripe.net/membership/indices

During the three-month period:

• The Member must stop announcing the allocation/independent Internet number resources

• The RIPE NCC will change the mnt-by object on the Member’s records to the status “deregistered maintainer”

• A warning statement is added to the relevant records of the RIPE Database mentioning the upcoming deregistration of the Internet number resources

• The RIPE NCC will revoke any certificates generated by the RIPE NCC Certification Service

After the three-month period, the allocation/assignment will be deregistered from the RIPE Database.

Should the Member not react within four weeks, the RIPE NCC will:

• Change the mnt-by object on the Member’s records to the status “deregistered maintainer”; and/or

• Add a warning statement to the relevant records in the RIPE Database mentioning the upcoming deregistration of the Internet number resources; and/or

• Withdraw the reverse delegation; and/or

• Contact the upstream to investigate possible hijacking of Internet number resources; and/or

• Delete all relevant objects in the RIPE Database, including allocation/assignment and route objects

• Revoke any certificates generated by the RIPE NCC Certification Service.

The sole purpose of these actions by the RIPE NCC is for deregistration of the Internet number resources to reflect reality. As a result, if the Internet number resources are no longer announced after one of these actions, the RIPE NCC might not perform any other actions.

Please note:

If the Member responds but with no intention to comply or objects at some point within the four-week period, the RIPE NCC will allow the time remaining in this four-week period for the Member to submit evidence that there is no reason for the deregistration of the Internet number resources or to request arbitration (see RIPE NCC Conflict Arbitration Procedure). However, if the four-week period expires without the submission of such evidence by the Member or without the submission of a request for arbitration, the RIPE NCC will proceed as if the Member had never reacted (see relevant procedure above). The Member may still request arbitration according to the timeframes of the RIPE NCC Conflict Arbitration Procedure. If the Member requests arbitration, the RIPE NCC will change the mnt-by object on the relevant records to the status “maintainer in dispute” and a warning statement will be added to the relevant records of the RIPE Database until the communication of the arbiter’s ruling.

2.2 Independent Internet number resources assigned through a “sponsoring LIR”

The RIPE NCC will send an official notification to all registered contacts stating that the Independent Internet number resources will be deregistered, explaining the reasons for this deregistration and the procedure for the deregistration. The Member must immediately inform the End User about the imminent deregistration.

During this period:

• The End User must stop announcing the Independent Internet number resources

• The RIPE NCC will change the mnt-by object on the relevant records to the status “deregistered maintainer”

• A warning statement is added to the relevant records of the RIPE Database mentioning the upcoming deregistration of the Internet number resources

After the three-month period, the independent Internet number resources will be deregistered from the RIPE Database.

Should the Member not react within four weeks, the RIPE NCC will:

• Change the mnt-by object on the relevant records to the status “deregistered maintainer”; and/or

• Add a warning statement to the relevant records in the RIPE Database mentioning the upcoming deregistration of the Internet number resources; and/or

• Withdraw the reverse delegation; and/or

• Contact the upstream to investigate possible hijacking of Internet number resources; and/or

• Delete all relevant objects in the RIPE Database, including allocation/assignment and route objects

The sole purpose of these actions by the RIPE NCC is for deregistration of the Internet number resources to reflect reality. As a result, if the Internet number resources are no longer announced after one of these actions, the RIPE NCC might not perform any other actions.

Please note:

If the Member responds but with no intention to comply or objects at some point within the four-week period, the RIPE NCC will allow the time remaining in this four-week period for the Member to submit evidence that there is no reason for deregistration of the Internet number resources or to request arbitration (see RIPE NCC Conflict Arbitration Procedure). However, if the four-week period expires without the submission of such evidence by the Member or without the submission of a request for arbitration, the RIPE NCC will proceed as if the Member had never reacted (see relevant procedure above). The Member may still request arbitration according to the timeframes of the RIPE NCC Conflict Arbitration Procedure. If the Member requests arbitration, the RIPE NCC will change the mnt-by object on the relevant records to the status “maintainer in dispute” and a warning statement will be added to the relevant records of the RIPE Database until the communication of the arbiter’s ruling.

NOTE: This document might change due to future policy changes. If this happens, the RIPE NCC will send a notification to the RIPE NCC Services Working Group mailing list.

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/groups/wg/ap

Contents

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

5.5 Transfers of Allocations

5.6 Use of last /8 PA 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

6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers

6.10 Provider Independent IPv4 Assignments for Multihoming

7.0 Assignment Window

8.0 PA vs. PI Address Space

9.0 Record Keeping

10.0 LIR Audit

11.0 Closing an LIR by the RIPE NCC

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".

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/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:

1. 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.
2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
3. 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.
4. 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.

The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months.

Starting on 1 July 2010, a gradual reduction in the allocation period will be applied as follows:

As of 1 July 2010, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to nine months.

As of 1 January 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to six months.

As of 1 July 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to three months.

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 First Allocation

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

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

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

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 by email 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 up to an IPv4 /20 (4096 addresses) to a downstream network operator every twelve months.

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

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. 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.

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 either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC, following the policies set for receiving further allocations within RIPE region (see the Section 5.3 Additional Allocations of this document).

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 will be signed to establish the current allocation owner.

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.

5.6 Use of last /8 for PA Allocations

The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:

1. Allocations for LIRs from the last /8
   On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
   1. LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be exactly one /22.
   2. LIRs receive only one /22, even if their needs justify a larger allocation.
   3. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application.
   4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.
      
      
2. Assignments to Internet Exchange Point
   A /16 from the final /8 will be held in reserve for exclusive use by Internet Exchange Points. On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one number resource (/24 to /22) according to the following:
   • This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.
   • Organisations receiving space under this policy must be Internet Exchange Points 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 Internet Exchange points will be assigned a /24. Internet exchange points may return this /24 (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment.
   • IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use.
   • Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN
     
     
3. Unforeseen circumstances
   
   1. 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 /8 covered by this policy has been distributed, it returns to the pool to be distributed as per clause 1.
      
      
4. Post-depletion Address Recycling
   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.
   1. Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in clause 1.
   2. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary
      
      
5. Insufficient address space
   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.

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.

The End Users must be assigned with enough address space to meet their needs for a period of up to 12 months.

Starting on 1 July 2010, a gradual reduction in the assignment period will be applied as follows:

As of 1 July 2010, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to nine months.

As of 1 January 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to six months.

As of 1 July 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to three months.

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/request-forms-supporting-notes

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:
http://www.ripe.net/data-tools/support/documentation/getting-started

6.3 Utilisation Rates

The utilisation rate of an assignment must be such that at least 50% of the total space shall have been utilised halfway through the assignment period applied at the time of the assignment.

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 Audit Activity” found at:
http://www.ripe.net/ripe/docs/audit

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.

6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers

The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /24 prefixes per TLD and four /24 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC 4786 (http://www.ietf.org/rfc/rfc4786.txt).

Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".

Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for authoritative TLD or ENUM Tier 0/1 DNS lookup services via anycast any longer.

6.10 Provider Independent IPv4 Assignments for Multihoming

The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24 if an End User demonstrates:

• the need for Provider Independent (PI) IPv4 address space; and
• the intent to announce this address space for the purpose of multihoming to two or more Autonomous Systems which the End User does not own or control

Cumulatively, no more than 255 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined above.

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/request-forms-supporting-notes

All new LIRs start with an AW of zero (0). Their AW will automatically be set to a /21 (2048 addresses) six months after receiving their first allocation. This means that all new LIRs need to request approval before making each assignment until their AW has been raised.

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 or a downstream network operator as the user of a sub-allocation 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 RIPE NCC staff. LIRs may approach the RIPE NCC for an evaluation of their AW six months after receiving their first allocation and at any time after that. 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 judgment 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 judgment 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 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 must be returned and the network renumbered.

In contrast, Provider Independent (PI) address space is assigned to End Users directly from the address pools managed directly by the RIPE NCC. PI space cannot be re-assigned or further assigned to other parties. PI address space can only remain assigned to a network as long as the criteria for the original assignment are maintained. Additionally, all new PI address space assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

As PI addresses are not assigned from LIR-allocated PA address blocks, they cannot be aggregated on the public Internet. Consequently, they are expensive to route, and therefore may 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 and is also subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

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.
• 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.

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.

9.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.

10.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

11.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/lir-services/training

The instructions are based on the following policy documents:

1. IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region
2. IPv6 Address Allocation and Assignment Policy
3. Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region

General Information

#[GENERAL INFORMATION]#

% Please add your RegID.
request-type: ixp-assign
form-version: 1.0
x-ncc-regid: nl.bluelight

Please do not change the value of the "request-type:" and "form-version:" fields.

Enter your Registry Identifier (RegID) in the "x-ncc-regid:" field. RegIDs have the following format: <country code>.<name>. If you do not know your RegID, please contact ncc@ripe.net.

Overview of  Organisation

#[OVERVIEW OF ORGANISATION]#

% Is this request being sent by a sponsoring LIR on behalf of an End
% User?  (Yes/No)
end-user-of-sponsoring-lir: Yes
% If yes, please confirm that the "End User Assignment Agreement"
% contains all of the elements listed in paragraph 2.0 of "Contractual
% Requirements for Provider Independent Resource Holders in the RIPE
% NCC Service Region".  (Yes/No)
confirmation: Yes
% Which IXP will use the requested address space?
org-description: Ruritania IXP Ltd

If you are an LIR sending this request on behalf of an End User, you should answer "Yes" in the "end-user-of-sponsoring-lir" field.

If you answered "Yes" you should also confirm that all of the elements of paragraph 2.0 of "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" are listed in the “End User Assignment Agreement” that is signed by the End User and the sponsoring LIR.

For all assignments that are requested through a sponsoring LIR for an End User, we need to receive a copy of the "End User Assignment Agreement" and the company registration papers of the End User.

You can find an example agreement at:
https://www.ripe.net/lir-services/resource-management/direct-assignments/independent-assignment-request-and-maintenance-agreement

You can send us an agreement in your local language or use the English version.

If the request is for an LIR, you should answer "No" to the two questions above. There is no need to submit any additional documentation if the request is for an LIR.

In the “org-description:” field, write a short description of the IXP requesting the assignment(s).

Overview of the User

#[OVERVIEW OF THE USER]#

% Who is the contact person for this IXP?
Name:         Fred Bloggs
Organisation: Ruritania IXP
Country:      NN
Phone:        +123 45 678910
Email:        fred@rurixp.ripe.net

Enter the legal name and primary location of the organisation in the “organisation:” and “country:” fields.

Please use international dialing codes (for example, +31 for the Netherlands,) in the “phone:”field.

Existing Address Space Usage

#[EXISTING ADDRESS SPACE USAGE]#

% If the IXP has any IPv4 ranges(s) for their peering LAN, list them
% below.  If any such space is being returned, then the return date
% should be specified.
subnet-ipv4: 192.0.2.0/24 to nl.bluelight in 1 month.
% If the IXP has any IPv6 assignments, list them below.
subnet-ipv6: None

Please specify address prefixes using slash notation (for example, y:y:y::/yy). You can repeat the “subnet-ipv4 or subnet-ipv6:” field as many times as needed.

If there is any address space assigned that they will be returned, list each prefix in separate "address-space-returned" fields. The maximum renumbering is 180 days. You can use the following syntax: <x.x.x.x/xx> in <time period> for this field.

IPv4 Address Space Usage

#[IPv4 ADDRESS SPACE USAGE]#

% How will the IXP use the requested IPv4 address space?
% ADDRESSING PLAN
%            Subnet          Immediate       Intermediate     Entire          Purpose
%            size (/nn)      Requirement     Requirement      Period
subnet:   /27            16           24          32     Network Infrastructure 
subnet:  /24,/26        272          296         320    Members connections 
 
totals:    /24,/26,/27    /24,/27      /24,/26     /24,/26,/27 
number-of-subnets: 2

The addressing plan shows how the End User will use the requested address space.

You can repeat the "subnet" row as many times as needed. Delete any empty "subnet" fields before you send the request.

In the "Subnet size (/nn)" column, enter a slash notation prefix for each subnet. Each entry should be large enough to contain the number of addresses needed for that subnet over the next time period.

In order to demonstrate the predicted growth of your network, you must provide an estimate of the address space you will require over three distinct periods: Immediate, Intermediate and the Entire period. These columns can either contain numbers (for example, 256) or slash notation prefixes (for example, /24).

In the "Purpose" column, write a short description of each subnet. If needed, you can write a more detailed description in the "Supplemental Comments" section at the end of this form.

In the "totals" row, add the totals of each column. The total of the "Subnet size (/nn)" column should be the total amount of address space you are requesting for this assignment.

In the "number-of-subnets" field, enter the total number of subnets listed in the addressing plan.

IPv6 Address Space Usage

#[IPv6 ADDRESS SPACE USAGE]#

% How will the IXP use the requested IPv6 address space?
% ADDRESSING PLAN
%          Subnet       Within     Within   Within      Purpose
%          size (/nn)   3 months   1 year   2 years
subnet: /64           x         -        -         Network Infrastructure 
subnet: /55           x         -        -         Members connections* 

The addressing plan shows when the IXP plans to use the address space.

Enter the size of each subnet in the “Subnet size (/nn)” column. Please specify the size using IPv6 slash notation (for example, /48). You can repeat the “subnet:” field as many times as needed.

In the “Purpose” column, write a short description for each subnet. If needed, you can write a more detailed description in the “Insert Supplemental Comments” section at the end of the form.

Complete the remaining columns with a cross (x) or a dash (-). For example, if you will use a subnet within three months, enter a cross in the “Within 3 months” column and a dash in both the “Within 1 year” and “Within 2 years” columns.

Supplemental Comments

#[SUPPLEMENTAL COMMENTS]#

% Please add more information if you think it will help us understand
% this request. You can attach a network diagram or other relevant
% supporting documentation.  If the IXP has an online list of members,
% please add the URL below.

Ruritania IXP has 62 IXP members, and add approximately six new members every month. Each member's connection requires one /30.
The IXP network consists of three routers (three IPs), three switches (three IPs) and two firewalls (eight IPs).  Two more routers and switches will be added next month.
We would like to return the current /24 used for our peering LAN and receive one /23 IXP assignment to renumber current members and connect new members.

The joining requirements are online at: http://www.rurixp.ripe.net/join_us.html

You can use this space for additional information that you think will be helpful for us when we evaluate your request.

A network diagram (topology map) can help us to understand the set-up of the network and its addressing needs.

Supporting Documentation

#[SUPPORTING DOCUMENTATION]#

% If this request is being sent by a sponsoring LIR on behalf of an
% End User, please attach a copy of the signed "End User Assignment
% Agreement" and the company registration papers of the End User.

% Have you attached any files/documents to this request?  (Yes/No)
file-attached:Yes

For each assignment that is requested through a sponsoring LIR for an IXP, we need to receive a copy of “End User Assignment Agreement” and the company registration papers of the End User.

If this request is for an LIR or a “Direct Assignment User”, you do not have to attach a copy of “End User Assignment Agreement” and company registration papers.

Database Templates

#[IPv4 DATABASE TEMPLATE]#

% If you are requesting IPv4, complete this IPv4 database template.
% If you are not requesting IPv4, please remove this IPv4 database
% template.

inetnum: <leave empty>
netname:     RURIXP
descr:       Ruritania IXP Ltd
country:     NL
org:         ORG-Bb2-RIPE
admin-c:     HOHO15-RIPE
tech-c:      HOHO15-RIPE
status:      ASSIGNED PI
mnt-by:      RIPE-NCC-END-MNT
mnt-lower:   RIPE-NCC-END-MNT
mnt-by:      SANTA-MNT
mnt-domains: SANTA-MNT
mnt-routes:  SANTA-MNT
changed:     hostmaster@ripe.net
source:      RIPE

#[IPv6 DATABASE TEMPLATE]#

% If you are requesting IPv6, complete this IPv6 database template.
% If you are not requesting IPv6, please remove this IPv6 database
% template.

inet6num:  <leave empty>
netname:     RURIXP
descr:       Ruritania IXP Ltd
country:     NL
org:         ORG-Bb2-RIPE
admin-c:     HOHO15-RIPE
tech-c:      HOHO15-RIPE
status:      ASSIGNED PI
mnt-by:      RIPE-NCC-END-MNT
mnt-lower:   RIPE-NCC-END-MNT
mnt-by:      SANTA-MNT
mnt-domains: SANTA-MNT
mnt-routes:  SANTA-MNT
changed:     hostmaster@ripe.net
source:      RIPE

If the IXP is requesting IPv4 and IPv6, please complete all templates. If not, you should complete the relevant template(s) and delete the rest when sending the request.

Leave the "inetnum/inet6num" fields empty as we will choose the address range.

The “netname:” should be a short, descriptive name for the network and should reflect the name of the organisation operating the IXP.

Enter the legal name of the organisation operating the IXP in the “descr:” field.

Enter the ISO country code of the organisation in the “country:” field.

Enter the org-ID of the organisation object in the “org:” field. You can create organisation objects using 'webupdates'.

Person and role objects contain information about people. Each object has a unique NIC handle (nic-hdl). You can create person and role objects using webupdates.

The nic-hdl of the role or person object entered in the “admin-c:” field should be for someone who has administrative responsibilities for the network.

The nic-hdl of the role or person object entered in the “tech-c:” field should be for someone who has technical knowledge of the network.

The “status:” field must be ASSIGNED PI.

Maintainers protect objects in the RIPE Database. They contain the information needed to authorise creation, deletion or modification of these objects. You can create maintainers using the “Maintainer Editor” (https://lirportal.ripe.net).

One of the “mnt-by:” fields must be RIPE-NCC-END-MNT. Enter the IXP’s maintainer in the other “mnt-by:” field. The IXP will be able to update the inetnum/inet6num object using webupdates.

The “mnt-lower:” field must be RIPE-NCC-END-MNT.

The “mnt-domains:” field shows which maintainer authorises the creation of domain objects for the assignment.

The “mnt-routes:” field shows which maintainer authorises the creation of route/route6 objects for the assignment.

All of the objects that you enter in the template must already exist in the RIPE Database.

The “changed:” field must be hostmaster@ripe.net.

The “source:” field must be RIPE.

End of Request

Best Regards,

Jan Janssen, Bluelight Admin

Please write your full name below the "#[END of REQUEST]#" header.

% Internet Exchange Point Assignment Request Form
% RIPE NCC members (LIRs) can use this
% form to request an IPv4/IPv6 Assignment for an Internet Exchange
% Point (IXP).  Please see ripe-576 for instructions on how to
% complete this form.
%
% Please note that the End User should have a signed "End User
% Assignment Agreement" with either the sponsoring LIR
% or the RIPE NCC.


#[GENERAL INFORMATION]#

request-type: ixp-assign
form-version: 1.0

% Please add your RegID.
x-ncc-regid: 


#[OVERVIEW OF ORGANISATION]#

% Is this request being sent by a sponsoring LIR on behalf of an End
% User?  (Yes/No)
end-user-of-sponsoring-lir: 

% If yes, please confirm that the "End User Assignment Agreement"
% contains all of the elements listed in paragraph 2.0 of "Contractual
% Requirements for Provider Independent Resource Holders in the RIPE
% NCC Service Region".  (Yes/No)
confirmation:

% Which IXP will use the requested address space? 
org-description: 


#[OVERVIEW OF THE USER]#

% Who is the contact person for this IXP?
Name:
Organisation:
Country:
Phone:
Email:


#[EXISTING ADDRESS SPACE USAGE]#

% If the IXP has any IPv4 ranges(s) for their peering LAN, list them
% below.  If any such space is being returned, then the return date
% should be specified.
subnet-ipv4:

% If the IXP has any IPv6 assignments, list them below.
subnet-ipv6:



% The next two sections (IPv4 and IPv6) will give us an overview of
% the detailed usage of the resources. Please fill in only the
% relevant section as per the resource being requested and remove the
% section that is not applicable.


#[IPv4 ADDRESS SPACE USAGE]#

% How will the IXP use the requested IPv4 address space? 
%
% ADDRESSING PLAN
% 
%       Subnet       Immediate    Intermediate  Entire   Purpose
%       size (/nn)   Requirement  Requirement   Period
subnet:

totals:
number-of-subnets: 

#[IPv6 ADD