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

 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

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

This document contains instructions for LIRs on how to complete the "Anycast Assignment Request Form". The instructions are based on the "IPv4 Address Allocation and Assignment Policy for the RIPE Region", the "IPv6 Address Allocation and Assignment Policy" and also "RFC 4786".

• General Information
• Address Space User
• Initial Information
• Anycast Node Plan
• Network Description
• Supporting Documentation
• Database Template(s)
• End of Request

General Information

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

request-type: anycast-assignment
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.

Address Space User

#[ADDRESS SPACE USER]#
%
% 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 TLD or ENUM operator will use the requested address space?

legal-organisation-name: North Santa NIC 
tld(s) or ENUM delegation(s): com biz nn
organisation-location: Santa City, NN
website-if-available: http://www.ns-nic.nn

The End User should be a recognised TLD or ENUM Tier 1 operator, as listed in these documents:

Root Zone Database Approved ENUM Delegations

% Does this End User already have address space in use for
% anycast? (Yes/No)

space-available: No

 % Will the End User return any address space?

address-space-returned: 
                

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. Anycast assignments can only be made to End Users if there is a signed 'End User Assignment Agreement' between the sponsoring LIR and the End User.

You can find an example agreement at http://www.ripe.net/membership/lir-end-user-agreement.html.

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

Enter the legal name of the organisation that will use the anycast assignment in the "legal-organisation-name:" field and list all of their TLDs (Top-Level Domains) in the "tld(s):" field.

Enter the primary location of the organisation in the "organisation-location:" field and, if they have a website, enter the URL in the "website-if-available:" field.

If the End User already has address space in use for anycast, list this in the "space-available:" field.

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.

Initial Information

#[INITIAL INFORMATION]#
%
% Does the End User accept the policies on anycast assignments?
% http://www.ripe.net/ripe/docs/ipv4-policies.html
% http://www.ripe.net/ripe/docs/ipv6policy.html (Yes/No)

confirmation: Yes

% Is the End User requesting an IPv4 assignment, an IPv6 
% assignment, or both? (IPv4/IPv6/Both)

ip-version: Both

% If the End User is requesting an IPv4 assignment, will the TLD
% nameserver set apply anycasting as described in BCP126/RFC4786?
% http://www.ietf.org/rfc/rfc4786.txt (Yes/No)

rfc4786: Yes

The End User must read the IPv4 Address Allocation and Assignment Policies and/or the IPv6 Address Allocation and Assignment Policy, and in particular the sections that refer to anycast assignments. Enter 'yes' in the "confirmation:" field if the End User agrees to follow these policies.

We need to know whether the End User would like us (RIPE NCC) to make an IPv4 assignment or an IPv6 assignment. If they need both, enter 'Both' in the "ip-version:" field and make any additional comments in the "Network Description" section.

If the End User is requesting an IPv4 assignment, please check that their TLD nameserver set conforms to the practices outlined in RFC 4786.

Anycast Node Plan

#[ANYCAST NODE PLAN]#
%
% Which anycast nodes will be used?
%
%		Node Name		Peers			Location

node:		Z-root Santa see Network Descr. Santa City IX
node:		Z-root Rudolf see Network Descr. Rudolf Town IX
node:

number-of-nodes: 2

The Anycast Node Plan shows how the End User will use the requested address space.

You can repeat the "node:" row as many times as needed.

Delete any empty "node:" fields before you send the request.

In the "Node Name" column, enter the name of each node.

In the "Peers" column, enter the AS Numbers of the peers for each node.

In the "Location" column, enter the primary location of the node.

If needed, you can write more detailed descriptions of any of the fields in the "Network Description" section.

Network Description

% Please add more information if you think it will help us understand
% this request.
                

We plan to provide anycasting from Santa City and Rudolf Town. The peers at Santa City IX are listed at http://www.scix.nn/peers and the peers at Rudolf Town IX are listed at http://www.rtix.nn/peers.

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 End User's addressing needs can help us to evaluate your request more quickly.

Supporting Documentation

#[SUPPORTING DOCUMENTATION]#
%
% If this request 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.
% You can also attach a network diagram or other supporting documentation.
%
% Have you attached any files/documents to this request? (Yes/No)
file-attached: Yes

For each anycast assignment that is requested through a sponsoring LIR for an End User, 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 you do not have to attach a copy of 'End User Assignment Agreement' and company registration papers.

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

Database Template(s)

#[DATABASE TEMPLATES]#

% IPv4
% Please complete all of the fields below.

inetnum:       
netname:       NS-NIC
descr:         North Santa NIC
country:       NN
org:           ORG-NSN3000-RIPE
admin-c:       HOHO1-RIPE
tech-c:        HOHO1-RIPE
status:        ASSIGNED ANYCAST
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

% IPv6
% Please complete all of the fields below.

inet6num:       
netname:        NS-NIC
descr:          North Santa NIC
country:        NN
org:            ORG-NSN3000-RIPE
admin-c:        HOHO1-RIPE
tech-c:         HOHO1-RIPE
status:         ASSIGNED ANYCAST
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
                

If the End User is requesting an IPv4 assignment and an IPv6 assignment, please complete both templates. You can repeat each template as many times as needed.

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

The "netname:" 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 ANYCAST.

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

#[END of REQUEST]#

Best Regards,
Jan Janssen, Bluelight Admin

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

1. Overview

2. Special Purpose Ranges

2.1. IPv6 PI Address Space

3. Routing Decisions

4. Longest Prefix Tables

1. Overview

This document details the address space managed by the RIPE NCC and the longest prefixes issued from different address ranges.

All IPv4 and IPv6 address space managed by the RIPE NCC and the current status of each address range can be found in the extended statistics file published daily at the URL below:

ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest

2. Special Purpose Ranges

2.1. IPv6 PI Address Space

The RIPE NCC assigns IPv6 Provider Independent (PI) prefixes in accordance with the IPv6 Address Allocation and Assignment Policy. The IPv6 PI assignments smaller than a /32 are taken from 2001:678::/29.

3. Routing Decisions

Routing decisions are the responsibility of network operators.

4. Longest Prefix Tables

The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29.

The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48.

• Introduction
  • General information on how to use this document
  • How to specify requirements
• Proposed generic text for the tender initiator
• Lists of mandatory and optional RFC/3GPP standards support for various hardware and software
  • IPsec: mandatory or optional
  • Definitions and descriptions of different types of devices
• Lists of required RFC/3GPP standards for different types of hardware
  • Requirements for "host" equipment
  • Requirements for consumer grade "Layer 2 switch" equipment
  • Requirements for enterprise/ISP grade "Layer 2 switch" equipment
  • Requirements for "router or Layer 3 switch" equipment
  • Requirements for "network security equipment”
  • Requirements for CPE equipment
  • Requirements for mobile devices
  • Requirements for load balancers:
• Requirements for IPv6 support in software
• Skill requirements of the systems integrator
  • Declaration of IPv6 competence
• Acknowledgments

Introduction

To ensure the smooth and cost-efficient uptake of IPv6 across their networks, it is important that governments and large enterprises specify requirements for IPv6 compatibility when seeking tenders for Information and Communication Technology (ICT) equipment and support. This document is intended to provide a Best Current Practice (BCP) and does not specify any standards or policy itself.

It can serve as a template that can be used by governments, large enterprises and all other organisations when seeking IPv6 support in their tenders or equipment requirements and offer guidance on what specifications to ask for. It can also serve as an aid to those people or organisations interested in tendering for government or enterprise contracts.

Be aware that the standards listed here have their origin in various bodies, which operate independent of the RIPE community, and that any of these standards might be changed or become replaced with a newer version. You may also need to adjust the recommendations to your specific local needs.

Some parts of this section are loosely based on the NIST/USGv6 profile developed by the US government:[1]
http://www.antd.nist.gov/usgv6/

The authors have modified these documents to make them more universally applicable. This option includes a list of RFC specification standards that must be supported, divided into eight categories of devices.

This document also follows the IPv6 Node requirements document, RFC6434. This RFC is the general IETF guidance on what parts of IPv6 need to be implemented by different devices.

General information on how to use this document

An IPv6 Ready Logo certificate can be required for any device. This is the easiest way for vendors providing the equipment to prove that it fulfills basic IPv6 requirements. The tender initiator shall also provide the list of required mandatory and optional RFCs in order not to exclude vendors that did not yet put their equipment under IPv6 Ready Logo testing certifications. This way public tenders can’t be accused of preferring any type or vendor of equipment.

When we specify the list of required RFCs, we must list all mandatory requirements, except the entries that start with, “If [functionality] is requested…” These entries are mandatory only if the tender initiator requires certain functionality. Please note that the tender initiator should decide what functionality is required, not the equipment vendor.

Certain features that are in the 'optional' section in this document might be important for your specific case and/or organisation. In such cases the tender initiator should move the requirement to the 'required' section in their tender request.

How to specify requirements

As stated above, the IPv6 Ready Logo program does not cover all equipment that correctly supports IPv6; so declaring such equipment ineligible may not be desirable. This document recommends that the tender initiator specify that eligible equipment be either certified under the IPv6 Ready program or be compliant with the appropriate RFCs listed in the section below.

About the IPv6 Ready Logo program:
http://www.ipv6ready.org/

Also note that there exists the BOUNDv6 project whose goal is to create a permanent multi-vendor network environment connecting approved laboratories where the community can test IPv6-enabled applications and devices in meaningful test scenarios. Tender initiators are encouraged to have a look and also use the results of this project.

About BOUNDv6:
http://www.boundv6.org/

Important note for tender initiator:

The IPv6 Ready Logo certification covers basic IPv6 requirements and some advanced features, but not all of them. If you require any advanced feature that is not covered by IPv6 Ready Logo certification, please request a list of RFCs that covers those specific needs in addition to IPv6 Logo Certification. In the lists below RFCs that are covered in the IPv6 Ready Logo certification are marked with *.

Proposed generic text for the tender initiator

In every tender, following text shall be included:

All ICT hardware as subject of this tender must support both the IPv4 and IPv6 protocols. Similar performance must be provided for both protocols in input, output and/or throughput data-flow performance, transmission and processing of packets.

IPv6 support can be verified and certified by the IPv6 Ready Logo certificate.

Any software that communicates via the IP protocol must support both protocol versions (IPv4 and IPv6). The difference must not be noticeable to users.

Equipment that has not been put through the IPv6 Ready testing procedures must comply with the RFCs listed below:

[appropriate list of selected mandatory and optional RFCs from below lists]

Lists of mandatory and optional RFC/3GPP technical specifications support for various hardware and software

Requirements are divided by hardware equipment and integrator support.

It should be assumed that all IPv4 traffic will migrate to IPv6. All requirements placed on IPv4 traffic capabilities like latency, bandwidth and throughput should also be required for IPv6 traffic.

