____________________________________________________
IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
Document ID: ripe-196
Date Published: July 20, 1999
Scheduled revision: Formal revision of this document is
scheduled to be commenced by 1 October 1999.
ABSTRACT
This document describes the registry
system for distributing globally unique
unicast IPv6 address space. IPv6 address
space is distributed in a hierarchical
manner (as is IPv6 address space), managed
by the IANA and further delegated by the
Regional Internet Registries (Regional
IRs) as described in RFC 1881. In the case
of IPv6, the Regional IRs allocate Top-
Level Aggregation Identifiers (TLAs) to
organizations, which, as TLA Registries,
in turn allocate or assign address space
to other Internet Service Providers (ISPs)
and end users. ISPs then serve as Next
Level Aggregation (NLA) Registries for
their customers.
This document describes the responsibili-
ties, policies, and procedures associated
with IPv6 address space management, to be
followed by all organizations within the
allocation hierarchy. The intention of
this document is to provide a framework
for clear understanding and consistent
application of those responsibilities,
policies, and procedures throughout all
layers of the hierarchy.
1. Scope
This document first describes the global Internet
Registry system for the distribution of IPv6 address
space (as defined in RFC 2374) and the management of
that address space. It then describes the policies
and guidelines governing the distribution of IPv6
address space. The policies set forth in this
____________________________________________________
ripe-196.txt Page 1
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
document should be considered binding on all organi-
zations that receive allocations or assignments of
IPv6 address space either directly or indirectly
from a Regional IR.
This document describes the primary operational
policies and guidelines in use by all Regional IRs.
Regional IRs may implement supplementary policies
and guidelines to meet the specific needs of the
Internet communities within their regions.
These policies and guidelines are subject to change
based upon the development of operational experience
and technological innovations, which together emerge
as Internet best practice.
1.1. The structure of this document is as follows:
Section 2, "IPv6 Address Space and the Internet Reg-
istry System", describes the hierarchical structure
of responsible organizations within the Internet
Registry system and the explicit goals that deter-
mine the framework of policies for allocation and
assignment of IPv6 address space.
Section 3, "IPv6 Technical Framework", explains the
IPv6 addressing format and describes the differences
between TLA, NLA, and SLA blocks.
Section 4, "Addressing Policies", describes the
requirements for applying for a TLA allocation and
the policies that apply to such allocations. It dis-
cusses how TLA registries can allocate space to
other ISPs (NLA blocks) and assign address space to
end-users (SLAs).
Section 5, "Organizations Operating in More than One
Region", describes the requirements for organiza-
tions operating in more than one IR region request-
ing address space.
Section 6, "DNS and Reverse Address Mapping",
describes the role of the Regional IRs in providing
reverse delegation and explains how the Regional IRs
can manage subsidiary reverse delegation of allo-
cated/assigned address space.
Section 7, "Glossary", provides a listing of terms
used in this document along with their definitions.
Section 8, "List of References", provides a list of
documents referenced in this document.
____________________________________________________
ripe-196.txt Page 2
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
2. IPv6 Address Space and the Internet Registry System
IPv6 unicast addresses are aggregatable with con-
tiguous bit-wise masks used to define routable pre-
fixes, using a method similar to that used for IPv4
addresses under CIDR. With IPv6, scarcity of address
space is assumed to no longer exist for the end-
user. However, inefficient assignments of address
space and rapid expansion of routing tables remain
as serious potential impediments to the scalability
of the Internet. The Internet Registry system exists
to ensure that IPv6 address space is managed in a
globally consistent, fair, and responsible manner
that minimizes wastage, and maximizes aggregation
within the routing structure.
2.1. The Internet Registry System Hierarchy
The hierarchical Internet Registry system exists to
enable the goals described in this document to be
met. In the case of IPv6, this hierarchy consists of
the following levels, as seen from the top down:
IANA, Regional Internet Registries, TLA, NLA Reg-
istries, and end-sites.
2.1.1. IANA
The Internet Assigned Numbers Authority (IANA) has
authority over all IP number spaces used in the
Internet, including IPv6 address space. IANA allo-
cates parts of the IPv6 address space to Regional
Internet Registries (Regional IRs) according to
their established needs.
2.1.2. Regional Internet Registries
Regional IRs operate in large geographical regions
such as continents. Currently, three Regional IRs
exist: ARIN serving North and South America, the
Caribbean, and sub-Saharan Africa; RIPE NCC serving
Europe, the Middle East, and parts of Africa; and
APNIC serving the Asia Pacific region. These
Regional IRs also serve areas beyond their core ser-
vice areas to ensure that all parts of the globe are
covered. Additional Regional IRs may be established
in the future, although their number will remain
relatively low. Service areas will be of continental
dimensions.
____________________________________________________
ripe-196.txt Page 3
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
Regional IRs are established under the authority of
the IANA. This requires consensus within the Inter-
net community and among the ISPs of the respective
region.
2.1.3. TLA Registries
TLA Registries are established under the authority
of the appropriate Regional IR to enable "custodian-
ship" of a TLA or sub-TLA block of IPv6 addresses.
TLA Registries perform roles and bear responsibili-
ties which are analogous and consistent with those
of the Regional IR within their designated network
services and infrastructures.
2.2. Goals of the Internet Registry System
The goals described in this section have been formu-
lated by the Internet community with specific refer-
ence to IPv6 address space. They reflect the mutual
interest of all members of that community in ensur-
ing that the Internet is able to function and grow
to the maximum extent possible. It is the responsi-
bility of every IR to ensure that all assignments
and allocations of IPv6 address space are consistent
with these goals.
These goals will occasionally be in conflict with
the interests of individual ISPs or end-users.
Therefore, IRs evaluating requests for allocations
and assignments must carefully analyze all relevant
considerations and must seek to balance the needs of
individual applicants with the needs of the Internet
community as a whole. The policies and guidelines
described in this document are intended to help IRs
balance these needs in consistent and equitable
ways. Full documentation of, and transparency
within, the decision making process must also be
maintained in order to achieve this result.
2.2.1. Uniqueness
Each IPv6 unicast address must be globally unique.
This is an absolute requirement for guaranteeing
that every host on the Internet can be uniquely
identified.
____________________________________________________
ripe-196.txt Page 4
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
2.2.2. Aggregation
IPv6 addresses must be distributed in a hierarchical
manner, permitting the aggregation of routing infor-
mation and limiting the number of routing entries
advertised into the Internet. This is necessary to
ensure proper operation of Internet routing and to
maximize the routing system's ability to meet the
demands of both likely and unforeseeable future
increases in both size and topological complexity.
In IPv6, aggregation of external routes is the pri-
mary goal.
This goal is motivated by the problems which arose
in IPv4 network addressing. IPv4 address allocations
have not been sufficiently hierarchical to ensure
efficient routing across the Internet. Inefficient
use of classful allocations led to an excess of
routing entries appearing in the default-free rout-
ing table. Furthermore, increased complexity of net-
work topologies led to IPv4 prefixes being announced
many times via different routes.
Responsible policies and guidelines must limit the
number of top level prefixes that are announced on
the Internet so as to ensure that the problems of
IPv4 are not repeated in IPv6. Such policies and
guidelines will always reflect the constraints of
current router technology and will be subject to
reevaluation as that technology advances. Further-
more, such policies and guidelines will be reviewed
according to a model consistent with that provided
in RFC 2374 and RFC 2450. Under this model, a
threshold is set significantly below the number of
default-free routing table entries considered to be
currently supportable. If the number of entries
reaches that threshold, then allocation criteria are
to be reviewed (see section 4.4).
2.2.3. Efficient Address Usage
Although IPv6 address resources are abundant, the
global Internet community must be careful to avoid
repeating the problems that arose in relation to
IPv4 addresses. Specifically, even though "conserva-
tion" of IPv6 addresses is not a significant con-
cern, registries must implement policies and guide-
lines that prevent organizations from stockpiling
addresses. IPv6 addressing architecture allows con-
siderable flexibility for end-users; however, all
registries must avoid wasteful use of TLA and NLA
address space by ensuring that allocations and
____________________________________________________
ripe-196.txt Page 5
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
assignments are made efficiently and based on demon-
strated need.
2.2.4. Registration
Every assignment and allocation of IPv6 Internet
address space must be registered in a publicly
accessible database. This is necessary to ensure
uniqueness and to provide information for Internet
trouble shooting at all levels. It also reflects the
expectation of the Internet community that all cus-
todians of public resources, such as public address
space, should be identifiable. As is the case with
IPv4 addresses, each of the Regional IRs will main-
tain a public database where all IPv6 allocations
and assignments are entered.
3. IPv6 Technical Framework
3.1. IPv6 Addressing Hierarchy
RFC 2374 specifies that aggregatable addresses are
organized into a topological hierarchy, consisting
of a public topology, a site topology, and interface
identifiers. These in turn map to the following:
|-3|--13|-8-|---24---|---16---|----64 bits---------|
+--+----+---+--------+--------+--------------------+
|FP|-TLA|RES|---NLA--|--SLA---|---Interface ID-----|
|--|-ID-|---|---ID---|--ID----|--------------------|
+--+----+---+--------+--------+--------------------+
|--public topology---|--site--|-----Interface------|
|--------------------|topology|--------------------|
+--------------------+--------+--------------------+
|------- network portion----->+<-----host portion--|
|----------------------------/64-------------------|
|--------------------------------------------------|
The public routing topology is represented by a /48,
giving each site 16 bits to create their local
topology. The host portion is represented by the
last 64 bits of the address.
Because all interface IDs are required to be in the
EUI-64 format (as specified in RFC 2373 and RFC
2374) the boundary between the network and host por-
tions is "hard" and ID address space cannot be fur-
ther sub-divided.
____________________________________________________
ripe-196.txt Page 6
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
Also, in order to facilitate multihoming and renum-
bering, the boundary between the public topology and
the site topology division at the /48 is also hard.
(RFC 2374 explains this more completely.)
3.2. Initial IPv6 Addressing Hierarchy
A modified version of the addressing hierarchy
described in section 3.1 will be used for the ini-
tial IPv6 allocations. The first TLA prefix (TLA
0x0001) has been divided into further blocks, called
"sub-TLAs", with a 13-bit sub-TLA identifier. Part
of the reserved space and the NLA space have been
used for this purpose.
This modified addressing hierarchy has the following
format and prefix boundaries:
Format boundaries
|-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----|
+--+-----+-----+---+-----+------+------------------+
|FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---|
|--|-ID--|-TLA-|---|--ID-|--ID--|------------------|
+--+-----+-----+---+-----+------+------------------+
Prefix boundaries (starting at bit 0)
number of number of
the left- the right- longest length
ID most bit most bit prefix (in bits)
******* *********** ********** ******* ********
TLA 3 15 /16 13
sub-TLA 16 28 /29 13
Reserved 29 34
NLA 35 47 /48 13
SLA 48 63 /64 16
For purposes of a "slow start" of a sub-TLA, the
first allocation to a TLA Registry will be a /35
block (representing 13 bits of NLA space). The
Regional IR making the allocation will reserve an
additional six bits for the allocated sub-TLA. When
the TLA Registry has fully used the first /35 block,
the Regional IR will use the reserved space to make
subsequent allocations (see section 4.2.5).
All router interfaces are required to have at least
one link-local unicast address or site-local
address. It is recommended that site-local addresses
____________________________________________________
ripe-196.txt Page 7
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
be used for all point-to-point links, loopback
addresses, and so forth. As these are not required
to be visible outside the site's network, they do
not require public address space. Any global unicast
address space assigned must not be used for link-
local or site-local purposes as there is address
space reserved for these purposes. (Note that "all
1s" and "all 0s" are valid unless specifically
excluded through reservation. See list of reserved
addresses in RFC 2373.)
4. Addressing Policies
As described above, Regional IRs make IPv6 alloca-
tions to requesting organizations that qualify for a
sub-TLA (TLA Registries). TLA Registries then allo-
cate NLA space to ISPs that are their customers (NLA
Registries). NLA Registries in turn assign SLA space
to end-users. TLA Registries may also assign SLA
space directly to end-users. TLA Registries and NLA
Registries also use SLA space to address their own
networks. This hierarchical structure of allocations
and assignments is designed to maximize the aggrega-
tion of routing information.
4.1. IPv6 Addresses not to be considered property
All allocations and assignments of IPv6 address
space are made on the basis that the holder of the
address space is not to be considered the "owner" of
the address space, and that all such allocations and
assignments always remain subject to the current
policies and guidelines described in this document.
Holders of address space may potentially be
required, at some time in the future, to return
their address space and renumber their networks in
accordance with the consensus of the Internet commu-
nity in ensuring that the goals of aggregation and
efficiency continue to be met.
4.1.1. Terms of allocations and assignments to be specified
At the time of making any allocation or assignment
of IPv6 address space, Registries should specify the
terms upon which the address space is to be held and
the procedures for reviewing those terms in the
future. Such terms and procedures should be consis-
tent with the policies and guidelines described in
this document.
____________________________________________________
ripe-196.txt Page 8
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
4.2. Allocations
In order to meet the goal of aggregation (section
2.2.2) Regional IRs will only allocate sub-TLA
address space to organizations that meet the crite-
ria specified in one or more of the following sec-
tions: 4.2.1 "General Criteria for Initial Sub-TLA
Allocation" and 4.2.2 "Criteria for sub-TLA Alloca-
tions in Transitional 'Bootstrap' Phase".
The criteria for an initial allocation to an organi-
zation are different from the criteria that apply
for subsequent allocations. Whereas the requirements
for an initial allocation are based on technical
considerations, requests for additional address
space are evaluated solely on the basis of the usage
rate of the initial allocation.
The following criteria for sub-TLA allocations
reflect the intentions of the authors of the IPv6
addressing architecture (see RFC 2374, RFC 2373, and
RFC 2450), namely that addressing policies must pro-
mote the goal of aggregation. The basis of these
criteria is that it is primarily the organizations
acting as transit providers or exchange points that
will be involved in the top-level routing hierarchy
and that other Service Providers should receive NLA
address space from these organizations.
4.2.1. General Criteria for Initial Sub-TLA Allocation
Subject to sections 4.2.2, and 4.2.3, Regional IRs
will only make an initial allocation of sub-TLA
address space to organizations that meet criterion
(a) AND at least one part of criterion (b), as fol-
lows:
a. The requesting organization's IPv6 network must
have exterior routing protocol peering relationships
with the IPv6 networks of at least three other orga-
nizations that have a sub-TLA allocated to them.
AND either
b(i). The requesting organization must have reas-
signed IPv6 addresses received from its upstream
provider or providers to 40 SLA customer sites with
routed networks connected by permanent or semi-per-
manent links.
OR
____________________________________________________
ripe-196.txt Page 9
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
b(ii). The requesting organization must demonstrate
a clear intent to provide IPv6 service within 12
months after receiving allocated address space. This
must be substantiated by such documents as an engi-
neering plan or deployment plan.
4.2.2. Criteria for sub-TLA Allocations in Transitional "Boot-
strap" Phase
By requiring exterior routing protocol peering rela-
tionships with at least three other IPv6 networks,
section 4.2.1 creates a problem during the initial
period of transition to IPv6 network addressing,
namely that too few organizations will meet the gen-
eral criteria during this phase (referred to as the
"bootstrap phase"). The criteria in this section
provide an interim mechanism for eligibility that
will only apply during the bootstrap phase, that is
until the number of organizations operating IPv6
networks is considered sufficient for the general
criteria to operate. (See section 4.2.2.1 "Duration
of Bootstrap Phase".)
Notwithstanding section 4.2.1, during the bootstrap
phase, Regional IRs will make an initial allocation
of sub-TLA address space to organizations that meet
criterion (a) AND criterion (b) AND either criterion
(c) OR criterion (d).
a. The requesting organization's network must have
exterior routing protocol peering relationships with
at least three other public Autonomous Systems in
the default-free zone.
AND
b. The requesting organization must show that it
plans to provide production IPv6 service within 12
months after receiving allocated address space. This
must be substantiated by such documents as an engi-
neering plan or a deployment plan.
AND either
c. The requesting organization must be an IPv4 tran-
sit provider and must show that it already has
issued IPv4 address space to 40 customer sites that
can meet the criteria for a /48 IPv6 assignment. In
this case, the organization must have an up-to-date
routing policy registered in one of the databases of
the Internet Routing Registry, which the Regional IR
____________________________________________________
ripe-196.txt Page 10
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
may verify by checking the routing table information
on one of the public looking glass sites).
OR d. The requesting organization must demonstrate
that it has experience with IPv6 through active par-
ticipation in the 6bone project for at least six
months, during which time it operated a pseudo-TLA
(pTLA) for at least three months. The Regional IRs
may require documentation of acceptable 6Bone rout-
ing policies and practice from the requesting orga-
nization.
4.2.2.1. Duration of Bootstrap Phase
The eligibility criteria in this section will only
apply until 100 requesting organizations have
received allocations of sub-TLA address space, pro-
vided that no more than 60 of these organizations
are located in one Regional IR's region. After this
threshold has been reached, the bootstrap phase will
be considered to be over and Regional IRs will only
make allocations to organizations that meet the gen-
eral criteria in section 4.2.1.
If 60 organizations have been allocated sub-TLAs
within one region (but less than 100 have been allo-
cated worldwide) then the bootstrap phase within
that region will be considered to be over. Addi-
tional applications from that region must satisfy
the general criteria in section 4.2.1, while appli-
cations from other regions need only satisfy the
bootstrap criteria.
When 100 sub-TLA registries are formed worldwide,
there will be enough choices for new prospective
sub-TLAs to find others to connect to and the boot-
strap phase can end. The regional limitation on
bootstrapping is intended to prevent one region con-
suming all available bootstrap opportunities before
IPv6 deployment has started in other regions.
4.2.3. Special considerations
4.2.3.1. Exchange Points
It is expected that some exchange points will play a
new role in IPv6, by acting as a sub-TLA registry
for ISPs that connect to the exchange point. Because
there is little information available about such
exchange points and how they will operate, they have
____________________________________________________
ripe-196.txt Page 11
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
not been considered during development of sub-TLA
eligibility criteria. As these exchange points are
established, the Regional IRs will evaluate whether
special criteria are required. It is expected that
the Regional IRs will request from the exchange
point information about the nature of the contracts
they enter with the ISPs seeking IPv6 service.
4.2.3.2. Multihomed Sites
At the moment the issue of multihomed sites is still
not resolved in the relevant working groups at the
IETF and the Regional Registries will wait until
this has been discussed further.
4.2.4. Size for Initial Allocation: "Slow-Start" Mechanism
Regional IRs will adopt a "slow start" mechanism
when making initial allocations of sub-TLA space to
eligible organizations. By this mechanism, the ini-
tial allocation will allow 13 bits worth of NLA IDs
to be used by the organization unless the requesting
organization submits documentation to the Regional
IR to justify an exception based on topological
grounds. This initial allocation allows the organi-
zation to create a hierarchy within the allocation
depending on their customer type (ISP or end-site)
and the topology of their own network. For example,
an organization may receive 8,192 SLAs (a /48 each).
(See section 4.3 for policies relating to assign-
ments.)
The slow-start mechanism for sub-TLA allocations is
important to the development of IPv6 addressing
hierarchies for several reasons. One significant
reason is that it allows the Regional IRs to set
relatively low entrance criteria for organizations
seeking a sub-TLA allocation. This makes the process
fair to all organizations requesting sub-TLA space
by giving everybody the same (relatively small)
amount and basing future allocations on track
record. Furthermore, the effect of this process will
be to create a range of different prefix lengths
which, in the event that routing table growth
requires it, will allow the ISP industry to make
rational decisions about which routes to filter.
Another important reason for adopting the slow-start
mechanism is to allow Regional IRs to maintain con-
tact with TLA Registries as they develop, thereby
providing a level of support and training that will
____________________________________________________
ripe-196.txt Page 12
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
help ensure that policies and practices are imple-
mented consistently. Without a slow start mechanism,
TLA Registries receiving large initial allocations
may not have formal contact with the Regional IR for
several years. The slow-start mechanism helps
Regional IRs to meet the goals of registration and
efficiency, by providing a process that enables them
to monitor whether the TLA Registries are properly
registering assignments in the database and cor-
rectly applying the policies for NLA and SLA assign-
ments contained in this document.
4.2.5. Criteria for Subsequent Sub-TLA Allocations
Regional IRs will not make subsequent allocations of
sub-TLA address space to a TLA Registry unless the
TLA Registry has used at least 80 percent of its
previously allocated address space. In this context,
address space is considered to be "used" if the TLA
Registry has made all of its allocations and assign-
ments of that address space to its own infrastruc-
ture or customer needs in accordance with the poli-
cies and guidelines specified in this document.
The size of subsequent allocations depend on the
demonstrated usage rate of the previous allocations.
4.2.5.1. Contiguous allocations
The subsequent allocation will be contiguous with
the previously allocated range to allow for aggrega-
tion of routing information. When a Regional IR
makes an initial allocation to TLA Registry, it will
reserve the full sub-TLA from which this allocation
was made. Subsequent allocations to that TLA Reg-
istry will be made from the reserved sub-TLA. If no
further growth is possible within that sub-TLA
range, the Regional IR may allocate a full TLA.
(Note, this practice may eventually lead to a situa-
tion in which no empty sub-TLAs are available, but
the existing sub-TLAs are not fully utilised. If
this occurs, then the provisions of section 4.4 will
apply.)
4.2.6. Registering and Verifying Usage
Each TLA Registry is responsible for the usage of
the sub-TLA address space it receives and must reg-
ister all end-site assignments and ISP allocations
in the database of the Regional IR in its region.
____________________________________________________
ripe-196.txt Page 13
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
The Regional IR may verify whether all assignments
are registered in the database. In addition to the
database entries, the Regional IR may ask for peri-
odic reports specifying how the addresses are being
used.
Registered end-sites must be connected and reach-
able. To verify this, the relevant Regional IR is
entitled to ping /48s within end-sites. Filtering
holes should be negotiated by the Regional IR and
the organization holding the addresses in question.
Therefore, it is suggested that end-sites use any-
cast cluster addresses on their border routers to
enable this. It is expected that one /48 SLA block
is enough address space per end-site. If an end-site
requests an additional SLA, the TLA Registry must
send the request to the Regional IR for a second
opinion.
4.2.7. Renumbering
It is possible that circumstances could arise
whereby sub-TLA address space becomes scarce. This
could occur, for example, due to inefficient use of
assigned address space, or to an increase in the
number of organizations holding both TLA and sub-TLA
space.
If such circumstances arise, it may be necessary for
Regional IRs to require that previously allocated
address space be renumbered into different ranges.
If a Regional IR requires a TLA Registry to renumber
its own network, this will also have an impact on
all of its customers' networks. Therefore, it is
recommended that TLA Registries and NLA Registries
enter contractual arrangements with their customers
at the time of the first allocation or assignment.
Such arrangements should clarify that the address
space might have to be returned, requiring all end-
sites to be renumbered. If renumbering is required,
then TLA Registries should inform their customers as
soon as possible.
Regional IRs requiring a TLA Registry to renumber
will allow that Registry at least 12 months to
return the sub-TLA space. [Note that the granted
renumbering time may depend on the prefix length
returned. The draft document
<http://search.ietf.org/internet-drafts/draft-ietf-
ipngwg-router-renum-09.txt> describes the issues
involved in and methods used for renumbering IPv6
____________________________________________________
ripe-196.txt Page 14
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
networks.]
[Note that site-local addresses are not affected by
renumbering the global unicast IPv6 addresses.]
4.2.8. Allocations to NLA Registries
TLA Registries with ISP customers may use their 13
bits of NLA address space to create an addressing
hierarchy for those ISPs. Each of the TLA Registry's
own end-user organizations would receive a /48 (see
section 4.3); however, the ISP customers (NLA Reg-
istries) could be "allocated" additional bits in
order to aggregate the ISP's customers internally. A
slow-start mechanism will be used for these NLA
allocations.
The NLA block is an allocation to the NLA Registry
and not an assignment. If the NLA Registry does not
sufficiently use it within a reasonable time, the
TLA Registry may require it to be returned. Defini-
tions of 'sufficient use' and 'reasonable time' will
be provided in a future version of this policy docu-
ment. These definitions will be influenced by IPv6
operational experience and determined by the
Regional IR's with the consensus of the Internet
registry and engineering communities.
Once an NLA Registry has assigned at least 80 per-
cent of its allocation, it may request an additional
block from the TLA Registry. This block can be any
size, depending on the NLA Registry's usage rate for
its first block. A TLA Registry receiving a request
for subsequent NLA allocations must submit the
request to the relevant Regional IR for a second
opinion.
Each NLA allocation must be registered in the
Regional IR's database. All end-user assignments
must also be registered in the Regional IR's
database. The same procedures for these end-user
assignments apply for the end-user assignments made
by the TLA Registry to their customers directly.
Ultimately, the TLA Registry is responsible for man-
agement of all address space it allocates and
should, therefore, appropriately monitor all assign-
ments made by the NLA Registries to which it allo-
cates. The Regional IR can at any time ask for addi-
tional information about the allocations and assign-
ments being made.
____________________________________________________
ripe-196.txt Page 15
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
4.3. Assignments
4.3.1. Assignments to End-users
The minimum assignment to end-user organizations
that have a need to create subnets in their network
is a /48 (80 bits of address space). Within this
/48, 16 bits are an SLA block used for subnetting
and further 64 bits are used per interface.
TLA Registries must submit all requests they receive
for additional assignments to the relevant Regional
IR for evaluation (a "second opinion"). All such
requests must document the full use of the initial
SLA and must be accompanied by an engineering plan
justifying the need for additional address space.
Dial-up lines are considered part of an ISP's
infrastructure and, therefore, addresses for such
purposes should be assigned from the SLA block of
that ISP. It is expected that longer prefixes be
used for non-permanent, single-user connections.
4.4. Reclamation Methods/Conditions
Allocations are valid only as long as the organiza-
tions holding the address space continue to meet the
criteria for allocations set out in sections 4.2.1,
4.2.2, and other criteria which may be specified
subject to the provisions of this section. Consis-
tent with the goal of aggregation described in sec-
tion 2.2.2, the criteria for allocations may be
reviewed with regard to current routing technology.
The current threshold point for reviewing the allo-
cation criteria is 4096 default-free entries in the
global routing table.
If this threshold is reached and current routing
technology then allows additional route entries, the
number of possible TLAs and sub-TLAs may be
increased accordingly.
However, if the limit is reached and routing tech-
nology at that time is not able to support addi-
tional routing entries, Regional IRs will review all
allocations made up to that point. In the course of
this review, the Regional IRs may seek consensus of
the Internet registry and engineering communities to
set minimum acceptable usage rates or new criteria
determining eligibility to hold sub-TLA space.
Dependent upon such a consensus, the Regional IRs
____________________________________________________
ripe-196.txt Page 16
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
may revoke the sub-TLA allocations of any Registry
not complying with those rates or criteria. Such
Registries will be required by the relevant Regional
IR to renumber their networks and return their pre-
vious allocation within a reasonable time.
During the period that routing technology is being
investigated, the Regional IRs will continue allo-
cating address space even if the number of "possi-
ble" routes are reached.
5. Organisations Operating in More than One Region
Organizations requesting sub-TLA space that operate
in more than one region, and that need separate sub-
TLA blocks for routing purposes, may request the
address space from more than one of the Regional
IRs, provided that the organization's networks meet
the criteria for allocation of sub-TLA address space
in each of the relevant regions.
6. DNS and Reverse Address Mapping
6.1 Allocation and Reverse Address Mapping
IANA will delegate to the Regional IRs responsibil-
ity for the management of the reverse address map-
ping of each of the address ranges allocated to
them.
For each IPv6 address block allocated by a Regional
IR to a member or customer, the Regional IR must set
up NS records in the appropriate sub-domain within
the "ip6.int" domain.
For example, where a /35 address block is allocated:
An allocation of "3FFE:2100:2000::0/35" would
require the following two zones to be delegated in
the "0.0.1.2.e.f.f.3.ip6.int" zone file:
$ORIGIN 0.0.1.2.e.f.f.3.ip6.int.
2 NS ns1.ispA.net.
NS ns2.ispA.net.
3 NS ns1.ispA.net.
NS ns2.ispA.net.
____________________________________________________
ripe-196.txt Page 17
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
Prior to allocating address space, the Regional IRs
will notify the recipient of the address range they
will receive. The recipient should configure reverse
DNS servers for that address range and then inform
the RIR of that configuration in order to complete
the allocation process.
Please see http://www.ripe.net/inaddr/ipv6.html for
more information.
6.1. Assignments and Reverse Address Mapping
All holders of a /35 allocation who make assignments
from that allocation are required to set up reverse
DNS for their customers.
7. Glossary
Allocation - The provision of IP address space to
ISPs that reassign their address space to customers.
Assignment - The provision of IP address space to
end-user organizations.
Default-free zone - The default-free zone is made up
of Internet routers which have explicit routing
information about the rest of the Internet and,
therefore, do not need to use a default route.
End-user - An organization receiving reassignments
of IPv6 addresses exclusively for use in operational
networks.
Exterior routing protocol peering relationships -
Routing relationships in which the organisations
receive the full Internet routing table separately
from neighbouring Autonomous Systems and are, there-
fore, able to use that routing table to make
informed decisions about where to send IP packets.
Interface Identifiers - A 64-bit IPv6 unicast
address identifier that identifies an interface on a
link.
NLA ID - Next-Level Aggregation Identifier.
NLA Registry - Internet Service Providers receiving
IPv6 address allocations from a TLA Registry.
Public Topology - The collection of providers and
exchanges who provide public Internet transit
____________________________________________________
ripe-196.txt Page 18
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
service.
Regional Internet Registries - Organizations operat-
ing in large geographical regions such as continents
which are responsible for fair distribution of glob-
ally unique Internet address space and for docume-
nting address space allocation and assignment.
Site - A location, physical or virtual, with a
network backbone connecting various network equipment
and systems together. There is no limit to the phys-
ical size or scope of a site.
Site Topology - A local, specific site or organi-
zation which does not provide public transit
service to nodes outside the site.
SLA ID - Site-Level Aggregation Identifier.
Slow Start - The efficient means by which
addresses are allocated to TLA Registries and to NLA
ISPs. This method involves issuing small address bl-
ocks until the provider can show an immediate requi-
rement for larger blocks.
TLA ID - Top-Level Aggregation Identifier.
TLA Registry - Organizations receiving TLA/sub-
TLA ID from Regional IRs to reassign to customers.
Unicast - An identifier for a single interface. A
packet sent to a unicast address is delivered to the
interface identified by that address. Note that the
definition of an IPv4 host is different from an IPv6
identifier. One physical host may have many interf-
aces, and therefore many IPv6 identifiers.
____________________________________________________
ripe-196.txt Page 19
Provisional IPv6 Assignment and Allocation Policy Document
APNIC, ARIN, RIPE NCC
____________________________________________________
8. 8. LIST OF REFERENCES
____________________________________________________
ripe-196.txt Page 19