1. Introduction
1.1. Overview
This document describes policies for the allocation and
assignment of globally unique Internet Protocol version 6
(IPv6) address space. It updates and obsoletes the existing
provisional IPv6 policies in effect since 1999 [RIRv6-Policies].
Policies described in this document are intended to be adopted
by each registry. However, adoption of this document does
not preclude local variations in each region or area.
[RFC 2373, RFC 2373bis] designate
2000::/3 to be global unicast address space that the Internet
Assigned Numbers Authority (IANA) may allocate to the RIRs.
In accordance with [RFC 2928, RFC 2373bis, IAB-Request], IANA
has allocated initial ranges of global unicast IPv6 address
space from the 2001::/16 address block to the existing RIRs.
This document concerns the initial and subsequent allocations
of the 2000::/3 unicast address space, for which RIRs formulate
allocation and assignment policies. Because End Sites will
generally be given /48 assignments [RFC 3177, RIRs- on-48s],
the particular emphasis of this document is on policies relating
the bits within 2000::/3 to the left of the /48 boundary.
However, since some End Sites will receive /64 and /128 assignments,
all bits to the left of /64 are in scope.
This policy is considered to be an interim policy. It will
be reviewed in the future, subject to greater 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
Unlike IPv4, IPv6 is generally assigned to End Sites in
fixed amounts (e.g. /48). The actual usage of addresses within
each assignment will be low when compared to IPv4 assignments.
In IPv6, "utilisation" is only measured in terms
of the bits to the left of the /48 boundary. In other words,
“utilisation” refers to the assignment of /48s
to End Sites and not the number of addresses assigned within
individual /48s at those End Sites.
Throughout this document, the term “utilisation”
refers to the allocation of /48s to End Sites and not the
number of addresses assigned within individual /48s 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 [RFC1715]
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 (/48s) 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 relationship 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
RIRs will apply a minimum size for IPv6 allocations to facilitate
prefix-based filtering.
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) not be an End Site;
c) plan to provide IPv6 connectivity to organisations to
which it will assign /48s by advertising that connectivity
through its single aggregated address allocation; and
d) have a plan for making at least 200 /48 assignments
to other organisations within two years.
5.1.2. Initial allocation size
Organisations that meet the initial allocation criteria
are eligible to receive a minimum allocation of /32.
Organisations may qualify for an initial allocation greater
than /32 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 /48 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.8 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
Assignments are to be made in accordance with the existing
guidelines
[RFC3177, RIRs-on-48], which are
summarized here as:
- /48 in the general case, except for very large subscribers
- /64 when it is known that one and only one subnet is needed
by design
- /128 when it is absolutely known that one and only one
device is connecting.
RIRs/NIRs are not concerned about which address size an LIR/ISP
actually assigns. Accordingly, RIRs/NIRs will not request
the detailed information on IPv6 user networks as they did
in IPv4, except for the cases described in Section
4.4 and for the purposes of measuring utilisation as defined
in this document.
5.4.2. Assignment of multiple
/48s to a single End Site
When a single End Site requires an additional /48 address
block, it must request the assignment with documentation or
materials that justify the request. Requests for multiple
or additional /48s 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 /48s 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 /48 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 assignment
information in a database, accessible by RIRs as appropriate.
(Information registered by an RIR/NIR may be replaced by a
distributed database for registering address management information
in future). Information is registered in units of assigned
/48 networks. When more than a /48 is assigned to an organisation,
the assigning organisation is responsible for ensuring that
the address space is registered in an RIR/NIR database.
RIR/NIRs will use registered data to calculate the HD-Ratio
at the time of application for subsequent allocation and to
check for changes in assignments over time.
IRs shall maintain systems and practices that protect the
security of personal and commercial information that is used
in request evaluation, but which is not required for public
registration.
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
Organisations that received /35 IPv6 allocations under the
previous IPv6 address policy [RIRv6-Policies] are immediately
entitled to have their allocation expanded to a /32 address
block without providing justification so long as they satisfy
the criteria in Section 5.1.1.
The /32 address block will contain the already allocated smaller
address block (one or multiple /35 address blocks in many
cases) that was already reserved by the RIR for a subsequent
allocation to the organisation. Requests for additional space
beyond the minimum /32 size will be evaluated as discussed
elsewhere in the document.
6.0 Assignments for
Internet Experiments
Organisations often require deployment tests for new Internet
services and technologies. These require numbering resources
for the duration of the test.
The policy goal of resource conservation is of reduced importance
when resources are issued on a temporary basis.
6.1
Defining the experiment
An organisation receiving numbering resources must document
the experiment. This may be in the form of a current IETF
Experimental RFC (http://www.ietf.org/rfc/rfc2026.txt
see Sec. 4.2.1) or an “experiment proposal”
detailing the resources required and the activities to be
carried out.
The assignment size will be equal to the existing minimum
allocation size on the date the request is received. Where
the experiment requires a variation to this rule it should
be noted in the resource request.
6.2 Publication
The experiment proposal must be made public (e.g. published
on web site), upon registration of the resources by the RIPE
NCC. Following the conclusion of the experiment the results
must be published free of charge and free from disclosure
constraints.
6.3 Non-commercial basis
Resources issued for an experiment must not be used for commercial
purposes.
6.4
Period of the Temporary Resource Registration
The resources will be issued on a temporary basis for a period
of one year. Renewal of the resource’s registration
is possible on receipt of a new request that details any continuation
of the experiment during the extended period.
The resources issued cannot be used for a commercial service
following the conclusion of the experiment.
6.5
Registration
The RIPE NCC will register the resources issued in the RIPE
Whois Database.
6.6 Making the request
The request must be made by a Local Internet Registry (LIR)
using the appropriate request form for the resource found
at:
http://www.ripe.net/ripe/docs/internet-registries.html#request
7. Assignments for Anycasting TLD Nameservers
If the name server set of a ccTLD or a gTLD without anycasting technology applied would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the TLD administrator may receive a single dedicated /48 network prefix for the sole purpose of anycasting name servers, as described in RFC 3258.
The prefix will be assigned by the RIPE NCC directly to the TLD, upon a request submitted via an existing LIR and will be registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for anycast DNS any longer.
|
you are here: RIPE -> RIPE Document Store