IPsec: mandatory or optional

In the original IPv6 Node Requirements (RFC4294) standard, IPsec was listed as a 'MUST' implement to be standards compliant.  The updated RFC (RFC6434) changed IPsec to a 'SHOULD' implement.  Reasons for the change are stated in this new RFC.

The RIPE IPv6 Working Group has extensively discussed whether to make IPsec support mandatory or optional.  The most vocal constituents showed support for moving IPsec to the optional sections, which is what is reflected in this document.

While the consensus of the community was to make IPsec optional in most cases, the IETF have now stated that IPsec 'SHOULD' be implemented in the latest version of the IPv6 Node Requirements standard (RFC6434).  In the IETF context, a SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Organisations that use IPsec or expect to use it in the future should include the following in the mandatory section when initiating the tender:
• IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] *

Definitions and descriptions of different types of devices

The following definitions will be used for classifying the varying hardware equipment. While some hardware may have overlapping functionality (i.e., a Layer 2 switch can act as a Layer 3 router or a router may have some firewall capabilities), it is expected that for any overlapping functionality, the requirements for each specific device be combined.

Host: A host is a network participant that sends and receives packets but does not forward them on behalf of others.

Switch, or ‘Layer 2 Switch’: A switch or ‘Layer 2 switch’ is a device that is primarily used for forwarding Ethernet frames based on their attributes. Exchanging Ethernet information with other Ethernet switches is usually part of its function.

Router or ‘Layer 3 Switch’: A router or ‘Layer 3 switch’ is a device that is primarily used for forwarding IP packets based on their attributes. Exchanging routing information with other Routers is usually part of its function.

Network Security Equipment: Network security equipment is devices whose primary function is to permit, deny and/or monitor traffic between interfaces in order to detect or prevent potential malicious activity. These interfaces can also include VPNs (SSL or IPsec). Network Security Equipment is often also a Layer 2 switch or a Router/Layer 3 switch.

Customer Premise Equipment (CPE): A CPE device is a small office or residential router that is used to connect home users and/or small offices in a myriad of configurations. Although a CPE is usually a Router, the requirements are different from an Enterprise/ISP Router Layer 3 switch.

Mobile Device: In the context of this document, a mobile device is a node that connects to a 3GPP defined system using some 3GPP specified access technology (such as 2G, 3G, or LTE). For situations where the network logic is being provided solely by a dedicated device A connected to another device B, the specification will refer to device A and not to device B. If the protocol logic is distributed (e.g. a computer with an external Ethernet interface that performs TCP checksum offloading), the aggregate system is being referred to.

Load Balancer: A load balancer is a networking device that distributes workload across multiple computers, servers or other resources, to achieve optimal or planned resource utilisation, maximise throughput, minimise response time, and avoid overload.

The following references are of relevance to this BCP document. At the time of publication, the editions indicated were valid. All references are subject to revision; users of this BCP document are therefore encouraged to investigate the possibility of applying the most recent edition of the references listed below.

Lists of required RFC/3GPP standards for different types of hardware

ICT hardware equipment is divided into seven functional groups:

• Host: client or server
• Layer 2 switch
• Router or Layer 3 switch
• Network security equipment (firewalls, IDS, IPS...)
• CPE
• Mobile device
• Load balancer

We have divided the following requirements into two categories, “mandatory” and “optional”. Equipment must meet the mandatory standards requirements list. Support for the optional requirements may earn the tender applicant additional points, if so specified by the tender initiator.

Any hardware that does not comply with all of the mandatory standards should be marked as inappropriate by the tender evaluator.

The standards that are part of the IPv6 Ready Logo test procedures, typically performed by accredited labs, are marked with an asterisk *.

Requirements for "host" equipment

Mandatory support:

• IPv6 Basic specification [RFC2460] *
• IPv6 Addressing Architecture [RFC4291] *
• Default Address Selection [RFC3484]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]
• ICMPv6 [RFC4443] *
• DHCPv6 client [RFC3315] *
• SLAAC [RFC4862] *
• Path MTU Discovery [RFC1981] *
• Neighbor Discovery [RFC4861] *
• If support for tunneling and dual stack is required, the device must support Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]
• If support for mobile IPv6 is required, the device must support “MIPv6” [RFC6275, RFC5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877]
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]
• DNS message extension mechanism [RFC2671]
• DNS message size requirements [RFC3226]
• Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] *

Optional support:

• IPv6 Router Advertisement Options for DNS Configuration [RFC6106]
• Extended ICMP for multi-part messages [RFC4884]
• SeND [RFC3971]
• SLAAC Privacy Extensions [RFC4941]
• Stateless DHCPv6 [RFC3736] *
• DS (Traffic class) [RFC2474, RFC3140]
• Cryptographically Generated Addresses [RFC3972]
• IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] *
• SNMP protocol [RFC3411]
• SNMP capabilities [RFC3412, RFC3413, RFC3414]
• SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
• Multicast Listener Discovery version 2 [RFC3810] *
• Packetisation Layer Path MTU Discovery [RFC4821]
• IPv6 Host-to-Router Load Sharing [RFC4311]
• Default Router Preferences and More-Specific Routes [RFC4191]

Requirements for consumer grade "Layer 2 switch" equipment

Optional support (management)

• MLDv2 snooping [RFC4541]
• IPv6 Basic specification [RFC2460] *
• IPv6 Addressing Architecture [RFC4291] *
• Default Address Selection [RFC3484]
• ICMPv6 [RFC4443] *
• SLAAC [RFC4862] *
• SNMP protocol [RFC3411]
• SNMP capabilities [RFC3412, RFC3413, RFC3414]
• SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]

Requirements for enterprise/ISP grade "Layer 2 switch" equipment

Mandatory support:

• MLDv2 snooping [RFC4541]
• DHCPv6 filtering [RFC3315]
• Router Advertisement (RA) filtering [RFC4862]
• Dynamic "IPv6 Neighbor solicitation/advertisement" inspection [RFC4861]
• Neighbor Unreachability Detection [NUD, RFC4861] filtering
• Duplicate Address Detection [DAD, RFC4429] snooping and filtering.[2]

Optional support (management):

• IPv6 Basic specification [RFC2460] *
• IPv6 Addressing Architecture [RFC4291] *
• Default Address Selection [RFC3484]
• ICMPv6 [RFC4443] *
• SLAAC [RFC4862] *
• SNMP protocol [RFC3411]
• SNMP capabilities [RFC3412, RFC3413, RFC3414]
• SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
• IPv6 Routing Header [RFC2460, Next Header value 43] filtering *
• Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] *
• UPnP filtering

Requirements for "router or Layer 3 switch" equipment

Mandatory support:

• IPv6 Basic specification [RFC2460] *
• IPv6 Addressing Architecture [RFC4291] *
• Default Address Selection [RFC3484]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]
• ICMPv6 [RFC4443] *
• SLAAC [RFC4862] *
• MLDv2 snooping [RFC4541]
• Multicast Listener Discovery version 2 [RFC3810] *
• Router-Alert option [RFC2711]
• Path MTU Discovery [RFC1981] *
• Neighbor Discovery [RFC4861] *
• Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] *
• If a dynamic interior gateway protocol (IGP) is requested, then RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] must be supported. The contracting authority shall specify the required protocol.
• If OSPF-v3 is requested, the equipment must comply with "Authentication/Confidentiality for OSPF-v3" [RFC4552]
• If BGP4 protocol is requested, the equipment must comply with RFC4271, RFC1772, RFC4760, RFC1997, RFC3392 and RFC2545
• Support for QoS [RFC2474, RFC3140]
• If support for tunneling and dual stack is required, the device must support Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]
• If support for tunneling and dual stack is required, the device must support Generic Packet Tunneling and IPv6 [RFC2473]
• If 6PE is requested, the equipment must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)” [RFC4798]
• If mobile IPv6 is requested, the equipment must support MIPv6 [RFC6275, RFC5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877]
• If the IS-IS routing protocol is requested the equipment must support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC5120]
• If MPLS functionality (for example, BGP-free core, MPLS TE, MPLS FRR) is requested, the PE-routers and route reflectors must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC4798]
• If Layer 3 VPN functionality is requested, the PE-routers and route reflectors must support "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC4659]
• If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment must support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC5120]

Optional support:

• IPv6 Router Advertisement Options for DNS Configuration [RFC6106]
• DHCPv6 client/server/relay [RFC3315] *
• Extended ICMP for multi-part messages [RFC4884]
• SeND [RFC3971]
• SLAAC Privacy Extensions [RFC4941]
• Stateless DHCPv6 [RFC3736] *
• DHCPv6 PD [RFC3633] *
• Route Refresh for BGP-4 Capabilities [RFC2918]
• BGP Extended Communities Attribute [RFC4360]
• (QOS) Assured Forwarding [RFC2597]
• (QOS) Expedited Forwarding [RFC3246]
• Generic Routing Encapsulation [RFC2784]
• Cryptographically Generated Addresses [RFC3972]
• IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] *
• Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC4891]
• SNMP protocol [RFC3411]
• SNMP capabilities [RFC3412, RFC3413, RFC3414]
• SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]
• DNS message extension mechanism [RFC2671]
• DNS message size Requirements [RFC3226]
• 127-bit IPv6 Prefixes on Inter-Router Links [RFC6164]
• Packetisation Layer Path MTU Discovery [RFC4821]
• IPv6 Host-to-Router Load Sharing [RFC4311]
• Default Router Preferences and More-Specific Routes [RFC4191]

Requirements for "network security equipment”

Equipment in this section is divided into three subgroups:

• Firewall (FW)
• Intrusion prevention device (IPS)
• Application firewall (APFW)

For every mandatory standard the applicable subgroups are specified in parentheses at the end of the line.

Mandatory support:

• IPv6 Basic specification [RFC2460] (FW, IPS, APFW) *
• IPv6 Addressing Architecture [RFC4291] (FW, IPS, APFW)
• Default Address Selection [RFC3484] (FW, IPS, APFW)
• ICMPv6 [RFC4443] (FW, IPS, APFW) *
• SLAAC [RFC4862] (FW, IPS) *
• Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] *
• Inspecting IPv6-in-IPv4 protocol-41 traffic, which is specified in: Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] (IPS)
• Router-Alert option [RFC2711] (FW, IPS)
• Path MTU Discovery [RFC1981] (FW, IPS, APFW) *
• Neighbor Discovery [RFC4861] (FW, IPS, APFW) *
• If the request is for the BGP4 protocol, the equipment must comply with RFC4271, RFC1772, RFC4760 and RFC2545 (FW, IPS, APFW)
• If the request is for a dynamic internal gateway protocol (IGP), then the required RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] must be supported. The contracting authority shall specify the required protocol. (FW, IPS, APFW)
• If OSPF-v3 is requested, the device must support "Authentication/Confidentiality for OSPFv3" [RFC4552] (FW, IPS, APFW)
• Support for QoS [RFC2474, RFC3140] (FW, APFW)
• If tunneling is required, the device must support Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] (FW)

A Network Security Device is often placed where a Layer 2 switch or a router/Layer 3 switch would otherwise be placed. Depending on this placement those requirements should be included.

Functionality and features that are supported over IPv4 should be comparable with the functionality supported over IPv6. For example, if an intrusion prevention system is capable of operating over IPv4 in Layer 2 and Layer 3 mode, then it should also offer this functionality over IPv6. Or if a firewall is running in a cluster capable of synchronising IPv4 sessions between all members of a cluster, then this must also be possible with IPv6 sessions.

Optional support:

• IPv6 Router Advertisement Options for DNS Configuration [RFC6106]
• DHCPv6 client/server/relay [RFC3315] *
• Extended ICMP for Multipart Messages [RFC4884]
• SeND [RFC3971]
• SLAAC Privacy Extensions [RFC4941]
• Stateless DHCPv6 [RFC3736] *
• DHCPv6 PD [RFC3633] *
• BGP Communities Attribute [RFC1997]
• BGP Capabilities Advertisement WITH-4 [RFC3392]
• (QOS) Assured Forwarding [RFC2597]
• (QOS) Expedited Forwarding [RFC3246]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]
• Cryptographically Generated Addresses [RFC3972]
• IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] *
• Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW)
• OSPF-v3 [RFC5340]
• Authentication/Confidentiality for OSPF-v3 [RFC4552]
• Generic Packet Tunneling and IPv6 [RFC2473]
• SNMP protocol [RFC3411]
• SNMP capabilities [RFC3412, RFC3413, RFC3414]
• SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
• DNS extensions to support IPv6 [RFC3596]
• DNS message extension mechanism [RFC2671]
• DNS message size requirements [RFC3226]
• Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC4891]
• Multicast Listener Discovery version 2 [RFC3810] *
• MLDv2 snooping [RFC4541] (when in L2 or passthrough mode) *
• Packetisation Layer Path MTU Discovery [RFC4821]
• IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5739]
• IPv6 Host-to-Router Load Sharing [RFC4311]
• Default Router Preferences and More-Specific Routes [RFC4191]

Requirements for CPE equipment

Mandatory support:

• RFC6204 (Basic Requirements for IPv6 Customer Edge Routers) *

Optional support:

• IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] *
• If support for mobile IPv6 is required, the device needs to comply to “MIPv6” [RFC6275, RFC5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC4877]
• Extended ICMP for multi-part messages [RFC4884]
• SeND [RFC3971]
• SLAAC Privacy Extensions [RFC4941]
• DS (Traffic class) [RFC2474, RFC3140]
• Cryptographically Generated Addresses [RFC3972]
• SNMP protocol [RFC3411]
• SNMP capabilities [RFC3412, RFC3413, RFC3414]
• SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
• Multicast Listener Discovery version 2 [RFC3810] *
• Packetisation Layer Path MTU Discovery [RFC4821]
• IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969]
• Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [RFC6333] If support this then also must support Dynamic Host Configuration protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite [RFC6334]
• The A+P Approach to the IPv4 Address Shortage [RFC6346]
• IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5739]
• IPv6 Host-to-Router Load Sharing [RFC4311]
• Default Router Preferences and More-Specific Routes [RFC4191]

Requirements for mobile devices

Mandatory support:

• IPv6 basic specification [RFC2460] *
• Neighbor Discovery for IPv6 [RFC4861] *
• IPv6 Stateless Address Autoconfiguration [RFC4862] *
• IPv6 Addressing Architecture [RFC4291] *
• ICMPv6 [RFC4443] *
• IPv6 over PPP [RFC2472]
• Multicast Listener Discovery version 2 [RFC3810] *
• IPv6 Router Alert Option [RFC2711]
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]

Optional support:

• Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC4941]
• Path MTU Discovery for IPv6 [RFC1981] *
• Generic Packet Tunneling for IPv6 [RFC2473]
• DHCPv6 [RFC3315] *
• Stateless DHCPv6 [RFC3736]
• DHCPv6 option for SIP servers [RFC3319]
• IPv6 Prefix Options for DHCPv6 [RFC3633]
• Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pd-exclude]
• Default Address Selection [RFC3484]
• IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] *
• IKEv2 Mobility and Multihoming Protocol MOBIKE [RFC 4555]
• IPv6 Host-to-Router Load Sharing [RFC4311]
• Default Router Preferences and More-Specific Routes [RFC4191]

References:

• 3GPP
• Internetworking Between Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) [3GPP TS 29.061]
• GPRS Service Description [3GPP TS 23.060]
• General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access [3GPP TS 23.401]
• Signaling flows for IP multimedia Call control based on SIP and SDP [3GPP TS 24.228]
• IP multimedia call control protocol based on SIP and SDP [3GPP TS 24.229]
• IP Based Multimedia Framework [3GPP TS 22.941]
• Architectural Requirements [3GPP TS 23.221]
• Packet domain; Mobile Stations (MS) Supporting Packet Switching Service [3GPP TS 27.060]
• IPv6 migration guidelines [3GPP TR 23.975]
• IETF
• IPv6 for Some Second and Third Generation Cellular Hosts [RFC3316]
• Recommendations for IPv6 in 3GPP Standards [RFC3314]
• IPv6 in 3rd Generation Partnership Project (3GPP) [RFC6459]

Requirements for load balancers

A load balancer distributes incoming requests and/or connections from clients to multiple servers. Load balancers will have to support several combinations of IPv4 and IPv6 connections:

• Load balancing IPv6 clients to IPv6 servers (6-to-6) must be supported
• Load balancing IPv6 clients to IPv4 servers (6-to-4) must be supported
• Load balancing IPv4 clients to IPv4 servers (4-to-4) should be supported
• Load balancing IPv4 clients to IPv6 servers (4-to-6) should be supported
• Load balancing a single external/virtual IPv4 address to a mixed set of IPv4 and IPv6 servers should be supported
• Load balancing a single external/virtual IPv6 address to a mixed set of IPv4 and IPv6 servers should be supported

If a load balancer provides Layer 7 (application level / reverse proxy, defined as ‘surrogate’ in section 2.2 of RFC3040) load balancing then support for the X-forwarded-for (or equivalent) header in HTTP must be provided in order to make the source IP address of the client visible to the servers.

Mandatory support:

• IPv6 Basic specification [RFC2460] *
• IPv6 Addressing Architecture [RFC4291] *
• Default Address Selection [RFC3484]
• Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]
• ICMPv6 [RFC4443] *
• Path MTU Discovery [RFC1981] *
• Neighbor Discovery [RFC4861] *
• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC3596]
• DNS message extension mechanism [RFC2671]
• DNS message size requirements [RFC3226]
• Deprecation of Type 0 Routing Headers in IPv6 [RFC5095] *

Optional support:

• IPv6 Router Advertisement Options for DNS Configuration [RFC6106]
• Extended ICMP for multi-part messages [RFC4884]
• SeND [RFC3971]
• DS (Traffic class) [RFC2474, RFC3140]
• Cryptographically Generated Addresses [RFC3972]
• SNMP protocol [RFC3411]
• SNMP capabilities [RFC3412, RFC3413, RFC3414]
• SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
• Multicast Listener Discovery version 2 [RFC3810] *
• Packetisation Layer Path MTU Discovery [RFC4821]
• NAT64/DNS64 [RFC6146, RFC6147]
• If support for IPsec is required, the device must support IPsec/IKEv2 [RFC4301, RFC4303, RFC4302, RFC5996] * and Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5685]
• If support for BGP4 is required, the equipment must comply with RFC4271, RFC1772, RFC4760 and RFC2545
• If support for a dynamic internal gateway protocol (IGP) is required, the RIPng [RFC2080], OSPF-v3 [RFC5340] or IS-IS [RFC5308] must be supported. The contracting authority shall specify the required protocol.
• If OSPF-v3 is requested, the device must support "Authentication/Confidentiality for OSPFv3" [RFC4552] (FW, IPS, APFW)
• IPv6 Host-to-Router Load Sharing [RFC4311] (FW)
• Default Router Preferences and More-Specific Routes [RFC4191] (FW)

Requirements for IPv6 support in software

All software must support IPv4 and IPv6 and be able to communicate over IPv4-only, IPv6-only and dual-stack networks. If software includes network parameters in its local or remote server settings, it should also support configuration of IPv6 parameters.

All features that are offered over IPv4 must also be available over IPv6. The user should not experience any noticeable difference when software is communicating over IPv4 or IPv6, unless this is providing explicit benefit to the user.

It is strongly recommended not to use any address literals in software code, as described in “Default Address Selection for Internet Protocol version 6” [RFC3484].

Skill requirements of the systems integrator

Vendors and resellers that offer system integration services must have at least three employees who have valid certificates of competency from the equipment manufacturers for the equipment that is sold as part of the tender. These employees must also have general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security (as also indicated by the certification for these skills). If it becomes obvious during the equipment installation and integration that the integrator’s knowledge, competence and experience is not sufficient to successfully install and configure the equipment to establish normal IPv4 and IPv6 communication with the network, the agreement shall be canceled and become null and void.

The definition of proper integration, timing and degree of disruption of the network during the assembly shall be a matter of agreement between the client and systems integrator.

It is also recommended that a systems integrator and its employees have a broad knowledge of IPv6 and generic IPv6 certificates other than those specifically offered by the equipment manufacturers. These certificates can be obtained from independent education providers. Such knowledge may be awarded extra points in the tender process.

All bidders in the tender process must sign a declaration, which indicates that the company and its employees have passed technical training for design, construction and integration of ICT equipment in IPv4 and IPv6 networks. A sample of such a declaration is shown below.

Declaration of IPv6 competence

Tender initiators should require technical IPv6 competence declaration from the equipment supplier or integrator. IPv6 knowledge and experience is required to assure proper installation and integration of IPv6 in the ICT environment.

The declaration should say that the equipment supplier or system integrator declares under criminal and material responsibility:

• That they have a sufficient number of people employed to perform offered services;
• That those employees are professionally trained for their work - design, construction and integration of ICT equipment in both IPv4 and IPv6 networks and environments;
• That the quality of offered services meets the requirements laid out in the tender documents, and that these requirements apply to both IPv4 and IPv6.

Note that declarations like this can vary depending on local legislation. Therefore translators and tender initiators should get legal advice on the exact wording for these requirements.

Acknowledgments

The first version of this document was done in the Go6 Expert Council and the Slovenian IPv6 working group.

The authors would like to thank everyone involved in the creation and modification of previous version of this document. First of all, we would like to thank Janez Sterle, Urban Kunc, Matjaz Straus, Simeon Lisec, Davor Sostaric and Matjaz Lenassi from Go6 Expert Council for their enthusiastic governance of this document. We recognise the work done in the Slovenian IPv6 working group for their review and useful input. Special recognition goes to Ivan Pepelnjak, Andrej Kobal and Ragnar Us for their efforts and work done on the document. Thanks also to the co-Chairs of RIPE IPv6 Working Group, David Kessens, Shane Kerr and Marco Hogewoning for their support and encouragement. We would also like to thank Patrik Fältström, Torbjörn Eklöv, Randy Bush, Matsuzaki Yoshinobu, Ides Vanneuville, Olaf Maennel, Ole Trøan, Teemu Savolainen and people from RIPE IPv6 Working Group (Joao Damas, S.P. Zeidler, Gert Doering among others) for their input, comments and review of the document. Last but not least, we would like to thank Chris Buckridge and the Communications Team from the RIPE NCC for correcting our grammar and wording in this document. And everyone else who contributed to this work.

The authors of this document would like to thank the RIPE IPv6 Working Group and its chairs for all of the support and encouragement to develop a follow-up version of the document. Special thanks goes to Ole Trøan, editor of RFC6204 for his help in the CPE section and for suggesting other changes across the document. Thanks to Marco Hogewoning, Ivan Pepelnjak and S.P. Zeidler for great input in ideas how to make the document structure and content better, Timothy Winters and Erica Johnson (both IPv6 Ready Logo committee, UNH) for help in marking RFCs they test and constructive suggestions. Thanks also to Yannis Nikolopoulos and Frits Nolet. Special thanks goes to Jouni Korhonen, Jari Arkko, Eric Vyncke, David Freedman, Tero Kivinen and Michael Richardson for some very useful comments and suggestions that made this document much better.

Suggestions for improvement to this document and other comments can be sent to to the RIPE IPv6 Working Group mailing list <ipv6-wg@ripe.net>.

[1]The USGv6 specifications are currently undergoing an updated revision which is expected to be completed by early 2012

[2] The IETF Source Address Validation Improvements (SAVI) Working Group is currently working on RFCs that specify a framework for source address validation. Once these RFCs are published, the NUD and DAD filtering references can be changed accordingly.

This document describes the new value of the "status:" attribute and the "assignment-size:" of the inet6num object

1.0 Motivation

For verification of efficient use of allocated space, there is a requirement for LIRs to keep records of IPv6 address assignments made to End Users. However, for calculating the efficiency (HD-ratio) there is no need to keep track of personal data associated with these assignments. The number and size of the assignments is sufficient to calculate the HD-ratio and verify efficiency.

To standardise these registrations and to provide an open and transparent method of verification, this document introduces a new value of the "status:" attribute for inet6num objects (AGGREGATED-BY-LIR) and a new attribute called "assignment-size:". This new value allows for the creation of inet6num objects indicating these are aggregated End User assignments, using the "assignment-size" attribute to indicate the size of the individual End User assignments in this aggregate

2.0 Database Objects Affected

Only inet6num objects may contain a "status:" value of "AGGREGATED-BY-LIR" or attribute called "assignment size:". When the inet6num has a status of "AGGREGATED-BY-LIR", the "assignment-size" attribute is required. In all other cases the attribute is optional.

3.0 Usage

The <AGGREGATED-BY-LIR> value allows to register individual End User assignments by means of a less specific aggregate object that contains multiple assignments of the same size, which is indicated in the "assignment size:" attribute.

This allows for efficient registration of assignments in cases where there is no need or it is not possible to register the details of individual End Users. An example of this would be the use of dynamic address pools for broadband Internet access.

If, for instance, you wish to create a pool of 1000 /56 assignments, you would create an object similar to:

 inet6num:                  2000::/46
 status:                    AGGREGATED-BY-LIR
 assignment-size:           56
 <…>

This would indicate block of a /46 is further split into /56 End User assignments. Optionally the "remarks:" and "description:" attributes can be used to further clarify the usage or for instance give hints such as "used for dynamic assignments".

When needed, more specific inet6num objects are allowed to indicate a different assignment size within a certain range however, only one level of more specifics is allowed.

4.0 Functionality

When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules:

• The inet6num object may contain an optional attribute called "assignment-size:".
• The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself.
• A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or “AGGREGATED-BY-LIR”.
• When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:" attribute becomes required.

1.0 Introduction
2.0 Definition
3.0 Policy
4.0 Warning
5.0 Obtaining the Address Space

1.0 Introduction

Internet Exchange Points (IXPs) are used to exchange Internet traffic between different Internet Service Providers (ISPs). Many Exchange Point operators require address space for the peering mesh that is independent from any of the address space in use by member networks.

2.0 Definition

An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity whose purpose is to facilitate the exchange of Internet traffic between ISPs.

There must be a minimum of three ISPs connected and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be acquired through the appropriate means (e.g. an upstream ISP).

3.0 Policy

Requesting organisations that meet the definition in section 2.0 may receive address space to meet their needs. If the requesting organisation is confident that it will never need more than a single network then a /64 will be assigned.

Otherwise, a /48 will be assigned.

The prefix will be assigned by the RIPE NCC directly to the IXP, upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. IXP IPv6 address 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”.

4.0 Warning

Networks assigned under this policy may not be globally routable.

5.0 Obtaining the Address Space

Address space for IXPs qualifying under this policy can be requested by using the form "IPv6 Request Form for Internet Exchange Points" available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html

% IPv6 First Allocation Request Form

% RIPE NCC members can use this form to request their first IPv6 Allocation.
% Please see http://www.ripe.net/ripe/docs/ipv6-first-alloc-support.html 
% for instructions on how to complete this form.

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

request-type: ipv6-first-alloc
form-version: 1.1
x-ncc-regid: 

#[REQUESTER TEMPLATE]#
%
% Please add your contact details.

name: 
phone: 
fax-no: 
e-mail: 
nic-hdl:

#[REQUIRED INFORMATION]#
%
% Do you accept the IPv6 Address Allocation and Assignment
% Policy? (Yes/No)

confirmation:

% If you have any online information about your future
% IPv6 services, please add the URL below.

website:

#[OVERVIEW OF ORGANISATION TEMPLATE]#
%
% Please add a short description of your organisation.

org-description:

% If your organisation has IPv6 allocations from any of the Regional
% Internet Registries (RIR), please list the ranges below.

other-allocation:

% Will the whole organisation use the requested allocation? If
% another part of the organisation will request separate IPv6
% address space from any RIR, please inform us below. (Whole/Part)

for-whole-or-part-of-the-organisation:

#[IPv6 ALLOCATION USAGE PLAN]#
%
% When will you use this address space?
%
%       Subnet       Within     Within   Within
%       size (/nn)   3 months   1 year   2 years   Purpose

subnet:
subnet:

#[DATABASE TEMPLATE(S)]#
%
% Please complete all of the fields below.
% 
% You can find more information on how to complete these fields
% in the supporting notes (ipv6-first-alloc-support.html). 

inet6num:   <leave empty>
netname:    <leave empty>
descr:      <add LIR organisation name> 
country:    <add country code>
org:	    <add org-ID>
admin-c:    <add nic-hdl of administrative contact>
tech-c:     <add nic-hdl of technical contact>
status:     ALLOCATED-BY-RIR
mnt-by:     RIPE-NCC-HM-MNT 
mnt-lower:  <add mntner name>
mnt-routes: <add mntner name>
notify:     <add email address>
changed:    hostmaster@ripe.net
source:     RIPE 

#[INSERT SUPPLEMENTAL COMMENTS]#
%
% Please add more information if you have specific addressing needs.

<add more information>

#[END of REQUEST]#

The instructions are based on the “IPv6 Address Allocation and Assignment Policy”.

• General Information
• Requester Template
• Required Information
• Overview of Organisation Template
• IPv6 Allocation Usage Plan
• Database Template(s)
• Insert Supplemental Comments
• End of Request

General Information

	#[GENERAL INFORMATION]# 
	% 
	% Please add your RegID. 
	request-type: ipv6-first-alloc 
	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>.

Requester Template

             
	#[REQUESTER TEMPLATE]# 
	% 
	% Please add your contact details.
	name: John Smith 
	phone: +123 45 678910 
	fax-no: +123 45 678911 
	email: john@bluelight.ripe.net 
	nic-hdl: HOHO1-RIPE
				

Enter your contact details in the requester template. You must be a registered contact for the LIR. The LIR Portal contains the list of registered contacts for your LIR.

Please use international dialling codes (for example, +31 for the Netherlands,) in the “ phone:” and “ fax-no:” fields.

Enter your NIC handle, if you have one, in the “ nic-hdl:” field.

Required Information

	#[REQUIRED INFORMATION]# 
	% 
	% Do you accept the IPv6 Address Allocation and Assignment 
	% Policy? (Yes/No) 
	confirmation: yes 
	% If you have any online information about your future 
	% IPv6 services, please add the URL below. 
	website: http://www.bluelight.ripe.net/ipv6-connectivity.html

You must read the IPv6 Address Allocation and Assignment Policy. Enter ‘yes’ in the “ confirmation:” field if you agree to follow this policy.

If you have any online information about your planned IPv6 services, enter the URL in the “ website:” field.

Overview of Organisation Template

	#[OVERVIEW OF ORGANISATION TEMPLATE]# 
	% 
	% Please add a short description of your organisation. 
	org-description: Bluelight B.V. is an ISP. We will
	make IPv6 connectivity available to all 10,000 of our ADSL customers. 
	% If your organisation has IPv6 allocations from any of the Regional 
	% Internet Registries (RIRs), please list the ranges below. 
	other-allocation: none 
	% Will the whole organisation use the requested allocation? 
	% If another part of the organisation will request separate IPv6 
	% address space from any RIR, please inform us below. (Whole/Part) 
	for-whole-or-part-of-the-organisation: whole

In the “ org-description:” field, write a short description of your organisation. Include information about your IPv6 services and customers.

Use the “ other-allocation:” field to list all the IPv6 allocations that you already have. These can be from any RIR. You can repeat this field as many times as needed.

Enter ‘part’ in the “ for-whole-or-part-of-the-organisation:” field if any part of your organisation, anywhere in the world, will request separate IPv6 address space. Otherwise, enter ‘whole’.

IPv6 Allocation Usage Plan

	#[IPv6 ALLOCATION USAGE PLAN]# 
	% 
	% When will you use this address space?
	% 
	%          Subnet     Within   Within  Within 
	% 	   size (/nn) 3 months 1 year  2 years 	Purpose
	subnet:		/45	x	-	-	8 ADSL POPs
	subnet:		/42	-	x	-	Corporate (64 /48s)
	subnet:		/48	-	-	x	SOHOs (256 /56s)
	

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

If an End Site needs more than a /48, a separate request form must be submitted.

In the “ Purpose” column, write a short description of each subnet. If needed, you can write a more detailed description in the “ Insert Supplemental Comments” section at the end of this 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.

Database Template(s)

	#[DATABASE TEMPLATE(S)]# 
	% 
	% Please complete all of the fields below. 
	inet6num: 
	netname: 
	descr: Bluelight B.V. 
	country: NL 
	org: ORG-Bb2-RIPE 
	admin-c: HOHO1-RIPE 
	tech-c: HOHO1-RIPE 
	status: ALLOCATED-BY-RIR 
	mnt-by: RIPE-NCC-HM-MNT 
	mnt-lower: BLUELIGHT-MNT 
	mnt-routes: BLUELIGHT-MNT 
	notify: john@bluelight.ripe.net 
	changed: hostmaster@ripe.net
	source: RIPE

Leave the “ inet6num:” and “ netname:” fields empty as we (the RIPE NCC) will complete them.

Enter the legal name of the LIR’s organisation in the “ descr:” field.

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

Enter the org-ID of the LIR’s organisation object in the “ org:” field. If you don’t know your LIR’s org-ID, you can find it in the Organisation Object Editor (https://lirportal.ripe.net).

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 ALLOCATED-BY-RIR.

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

The “ mnt-by:” field must be RIPE-NCC-HM-MNT.

The “ mnt-lower:” field shows which maintainer authorises the creation of inet6num objects (assignments) within the allocated block.

The “ mnt-routes:” field shows which maintainer authorises the creation of route6 objects for the allocated block.

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

We will send an e-mail to the e-mail address in the “ notify:” field every time the inet6num allocation object is updated.

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

The “ source:” field must be RIPE.

Insert Supplemental Comments

	
	#[INSERT SUPPLEMENTAL COMMENTS]# 
	% 
	% Please add more information if you have specific 
	% addressing needs. 
	We will make the IPv6 connectivity available first to our large 
	corporate customers and then our small business users (SOHOs). 
	The next phase will be to offer the connectivity to 
	our private users. 
	Our large corporate customers will receive a /48. The small business
	users and private users will receive a /56.

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

End of Request

	
	#[END of REQUEST]#

1. Introduction
2. Background
2.1 The Early Internet
2.2 Today's Internet
3. What is Aggregation?
4. The Internet Routing Table
4.1 Deaggregation
4.2 General Deaggregation
4.3 iBGP and eBGP
4.4 Deaggregation to aid Multihoming
4.5 Legacy Assignments
5. Impacts of the Routing Table Size
5.1 Router Memory
5.2 Router Processing Power
5.3 Routing Convergence
5.4 Network Performance
6. Solutions
6.1 The CIDR Report
6.2 Filtering
6.3 The "CIDR Police"
6.4 BGP Features
6.4.1 The NO_EXPORT BGP Community
6.4.2 The NOPEER BGP Community
6.4.3 The "AS_PATHLIMIT:" Attribute
6.4.4 Provider-Specific Communities
7. Recommendations
7.1 Initial Allocations
7.2 Subsequent Allocations
7.3 Multihoming
7.4 BGP Enhancements
7.5 Proxy Aggregation
7.6 IP Version 6
8. Conclusion
9. Acknowledgments
Y. References
Z. Authors

1. Introduction

The Internet is made up of autonomous networks (usually called Autonomous Systems or AS) interconnected with each other.  These autonomous networks will have over time been assigned or allocated address space for use within their own networks, or networks of their customers.  This address space is announced to neighbouring autonomous networks.  Depending on the business or contractual arrangements between these neighbouring autonomous networks, this address space may or may not announced to the neighbouring autonomous networks of these networks.  And so on, across the entire Internet.

The collection of this address space as announced by the organisational entities making up the Internet is known as the Internet Routing Table.

With each AS announcing their address space, and each AS hearing this announcement either directly or indirectly, each end system in the Internet is able to communicate with other end systems, thereby giving the global communications system known as the Internet.

2.  Background

As documented in the CIDR Report [1] and other similar activities, the size of the Internet Routing Table has been of considerable interest to Internet Service Providers and the vendors of Internet routing equipment since the rapid adoption of the Internet as a communications medium in the early 90s.

2.1 The Early Internet

In the early Internet, address space assigned to Autonomous Systems and End Sites fitted into three categories: class A, class B, and class C. The Internet Routing Table contained only these three types of addressing, small organisations receiving a class C, medium sized organisations receiving a class B, and large organisations receiving a class A.  This was known as classful address assignment, and the routing system associated with it understood the different classes.

A major effort in 1994, saw the Internet start the conversion from using this classful prefix system to using a classless system ([2] and [3]). The motivation for this was the rapid depletion of the classful address space, with biggest pressure being on the address space range being used for class B networks (128.0.0.0 to 191.255.0.0).

With the commercialisation of the Internet and prior to the migration to the classless addressing system, organisations which had grown out of their requirements for a single class C network would receive further class C networks, rather than being "upgraded" to a class B network.  This was designed to reduce the pressure on the class B address block.

The result of this was that many organisations had a large amount of class C address blocks for their use - or a large number of /24 prefixes, using today's terminology.  As part of the migration to the classless routing system, the CIDR Report's original motivation was to encourage network operators to merge their contiguous /24 prefixes into a single larger announcement.  This activity is called aggregation and will be explained in detail in subsequent sections.

The CIDR Report was quite successful in encouraging aggregation.  The weekly public e-mail to Operations mailing lists helped point out those ISPs who were making efforts at aggregating their announcements to the Internet.  The results of this peer pressure are visible in the early stages of the graphs available on the CIDR Report website ([1] and [4]).

2.2 Today's Internet

In the classless Internet today, network operators who participate in the Regional Internet Registry (RIR) system will receive allocations from the RIRs (AfriNIC, APNIC, ARIN, LACNIC & RIPE NCC).  These allocations will be of the size requested from the RIRs according to the network operators' requirements, and generally will be of a minimum size, for example a /21.

Following the introduction of the classless allocation system and classless routing in 1994, network operators would receive an address block from their RIR, and would generally announce this address block to the Internet.  This happens in the same way that operators in the early Internet would announce only the class A, class B, or class C they had been assigned.

While there is a widely known and unwritten expectation that the address block allocated by the RIR is what would be announced by the network operator to the Internet, the more common practice today seems to be to still announce /24s (the equivalent of the legacy class Cs).  The result is that around 60% of the Internet Routing Table consists of /24 prefixes.

Some of the /24 announcements are undoubtedly caused by traffic engineering efforts for multihoming (an activity recognised as a requirement in the industry by the authors of RFC1519 - [3]).  However, the majority can be attributed to ISPs "receiving 32 Class Cs from the RIR" and announcing them as such.  (Expected behaviour would be to combine these into a single announcement with a /19 network mask.)

3.  What is Aggregation?

Aggregation is the activity of introducing several contiguous IP addresses as a single address block into the IP routing system (using BGP).  For example, if an enterprise has received 32 IP addresses from their ISP for numbering the systems on their internal LAN, they would announce these 32 IP addresses to their ISP as a single entity.  Each device on the LAN can be represented by the address block, rather than their presence having to be uniquely indicated to the rest of the world.

For example, if the enterprise receives contiguous addresses from 192.0.2.0 to 192.0.2.31, they would announce this to their ISP as 192.0.2.0/27.  This format says that the first 27 bits of the IP address is the network portion, with the final five bits being the host portion.

Likewise, on a larger scale, if an ISP has received 4,096 IP addresses from the RIR, for example 10.201.48.0 to 10.201.63.255, they would announce these IP addresses as a single address block to their neighbouring networks, so as 10.201.48.0/20.

Both these examples describe what is known as aggregation.  The end network has combined contiguous addresses into a single entity, and this single entity is announced to neighbouring Autonomous Systems.

While these two examples are relatively small scale examples, they indicate the activities of ISPs who participate in the Internet - individual IP addresses are combined into the largest feasible chunk before they are announced to the Internet.

Proxy aggregation is when an ISP, for example, takes contiguous prefix blocks announced to it by other networks (usually by BGP) and aggregates them into a single larger announcement originated from their own network.

4.  The Internet Routing Table

There are but a few contributory factors to the size of the Internet Routing Table.  These are analysed in turn.

4.1 What is Deaggregation?

The RIRs allocate address space to ISPs in blocks, with the expectation that these blocks are announced to the Internet unaltered.  It should be noted that the RIRs have no rules about how this address space should be announced to the Internet.  The industry considers it improper for the RIRs to tell ISPs how to announce address space; in the same way that libraries won't tell their readers how to read the books it lends.

However, many ISPs don't announce their allocations as single blocks as they are expected to, preferring to announce their address space in smaller pieces, even as small as /24s.  This activity is known as deaggregation.

4.2 General Deaggregation

There seem to be several reasons for this deaggregation.  Some providers claim that they have commercial reasons for doing so; some cite routing system security concerns; others claim it reduces bandwidth wasting virus and miscreant activities against their networks.

Routing system security is a general concern for many providers around the Internet.  There is no universally accepted or used system for ensuring that a provider is entitled to originate any address block.  (While the Internet Routing Registry was designed to assist with this, its use has never been made mandatory, and the routing system still works well without it.) The result is that some providers work around their concerns about the relative lack of routing system security by simply announcing the smallest acceptable prefix.  This means that no other autonomous system can announce more specific versions of the same prefixes thereby causing a denial of service on the legitimate user of the address space.  However, the authors are aware of very few such incidents being recorded, so deaggregation for security reasons seems a somewhat overly unfriendly activity compared with the potential risk.

Another claimed reason for deaggregation is the claim that it reduces denial of service attacks and miscreant activities aimed at a service provider network.  It is well known that there are many virus and worm ridden systems around the Internet that simply carry out scans of contiguous address blocks (whether routed or not) looking for other systems to infect.  This creates a "background noise" of traffic aimed at an address block.  In the authors' experience, the announcement of a /16 address block can attract up to 2Mbps of this noise - in developing parts of the Internet, such bandwidth is an expensive proposition for ISPs, so they only announce what they are actually using.  As each /24 is consumed by their infrastructure and their customers, they'd announce the /24 to the Internet (and quite often this /24 is not sequential to any previous internal assignments).  Even when the original /19 allocation was entirely used, the ISP makes no effort to aggregate it (in their eyes nothing is broken, so doesn't require fixing), with the resulting impact on the size of the global Routing Table.

It is likely that the blanket "we have commercial reasons for deaggregation" claimed by some providers includes concerns about both of the previous scenarios.  It is also quite likely that there are other commercial reasons; one example heard in previous years was that appearing in the top 10 of the CIDR Report was considered a positive reflection on the size and quality of the ISP's business.

4.3 iBGP and eBGP

A further reason for deaggregation seems to be a failure to appreciate the difference between BGP as used inside the SP network (iBGP), and BGP as used for inter-domain routing (eBGP).  iBGP is intended to carry all the ISP's customer prefixes and local infrastructure prefixes (hosting LANs, etc), as well as prefixes learned from other SP networks.  eBGP is intended to announce reachability between domains, and this can simply be achieved by each ISP announcing the address blocks they have been allocated by the RIRs.  Quite often ISPs happily leak their iBGP routing information into eBGP, with the resulting impact on the size of the Internet Routing Table.

Perhaps the most interesting location where the differences between an ISP's iBGP and eBGP can be examined would be at the University of Oregon Route Views project [5].  This project has views of the Internet Routing Table as seen by many different ISPs around the world.  Some ISPs choose to send their eBGP view, others choose to send their iBGP view.  The Route Views project makes no demands on what should or should not be sent.  This then provides an interesting insight into aggregation efforts made by ISPs, the extent of iBGP for some of the larger ISPs, and the filtering efforts made by other ISPs to remove iBGP views received from their peers across the Internet routing infrastructure.

4.4 Deaggregation to aid Multihoming

The need to deaggregate as part of traffic engineering activities for networks who multihome is an oft quoted reason or absolute justification for the size of the Internet Routing Table.  It seems that standard multihoming practice these days is to take any address allocation or assignment, chop it into individual /24s, and announce these /24s out of all external network links.

A /24 is chosen for this activity as there is a belief that most ISPs will filter IP prefixes on a /24 boundary (being the size of the legacy class C address), even though there is little evidence to back this belief up, as a cursory glance at the CIDR Report [1] will show.

Furthermore, the theory behind announcing an address block only as /24s is that this will somehow make multihoming work.  In the authors' experience this is not the case, as successful traffic engineering and load balancing is only achieved by announcing appropriate sub-prefixes of an allocated address block depending on traffic levels generated by devices occupying these sub-prefixes.

The result of this scatter gun approach is a further contribution to the increase in the size of the Internet Routing Table.

4.5 Legacy Assignments

Often blamed for the Internet Routing Table size are legacy assignments. These are assignments made by the IANA prior to the establishment of the RIR system.  However, the main contributor to the Internet Routing Table from legacy assignments was from the 192/8 block, the first /8 block in the former class C space.  After the clean up (where many operators aggregated their classful addresses where possible) post-migration to classless routing, the 192/8 address block has remained at contributing around 5,500 prefixes to the Internet Routing Table.  This compares more than favourably with other /8 blocks which the RIRs use for allocations to ISPs, where completed blocks often contribute 8000 or 9000 prefixes each.

Looking into the former class B space (128/8 up to 191/8), there is significant deaggregation in the legacy class B assignments, but more than likely caused by issues discussed in the previous two sections.  The same is true for legacy assignments in the former class A space.

5.  Impacts of the Routing Table Size

Why should the size of the Internet Routing Table matter?  In the discussion so far, little more than prudence has been mentioned in what should be announced to the Internet.  But there are many issues facing Autonomous Systems participating in the Internet today.

5.1 Router Memory

Throughout the history of the Internet, routing equipment vendors have specified routing equipment to be sufficient for the networks of the day. In the rapidly growing Internet, this has caused anguish for operators at various stages.  A rapidly growing Internet has seen routers with sufficient memory to carry the full table one year become obsolete the following year; even with the router being upgraded to maximum memory it still has not sufficient capacity to store the table as it stands.

Newer model routers with larger memory are the natural replacements, meaning a very short shelf life of a router compared with other components in the Internet.  These equipment upgrades result in upheaval in the service provider networks.

5.2 Router Processing Power

Another resource under pressure is that of the router CPU (control plane). The larger the Internet Routing Table is, the longer it takes the router CPU to process on initial establishment of the BGP session with neighbouring Autonomous Systems, and the more time the router CPU requires to process changes in this Routing Table due to topology changes.  Faster CPUs reduce this time, so the network operator is faced with having to upgrade router CPUs, often by fork-lift upgrades (swapping entire chassis), just to keep the same routing performance within their network.

A typical scenario was presented in [6] following a request to provide a prediction on the size of routers needed in five years time - the shelf life of existing router hardware is reducing with the increasing size of the table and the increasing number of routing information updates being seen on the Internet.

5.3 Routing Convergence

Routing convergence is when the network has finally figured out the best path to a particular destination.  It needs to happen every time a route is withdrawn or re-announced; this computation takes time.

The two keys factors affecting the time it takes for routing to converge are the router CPU and routing table size.  The more prefixes there are in the Internet Routing Table, the more work a router will have to do to find the new routes.  This time can be reduced by using a faster CPUs, usually by going to the expense and inconvenience of upgrading the control plane; replacing the entire router chassis (so-called fork-lift upgrade) introduces even greater costs for the operator, not to mention the impact of network down-time.  The alternative is by reducing the size of the Internet Routing Table through aggregating prefixes into as few announcements as possible.

Slow convergence means slow recovery in the event of network failure, and results in a much more customer visible network issue.

5.4 Network Performance

The performance of the network is something that network operators don't consider has anything to do with prefix announcements to the Internet.

However, it is relatively easy to demonstrate that failure to announce the aggregate makes the overall Internet experience of the end users of the local network somewhat poorer than if the aggregate was announced.

A typical and common situation that the authors have encountered is where a network operator announces prefixes in their internal BGP out to the Internet (by external BGP).  Customer prefixes are injected into the internal BGP when the link to the customer is active, and then withdrawn when the link to the customer is inactive.  The problem with leaking the internal BGP out to the Internet is that these customer prefixes have to be withdrawn from all the routers which carry the full Internet Routing Table across the entire Internet.  And this withdrawal does not happen instantly [7] or uniformly, with the attendant problems this causes.  When the customer link returns, their prefix is re-injected into their provider's internal BGP, and then further announced out to the Internet. The propogation of the out-bound announcement again doesn't happen instantly.

The result of all this is that the End User sees the Internet as being not immediately available once their link returns.  Support calls to their service provider are handled negatively because as far as the service provider is concerned there is nothing wrong.

If the service provider had not leaked their internal BGP to the Internet, but instead announced their aggregate and any necessary traffic engineering sub-prefixes, their customer would not have seen the delays in the restoration of usability of their Internet connection.

6. Solutions

Various solutions to the problem of the growth of the Internet routing table have been proposed and attempted over recent years.

6.1 The CIDR Report

The CIDR Report originally was one technique employed to hold the Internet Routing Growth in check.  The idea behind the CIDR Report was to encourage ISPs to aggregate.  Its effectiveness was primarily through peer pressure, naming and shaming.  It was effective in the early years of the migration from classful to classless Internet, but in recent years, there is some evidence of ISPs using their prominent position in the CIDR Report as positive marketing regarding their status and influence in the Internet!

In recent years the CIDR Report has been greatly enhanced over the early reporting tool, with the associated website [1] having a user interface to allow network operators to check their aggregation efforts.  The CIDR Report even includes a tool which will take the routing table view it has for a particular ASN and suggest aggregation possibilities.  There is little reason for any network operator to be unaware of their announcements to the Internet Routing Table, and also little excuse for them not knowing how to improve their aggregation efforts.

6.2 Filtering

Another technique employed is the filtering on the RIR minimum allocation sizes per address block allocated by the IANA to the RIRs.  For example, if an RIR's smallest allocation from a particular /8 block was a /21, the network operators would filter routing announcements received from external networks such that prefixes smaller than the /21 would be rejected.  One positive result is that operators announce larger prefixes (and even their aggregate blocks) to get around these filters.

Effects of general prefix filtering can be seen on the CIDR Report website [4], which has views of the full Internet Routing Table as seen from many different Autonomous Systems.

It's not clear how many network operators employ filtering based on RIR minimum allocation sizes, nor is it clear if such filtering is completely useful in achieving its intention of limiting routing table size.  Very clearly, if a network operator has received the minimum allocation from their RIR, their ability to traffic engineer for multihoming is somewhat restricted - they cannot subdivide their address block for traffic engineering purposes if their upstream provider filters on the RIR minimum allocation boundaries.

6.3 The "CIDR Police"

In the late 90s and early 00s, a small group of volunteers analysed the various routing table announcement reports, and gave their time freely to work with ISPs who were announcing more prefixes than they apparently needed to [8].  They would look for ISPs announcing contiguous /24 prefixes, and suggest that merging these into a single larger announcement would be beneficial to the Internet Routing Table.  This met with varying levels of success, ranging from cooperation and appreciation to hostility and even abuse from the network operators concerned.

Around the time of the Internet "bust" in 2001, the volunteers behind the "CIDR Police" effort moved on to other priorities facing them.  While recent years have seen some discussion about restarting the "CIDR Police" effort, nothing has yet materialised at the time of writing.

6.4 BGP Features

The Internet community (mainly the ISPs and the equipment vendors) have also worked to add features within BGP to assist with aggregation efforts. These are discussed in turn.

6.4.1 The NO_EXPORT BGP Community

The first aid for multihoming and prefix aggregation came in the form of the NO_EXPORT BGP Community, described as part of the BGP Community Attribute specification [9].  A prefix tagged with this community would not be advertised by one eBGP speaker to another.

The idea is that a service provider would leak sub-prefixes to their upstream or peer provider to aid with traffic engineering; but tag these sub-prefixes with the "no_export" community to indicate to their upstream that these sub-prefixes should not be announced to any other autonomous system.  Many providers use this community for traffic engineering purposes, but the usage is perhaps not as widespread as it could be.

6.4.2 The NOPEER BGP Community

The next aid to assist with the traffic engineering and aggregation quandary was the NOPEER BGP Community.  This was introduced relatively recently [10], but has had no support from the equipment vendors (no known implementations), and apparently little demand from any Internet Service Providers.

The idea here is that a service provider who wishes to deaggregate to support traffic engineering for multihoming would tag such "traffic engineering" sub-prefixes with the NOPEER community.  Upstream ISPs would then propagate or discard these prefixes depending on whether the eBGP relationship would be deemed as a peer or not.

Internet Service Providers generally have three types of relationships with other providers in the Internet: upstream, bi-lateral peer, or customer.  Support of the NOPEER community would be provided by the providers indicating in their router configurations whether the BGP peering was with an upstream, bi-lateral peer, or customer.  Upstream and customer BGP peerings would see the NOPEER tagged prefixes being propagated on the peering, whereas bi-lateral peerings would see the NOPEER tagged prefixes being discarded.  This allows the edge provider attempting to carry out traffic engineering do so all the way to the "Internet core", but not see the "Internet core" having to carry the sub-prefixes being required for this traffic engineering.

There are estimated to be around ten service providers at the core of the Internet who have a no-fee peering relationship with each other [11], and with the bulk of the Internet's ASNs appearing at the edge rather than the transit core, the impact of the edge providers using the NOPEER community with attendant support in the transit core could be quite significant on the size of the routing table as seen at the "Internet core".

6.4.3 The "AS_PATHLIMIT:" Attribute

The latest contribution to assist with traffic engineering needs for multihoming ISPs has been the proposal to introduce an AS_PATHLIMIT attribute [12].

The idea here is to restrict the propagation of a prefix to a particular AS radius, as determined by the value of the AS_PATHLIMIT attribute.  The attribute contains the maximum number of ASNs that can appear in the AS path (as well as the ASN which introduced the attribute).  Each AS would compare the value of the attribute with the number of ASNs in the AS_PATH. If the number of ASNs in the AS_PATH is greater than the value of the AS_PATHLIMIT, the prefix would not be processed internally in the network, or propagated to eBGP peers.  This would allow service providers to do localised traffic engineering with out other providers at more distant points in the Internet having to see those specific traffic engineering prefixes.

6.4.4 Provider-Specific Communities

Many transit providers permit their customers to use BGP communities to signify a degree of prefix propagation greater than NO_EXPORT, but less then permitting it into the global routing tables.  This often includes options such as "all regional peers", "all peers" (but not their transit providers), or in some cases even just specific peers with which the customer is multihomed.

Provider-specific communities are usually documented either on the provider's website, or sometimes as part of the Route Object within the Internet Routing Registry system.  The community values are not coordinated, although several ISPs do attempt to use similar values to achieve the same effect, following the spirit of RFC1998 [13] describing InternetMCI's community usage in the mid 90s.  Known examples of provider-specific communities are documented at [14].

Care needs to be taken to ensure that BGP policies on routers are carefully maintained, as route propagation needs to match the intent of the community.  Unintended leakage of routes can propagate into the global routing tables, negating the intent of this form of restricted propagation.

7. Recommendations

The latter part of this document describes the RIPE Routing Working Group recommendations for making routing announcements to the Internet.  It is hoped and expected that all network operators will follow these recommendations so that the growth of the Internet Routing Table is kept in check, and will only be as much as is absolutely essential.

7.1 Initial Allocations

When the network operator receives an IP address allocation from the RIR or an assignment from their upstream ISP, the expectation of the entire Internet community is that these IP addresses are combined into the largest feasible block and announced as such to the rest of the Internet.

For example, if a network operator receives a /21 from their RIR, they should configure BGP to announce only this /21 to neighbouring Autonomous Systems.

7.2 Subsequent Allocations

Whenever possible, the RIRs attempt to make allocations to their LIR members which are contiguous with previous allocations.  When the network operator receives a new allocation or assignment which is the same size as the original allocation and is contiguous with it, they should combine the two address block and announce them as an aggregate.

For example, suppose a network operator was originally allocated a /21 and now receives the neighbouring /21.  If the two /21s fall on the correct bit boundary, they can be combined into a /20.  They should then announce this /20 to their neighbouring ASNs, and remove the announcement of the original /21.

If the subsequent allocation is not contiguous, or is contiguous but falls foul of bit boundaries, or is of a different size to the previous allocation, then there is no aggregation which can be carried out and the network operator should announce the two address blocks separately.

7.3 Multihoming

If the network operator has a multihomed network, they will have a requirement to subdivide their address block (or blocks) to aid traffic engineering.  If the operator needs to do this, they must still announce their address block, as without this announcement they will get no backup should the alternative link or links fail.  The subdivision of this address block should be done prudently - tutorials have been presented at various network operations fora over the last few years explaining how this could be done, achieving maximum traffic engineering effect but with out harshly impacting the Internet Routing Table [15].

7.4 BGP Enhancements

The various BGP enhancements described in Section 6.4 should also be considered where appropriate, and where supported by the router vendors. Most of the ISPs outside the transit core will find a use for the NO_EXPORT and NOPEER BGP Communities, as well as the new "AS_PATHLIMIT BGP:" Attribute, allowing them to limit the number of traffic engineering related sub-prefixes being propagated across the Internet.

7.5 Proxy Aggregation

Proxy aggregation needs to be handled very carefully.  Aggregating announcements originated by other ASNs can lead to undesirable effects, especially with the traffic engineering desires of the other ASNs, and with "black-holing" their traffic in the event of link failure.  Proxy aggregation only makes sense when the network operator has ascertained that the aggregation will not impact the operations of the affected networks (for example, the affected network may be multihomed onto the same upstream provider only).

7.6 IP version 6

While these recommendations have focused entirely on the IPv4 Internet, they are equally applicable to the use of IPv6.  Participation in the IPv6 Internet is no different from participation in the IPv4 Internet, and the expectations on networks or Autonomous Systems are exactly the same in both cases.

8. Conclusion

Aggregation is a necessary activity for network operators participating in today's Internet.  What was taken for granted following the migration to the classless Internet in the early 90s no longer seems to be a standard activity for most network operators.  The result is rampant growth of the Internet Routing Table, causing issues which impact every participant in the Internet.

BGP analysis activities such as those at [16] show the potential savings on the size of the Internet Routing Table - and these savings are potentially significant, anything from 30% to 50% depending on the measurements made and the view of the Internet Routing Table being used.

9. Acknowledgments

Thanks to the LINX membership for the original idea (LINX's experiment with a Routing Aggregation Policy [17]) and to Mike Hughes for the initial text which formed the basis of this document.  Thanks to Leo Vegoda, Geoff Huston, Gaurab Raj Upadhaya and Duncan Rogerson for their helpful comments and suggestions.

Y. References

[1] The CIDR Report | Original Idea: Tony Bates | Maintained by: Geoff Huston

[2] RFC 1518 - An Architecture for IP Address Allocation with CIDR | Tony Li and Yakov Rekhter

[3] RFC 1519 - Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy | Vince Fuller, Tony Li, Jessica Yu and Kannan Varadhan

[4] Routing Table Status Report | Geoff Huston - APRICOT 2005/APNIC 19

[5] The Route Views Project | University of Oregon

[6] Routing Update | Geoff Huston - APRICOT 2006/APNIC 21

[7] Delayed Internet Routing Convergence | Craig Labovitz, Abha Ahuja, Abhijit Bose and Farnam Jihanian - Sigcomm 2000

[8] CIDR Police - Please Pull Over and Show Us Your BGP Announcements | Barry Greene and Hank Nussbacher - NANOG 27

[9] RFC 1997 - BGP Communities Attribute | Ravi Chandra and Paul Traina

[10] RFC 3765 - NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control | Geoff Huston

[11] AS Path Analysis | Vijay Kuhmar Adhikari, Gaurab Raj Upadhaya and Bill Woodcock - SANOG 8

[12] AS-PATHLIMIT Attribute | Joe Abley, Tony Li and Rex Fernando

[13] RFC1998 - An Application of the BGP Community Attribute in Multihome Routing | Enke Chen and Tony Bates

[14] BGP Community Guide

[15] BGP Multihoming Techniques | Philip Smith - NANOG 35

[16] Aggregation Potential

[17] The Routing Aggregation Policy - A Failed Social Experiment at the LINX | Nigel Titley - APNIC 21

Z. Authors

The authors can be contacted as follows:

Philip Smith | pfs@cisco.com
Rob Evans | rhe@nosc.ja.net
Mike Hughes | mike@linx.net

This document contains instructions for LIRs on how to complete the “IPv6 End User Site Assignment Request Form”

The instructions are based on the “IPv6 Address Allocation and Assignment Policy”

• General Information
• Required Information
• Overview of Organisation Template
• User Template
• IPv6 Assignment Usage Plan
• Insert Supplemental Comments
• End of Request

General Information

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

request-type: ipv6-enduser-assignment
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>.

Required Information

#[REQUIRED INFORMATION]#
%
% Do you and the End User accept the IPv6 Address 
% Allocation and Assignment Policy? (Yes/No)

confirmation: yes

% Why does the End User site need more than a /48?

reason: Ruria Inc. consists of four divisions, 
        which are technically independent, 
        and therefore require separate /48 assignments.

You and the End User must read the IPv6 Address Allocation and Assignment Policy. Enter ‘yes’ in the “confirmation:” field if you both agree to follow this policy.

In the “reason:” field, please explain why the End User needs a large IPv6 assignment.

Overview of Organisation Template

#[OVERVIEW OF ORGANISATION TEMPLATE]#
%
% Who will use the requested address space?

organisation-name:      Ruria Inc.
organisation-location:  Ruritania, NN
org-description:        Ruria Inc. is a well-known company in NN. 
                        Its main activities include digital imaging, music, travel agency  
                        and producing home appliances.
                        Ruria Inc. will make its network IPv6-enabled soon. 
website-if-available:   http://www.ruria.nn

% Will the whole organisation use this assignment? If 
% another part of the organisation will request separate 
% IPv6 address space, please inform us below. (Whole/Part)

for-whole-or-part-of-the-organisation: whole

Enter the legal name and primary location of the organisation that will use this IPv6 address space in the “organisation-name:” and “organisation-location:” fields.

In the “org-description:” field, write a short description of the organisation. Include information about its IPv6 services and customers.

If this End User has a website, enter the URL in the “website-if-available:” field.

Enter ‘part’ in the “for-whole-or-part-of-the-organisation:” field if the End User’s organisation will request separate IPv6 address space. Otherwise, enter ‘whole’.

User Template

#[USER TEMPLATE]#
%
% Who is the contact person for this organisation?

name:    Hannu Olofsson
phone:   +123 45 678910
fax-no:  +123 45 678911
email:   hannu@ruria.nn
nic-hdl: HOHO1-RIPE

Please use international dialling codes (for example, +31 for the Netherlands,) in the “phone:” and “fax-no:” fields.

Enter the contact person’s NIC handle, if they have one, in the “nic-hdl:” field.

IPv6 Assignment Usage Plan

#[IPv6 ASSIGNMENT USAGE PLAN]#
%
% When will the End User use this IPv6 assignment?
% 
%         Subnet       Within    Within    Within
%         size (/nn)  3 months   1 year    2 years     Purpose

subnet:    /48            x          -          -         Digital Imaging
subnet:    /48            -          x          -         Ruria Travel
subnet:    /48            -          x          -         Ruria Music
subnet:    /48            -          -          x         Home Applicances

% Which netname will you use for this assignment?

netname: RURIA

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 of 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 the End User 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.

The “netname:” should be a short, descriptive name for the network and should reflect the End User's organisation name.

Insert Supplemental Comments

#[INSERT SUPPLEMENTAL COMMENTS]#
%
% Please add more information if you think it will help us 
% understand this request.

Ruria Inc. is already installing equipment to run their network 
with dual-stack IPv4/IPv6.

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

End of Request

#[END of REQUEST]#

Best Regards,
Jan Janssen, Bluelight Admin

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

% IPv6 End User Site Assignment Request Form

% RIPE NCC members can use this form to request a large
% IPv6 Assignment for an End User. Please see ripe-374 for
% instructions on how to complete this form.

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

request-type: ipv6-enduser-assignment
form-version: 1.1
x-ncc-regid:

#[REQUIRED INFORMATION]#
%
% Do you and the End User accept the IPv6 Address
% Allocation and Assignment Policy? (Yes/No)

confirmation:

% Why does the End User site need more than a /48?

reason:

#[OVERVIEW OF ORGANISATION TEMPLATE]#
%
% Who will use the requested address space?

organisation-name:
organisation-location:
org-description:
website-if-available:

% Will the whole organisation use this assignment? If 
% another part of the organisation will request separate
% IPv6 address space, please inform us below. (Whole/Part)

for-whole-or-part-of-the-organisation:

#[USER TEMPLATE]#
%
% Who is the contact person for this organisation?

name:
phone:
fax-no:
e-mail:
nic-hdl:

#[IPv6 ASSIGNMENT USAGE PLAN]#
%
% When will the End User use this IPv6 assignment?
% 
%       Subnet       Within     Within   Within
%       size (/nn)   3 months   1 year   2 years   Purpose

subnet:
subnet:

% Which netname will you use for this assignment?

netname: 

#[INSERT SUPPLEMENTAL COMMENTS]#
%
% Please add more information if you think it will help us
% understand this request.

<add more information>

#[END of REQUEST]#

This document provides the management process for IPv6 global unicast address space whereby address allocations are made from a single global pool according to a "sparse allocation" algorithm. This allocation process will maximise aggregation of address space, ensuring that most ISPs retain a single prefix as they grow, and avoiding the address space fragmentation which results from the current IPv4 allocation technique. This document also describes the registration process and the administration of the IP6.ARPA domain.

Table of Contents

• 1.0 Overview
• 2.0 Common Address Pool
• 3.0 Sparse Allocation Algorithm
• 4.0 Allocation Request Process
• 5.0 Avoiding Fragmentation
• 6.0 CAP Contention
• 7.0 Review of Allocation Process
• 8.0 Common Registration Service
• 9.0 Reverse DNS (ip6.arpa) Requirements
• 10. IANA Considerations

• Author's Addresses

1.0 Overview

Under the current system of management of global IP address space, Regional Internet Registries (RIRs) are responsible for allocation of address space to organisations within their respective geographic regions.

RIRs receive address space periodically from IANA, and then manage that address space as a "pool" from which subsequent allocation are made to organisations within their regions. RIRs individually use various allocation techniques within their respective pools of address space (including sparse allocation techniques), in an attempt to ensure that subsequent allocations to ISPs are able to be aggregated.

Under this current system, aggregation of allocated address space is limited by several factors. These factors include the requirement for RIRs to utilise their existing pool of addresses to a level of 80% prior to requesting more address space from IANA, as well as the relatively small size of the address pools held by RIRs at any one time. Over a period of several years, a single large ISP may receive many discontiguous allocations from its RIR.

This document provides a management system for IPv6 which avoids these problems by delegating to the RIRs collectively a single large pool of IPv6 address space which will be managed under a new allocation system. Under this system, an RIR wishing to make an allocation will receive that allocation from the common pool, rather than from a regional pool already held by that RIR. Furthermore, the allocation it receives from that pool will be selected so as to maximise the room for future expansion of the allocation as a single aggregatable block.

2.0 Common Address Pool

For the purposes of this document, the source of address space described above is referred to as the Common Address Pool (or CAP). The CAP will be established by the IANA as a single allocation of address space for management by the RIRs under this proposed framework. See IANA considerations below.

Allocations from the CAP will be selected according to a Sparse Allocation (or "binary-chop") algorithm, designed to maximise aggregation of address blocks allocated. This algorithm is described in the next section.

The administration of the CAP will be conducted jointly by the RIRs, through a "registration service" which is described below. For the purposes of this document, the term CRS is used to refer to the Common (Address Pool) Registration Service.

3.0 Sparse Allocation Algorithm

An allocation of IPv6 address space is defined uniquely by a start address (expressed as an IPv6 address) and an address block prefix (expressed as the integer number of bits in the network mask, between 0 and 64). Examples are:

2000::/3
2001::/16
2002:200::/23
2002:298::/35

Under the sparse allocation system, the start addresses for successive allocations are generated according to a simple algorithm, as illustrated below.

For example, within a 6-bit address space, the first 16 start addresses would be as follows.

         Seq#   Address   Decimal
          1     000000     00
          2     100000     32
          3     010000     16
          4     110000     48
          5     001000     08
          6     101000     40
          7     011000     24
          8     111000     56
          9     000100     04
         10     100100     36
         11     010100     20
         12     110100     52
         13     001100     12
         14     101100     44
         15     011100     28
         16     111100     60

The following illustration shows this 6-bit address space (comprising 64 locations), and the location of the first 16 allocations to be made (according to their sequence number), according to the above list.

 
    |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
    1   |   |   |   |   |   |   |       |   |   |   |   |   |   |
        |   |   |       |   |   |   2   |   |   |       |   |   |
        |       |   3   |       |       |       |   4   |       |
            5               7               6               8
        9       13      11      15      10      14      12      16

The effect of the sparse allocation algorithm is to successively subdivide each remaining block of free address space into 2 equal parts, the first being left to accommodate growth of an existing allocation, and the second being made as a new allocation.

In the first instance (perhaps for the first 1000-2000 allocations, or as otherwise agreed), successive blocks can be selected according to a predefined list as described above. Subsequently however, it will be desirable to select blocks of free space for subdivision according to their size and the rate of growth demonstrated by the immediately preceding allocation. See "Avoiding Fragmentation" below.

4.0 Allocation Request Process

When a new address block is required by an RIR, a request will be sent to the CRS for a block of the required size. The CRS will apply the sparse allocation algorithm (as described above) to determine the start address of the next free block of address space which at of at least the size required by the RIR. This block will be registered by the CRS in an internal database, and then returned to the requesting RIR.

When a subsequent allocation is required by an RIR (that is, in order to expand an address block already allocated by that RIR), a request must be sent to the CRS for the expansion of an existing allocation to the required size. The CRS will then examine the current state of the Common Address Pool to ensure that the required additional space is available, and return a confirmation of the allocation (and updating internal records as above).

5.0 Avoiding Fragmentation

Under the sparse allocation system described here, the "distance" between neighbouring allocations is initially very large, so it is not expected that any fragmentation of address space will occur for some time.

However, depending on the rate of allocation, and the rate of growth of individual allocations, the avoidance of fragmentation will need to be addressed eventually. A technique is proposed here which avoids fragmentation of address blocks which exhibit rapid growth.

Before allocating a start address for any new allocation, the CAP should be examined to determine whether the immediately preceding allocation is likely to exhaust its available address space in the foreseeable future. If that preceding allocation has grown to occupy more than an agreed percentage of the address space potentially available to it, the selected start address should not be allocated.

In the case below, an existing allocation A has grown to occupy 25% of the space potentially available to it. In this case, the candidate address B would not be allocated, and another address would be selected instead.

       A----------- space available to A ---------->
    ---|xxxxxxxxxx-----------|---------------------|-------
                             ^
                             B-- new allocation --->

The question of which alternative address should be selected in this case could be addressed in a variety of ways, but these are not examined in this document.

6.0 CAP Contention

Since the CAP will be accessed by multiple RIRs, a mechanism will be required to manage possible contention by simultaneous requests. This mechanism is beyond the scope of this document.

It is also recognised that a central administrative agency, even a very lightweight one, may for various reasons be unavailable or unreachable for a period of time exceeding the required response time on allocation requests. For this reason it will be necessary for the CRS to make provisional allocations to RIRs of multiple address blocks, so that each RIR always has a "reserve" to be used in the exceptional case that the CRS is unavailable. To avoid duplicate allocations, this "reserve" for each RIR would be updated by the CRS with every allocation made to that RIR.

7.0 Review of Allocation Process

The initial set of allocations made under this policy should be limited, on the basis that allocation system is reviewed before the limit is reached, and adjusted in light of experience. Such a review would take place within the communities of the RIRs, through the regional Open Policy Meeting processes.

The initial set of allocations will have 2048 entries, with a review to be commenced immediately after the 1024th allocation is made from that set.

8.0 Common Registration Service

A registration service entity will be formed to act as the custodian for the global space. The operation of this entity will rotate amongst the RIRs and will be the Secretariat for the entity. Each RIR will operate a database server, the server that is located at the Secretariat will be the master, the servers at the other RIR locations will be mirrors of the master. This data base will NOT be a whois data base. It will contain only the information necessary to identify the RIR that made the allocation and the information necessary to generate the reverse delegation DNS zone file. All information required for the RIR to manage the address space and to provide whois information will be resident at the respective RIRs and subject to their specific processes and procedures. Allocations will be made from the master server by each RIR using AAA. The mirror data base servers at the other RIR locations server provide robustness to the system by being redundant to the master.

9.0 Reverse DNS (ip6.arpa) Requirements

Administration

The ip6.arpa domain and any third level domains will be administered by the registration service entity. Technical administration will be performed by the RIR that is the Secretariat. Each RIR will operate a DNS server, the server that is located at the Secretariat will be the silent master for these domains, the servers at the other RIR locations will be mirrors of the master. The zone files will be created from the master registration data base server that is located at the secretariat location. Each RIR will operate a suite of servers that will be the secondary servers for these domains. The SOA records for these domains will be transparent.

Delegation

All delegations will be made on a nibble boundary regardless of allocation boundary. Thus a /32 allocation could also have a corresponding delegation, whereas a /35 would have two (2) /36 delegations.

The initial delegation will consist of the two (2) /4 prefixes that comprise the unicast address space. Allocations made by the RIRs will be delegated from the appropriate /4 delegation and will be done on a nibble boundary as described above. As the number of delegations in the /4 domain grow, intermediary delegations can be made to move the flat space into a hierarchical tree.

10. IANA Considerations

This proposal is intended to provide a deterministic means of allocating address blocks. Once agreed by the relevant communities, this process can be carried out by any party.

As discussed above, the algorithm used to generate start addresses will be subject to revision in the light of experience, and both the algorithm itself and the broader allocation policy will be subject to regular review by the addressing community.

It is proposed that in order to maximise the benefits of the system, the entire FP001 be allocated by IANA to this system, for management by the RIRs.

Author's Addresses

Paul Wilson
APNIC
Level 1, 33 Park Road
Milton QLD
AUSTRALIA

Phone: +61 7 3367 0490
Email: pwilson@apnic.net

Raymond Plzak
ARIN
3635 Concorde Parkway, Suite 200
Chantilly, Virginia
United States

Phone: +1 703 227 9850
Email: Plzak@arin.net

Axel Pawlik
RIPE NCC
Singel 258
1016 AB Amsterdam
The Netherlands

Phone: +31 20 535 4444
Email: axel@ripe.net