All,
I have send this to this lists as the global-v6
lists does not seem to be working.
Regards,
Stuart
----- Original Message -----
Sent: Friday, January 11, 2002 7:32 PM
Subject: Re: [GLOBAL-V6] New draft available: IPv6 Address
Allocation and Assignment Global Policy
Dear all,
Please find enclosed comments
on new draft enclosed in text below.
I an unable to attend the RIPE
meeting next week in Amsterdam, but Paul Mylotte will comment on the comments
in this mail at the meeting.
Regards,
Stuart
IPv6 Address Allocation and Assignment Global Policy
Draft of December, 22 2001
Version 2001-12-22
APNIC
ARIN
RIPE - NCC
Status of this Memo
This document specifies "Internet
best current practices" for the
Internet community, and requests discussion and
suggestions for
improvements. Distribution of this document is unlimited as long
as
its contents remain
unchanged.
Comments on this document should be
sent to the global-v6 mailing
list:
To post:
global-v6@localhost.
To subscribe:
<http://www.apnic.net/net_comm/lists/>
Archives: <http://www.apnic.net/mailing-lists/global-v6>
Contents
Status of this
Memo.......................................... 1
1.
Introduction.............................................
2
1.1.
Overview............................................
2
1.2. Current
Status...................................... 3
2.
Definitions..............................................
4
2.1. Autonomous System
(AS).............................. 5
2.2. Internet
Registry (IR).............................. 5
2.3.
Internet Assigned Numbers Authority (IANA)..........
5
2.4. Regional Internet Registry
(RIR).................... 6
2.5. National Internet Registry
(NIR).................... 6
2.6. Local Internet Registry
(LIR)....................... 6
2.7.
Allocate............................................
6
2.8.
Assign..............................................
6
2.9.
Utilization.........................................
7
2.10.
Site...............................................
7
3. Goals of IPv6 address space
management................... 7
3.1.
Goals...............................................
7
3.2.
Uniqueness..........................................
8
3.3.
Registration........................................
8
3.4.
Aggregation.........................................
8
3.5. Conservation
(Stewardship).......................... 9
3.6.
Fairness............................................
9
3.7. Minimize
Overhead................................... 9
3.8.
Conflict of goals...................................
9
4. IPv6 Policy
Principles................................... 10
4.1.
Address space not to be considered property......... 10
4.2.
Routability not guaranteed.......................... 11
4.3.
Minimum Allocation.................................. 11
4.4.
Consideration of IPv4 Infrastructure................ 12
5. Policies for allocations
and assignments................. 12
5.1. Consistency of IR address
space management policies. 12
5.2. Initial
allocation.................................. 12
5.2.1. Initial allocation criteria....................
12
5.2.2. Initial
allocation size........................ 13
5.3. Subsequent
allocation............................... 13
5.3.1. Subsequent allocation criteria.................
13
5.3.2.
Utilization Metric............................. 13
5.3.3. Applied HD-Ratio...............................
14
5.3.4.
Subsequent Allocation Size..................... 14
5.4.
LIR-to-ISP allocation............................... 14
5.5.
Assignment.......................................... 15
5.5.1. Assignment address space size..................
15
5.5.2.
Assignment to a site........................... 15
5.5.3. Assignment of multiple /48s to a single site...
15
5.5.4.
Assignment to operator's infrastructure........ 15
5.6. DB
registration..................................... 16
5.7.
Reverse lookup...................................... 16
5.8.
Validity of allocations and assignments............. 16
5.9.
Existing IPv6 address space holders................. 17
6. Special
case............................................. 17
6.1. IX
(Internet Exchange).............................. 17
7.
Acknowledgment...........................................
17
8.
References...............................................
18
9. Appendix
A:.............................................. 19
1. Introduction
1.1. Overview
This document describes policies for
the allocation and assignment of
globally unique Internet Protocol Version 6 (IPv6)
address space. In
particular, [RFC2373, RFC2373bis] designates 2000::/3 to be global
unicast address space that IANA may
allocate. In accordance with
[RFC2928, RFC2373bis, IAB-Request], IANA has assigned
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
policies. Because end sites will
generally be given /48 allocations [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 allocations, all
bits to the left
of /64 are
in scope.
This document updates and replaces
all the guidelines and procedures
of the existing Provisional IPv6 Policies
[RIRv6-Policies] based on
over two years of experience with the 1999 policy. The
Provisional
IPv6 Policy
document will be obsoleted with the adoption of this
document.
Address policies should be globally
uniform and formulated in a
bottom-up manner through consensus processes at regional and global
levels. Address policies must be
determined with well-balanced
consideration given to not only technical constraints
and the
expectations of the
Internet community, but also to the operational
needs of ISPs and end users. Furthermore, the
policies should be
reviewed
whenever necessary in accordance with changes in the
external environment or operational
experience of the relevant
communities.
Policies described in this document
are global in nature and are
intended to be followed in each registry. However, adoption of
this
document does not
preclude local variations in each region or area.
This policy is also considered an
interim policy in the sense that
there is still little experience with allocating IPv6
addresses. As
experience from implementing the policy is gained, some aspects of
the policy will likely need review
and updating.
1.2. Current Status
The APNIC meeting held in Taiwan in
August 2001 discussed policies
relating to IPv6 address allocation and assignment and
reached a
certain
consensus. Afterward, similar suggestions were made at a
RIPE meeting held in October 2001
and an ARIN meeting held in the
same month. Various discussions were held at these
meetings, with
consensus
identified on a number of points. This document makes a
proposal based upon the results of
discussions at these meetings.
In all of these meetings, the
participants recognized an urgent need
for more detailed, complete policies in the Asia Pacific
Region
governing global IPv6
address space management. It was generally
recognized that discussion about policies for IPv6
allocation and
assignment
will not easily come to an end, but there is a consensus
that such discussion should be summed up
quickly to establish interim
policies. Accordingly, this document should be considered as a
time-
limited public
document that describes the most reasonable solution
available at present that has been obtained
through these
discussions. This document will therefore be duly updated as
the
Internet environment of
IPv6 progresses, and it is expected that
updates will occur relatively frequently in the coming
years.
This document does not provide
details of discussions concerning
individual policy issues, however the following sources
provide
background
information which may be of interest:
Meeting results: <http://www.apnic.net/meetings/12/results/>
<http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes.html>
<http://www.arin.net/minutes/ARIN_VIII/PPM.html>
Presentation Materials:
<http://www.apnic.net/meetings/12/docs/prop_new_ipv6_policy.ppt>
<http://www.apnic.net/meetings/12/docs/ipv6principles-dist.ppt>
<http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/>
<http://www.arin.net/minutes/ARIN_VIII/PPM.html>
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.
+--------+
| IANA |
+--------+
|
+-----------+-----------+
|
| |
+--------+ +--------+ +--------+
| RIR | | RIR |
| RIR | Regional Internet
+--------+ +--------+ +--------+ Registries
|
+-----------+--+--------+
|
| |
| +-----+
+-----+
| | NIR |
| NIR | National Internet
| +-----+
+-----+ Registries
|
| |
+--------+ +--------+ +--------+
|LIR/ISP | |LIR/ISP | |LIR/ISP | Local
Internet
+--------+ +--------+ +--------+
Registries
|
| |
+---------+
| |
|
|
| |
+-------+ +----+
+----+ +----+
|EU(ISP)| | EU | | EU
| | EU | End users
+-------+ +----+
+----+ +----+
2.1. Autonomous System (AS)
Autonomous Systems are the unit of
routing policy in the world of
exterior routing, and are specifically applicable to
protocols like
BGP
[RFC1771].
2.2. Internet Registry (IR)
An Internet Registry (IR) is an
organization 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.3. Internet Assigned Numbers Authority
(IANA)
The Internet Assigned Numbers
Authority (IANA) has responsibility for
management of the entire IP address space used on the
Internet.
Actual assignment
operations are performed by organizations under
IANA. Rather than allocating or assigning address
space to
operational
networks, the IANA delegates responsibility for large
blocks of address space to Regional Internet
Registries, for
management
at the regional level.
2.4. Regional Internet Registry
(RIR)
Regional Internet Registries (RIRs)
are established and authorized by
respective regional communities, and recognized 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. Currently, there are three RIRs: APNIC,
RIPE NCC, and ARIN.
Preparations are being made to establish LACNIC
and AfriNIC.
2.5. National Internet Registry
(NIR)
A National Internet Registry (NIR)
is an IR that primarily allocates
address space to its members, which are Local Internet
Registries
(LIRs). NIR
members are generally Internet Service Providers (ISPs)
organized at a national level. A NIR is
constituted from ISPs, but
the NIR itself does not function as an ISP. NIRs are expected
to
remain neutral to the
interests of ISPs of their constituency. NIRs
exist mostly in the Asia Pacific
Region.
2.6. Local Internet Registry (LIR)
A Local Internet Registry (LIR) 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.7. Allocate
To allocate means to distribute
address space to IRs for the purpose
of subsequent distribution by them.
2.8. Assign
To assign means to designate address
space that an IR distributes
part or all of to an end user for the purpose of actual deployment in
that end user's or ISP's own
network. Address space is also
designated as assigned if the IR uses it for the purpose
of
addressing their own
network. Assignments are made only for specific
purposes demonstrated by specific
organizations and are not be sub-
allocated or sub-assigned to other parties.
In this hierarchical structure, IANA
allocates address space to RIRs
for the purpose of redistribution. RIRs then
allocate address space
to
NIRs or LIRs in their respective regions (or in some cases to NIRs
which further allocate the space to
LIRs within their own countries).
Each NIR allocates address space to LIRs in its own
country. When an
RIR
or NIR allocates address space to an LIR, it also delegates to
the LIR the authority to assign
addresses to end users.
2.9. Utilization
Unlike IPv4, IPv6 generally assigns
a /48 to each end site. The
actual utilization of any particular /48, when compared to IPv4 ,
will be extremely low. In IPv6, the
"utlization" that is of interest
refers to the bits to the left of the /48.
Throughout this document, the term
utilization refers to the
allocation of /48s to end sites, and not the utilization of those
/48s within those end sites.
2.10. Site
A site is defined as an end user
(subscriber) who has a business
relationship with a provider that involves that provider
carrying its
traffic.
Every end user (subscriber) individually on a contract with
an ISP is considered an entity and is
eligible to receive a /48 IPv6
assignment, regardless of organization or geographical
location.
3. Goals of IPv6 address space
management
3.1. Goals
The goals of address space
management described here reflect the
mutual interest of all members of the Internet community
and ensure
that the Internet
is able to function and grow to the maximum extent
possible.
Address policies must be determined
with well-balanced consideration
given to not only technical constraints and the
expectations of the
Internet
community but also to the operational needs of ISPs and end
users.
These goals are essentially the same
as the goals in IPv4 policies
that have been formulated by the Internet
community. However,
attention must be paid to the fact that differences between IPv6 and
IPv4 change the relative priority
of elements that must be considered
to attain these goals.
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
Every assignment and allocation of
Internet address space must be
registered in a public registry database accessible to
all members of
the Internet
community.
Which database is this referring to
? Each RIR database?
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.
Are we talking /48s /64s and
/128s?
It also reflects the expectation of
the Internet community that all
users of public resources, such as address space, should
be able to
check the
conditions of the resources.
What does "conditions of the
resource" mean?
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
and limit the expansion of Internet routing
tables. With its vast
address space, IPv6 makes hierarchical distribution for aggregation
much easier than IPv4.
The IPv6 specification creates a
huge address space, and the number
of hosts under internal routing control of an individual
autonomous
system is
expected to increase dramatically compared with IPv4. For
example, cellular phones, various electric
appliances, and telemeter
sensors, are likely to become connected to the Internet in addition
to the conventional types of IPv4
hosts. Thus, hierarchical
distributions must be considered to limit the expansion of routing
tables regarding not only external
routing information advertised in
the Internet default-free zone but also internal routing
information
within an
autonomous system. Because internal aggregation is
important, policies should be sensitive to
supporting better internal
aggregation (e.g, through assignment of bigger blocks).
3.5. Conservation (Stewardship)
Maintaining unnecessary allocations
and assignments or stockpiling
address space with no aggregation merit should be
avoided as a matter
of
course. Also, efforts must be made for the efficiency of
address
use as much as
possible within the bounds of other constraints.
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. Minimize Overhead
It is desirable to minimize the
overhead associated with obtaining
additional address space as a site grows. 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, etc.
This para talks about trying to
minimize overhead as a site grows, but if a site is allocated a /48 and needs
an additional /48 for expansion then according to 5.5.3
The LIR whose customers
needs an additional /48 request needs to be reviewed at the RIR/NIR
level. Is this really minimizing overhead!!
Maybe this section needs more text
and a reference to 5.5.3?
3.8. Conflict of goals
The goals of conservation,
aggregation and minimization of
administrative overhead often conflict with each
other. In IPv6
address
management, the six goals described above are given different
priorities from the implicit
priorities of IPv4 address management.
IPv6 address management should give
higher priority to aggregation
and lower priority to address conservation, when
compared with
current IPv4
management practices. This does not mean that wasteful
address usage should be tolerated
because vast address space is
available. Instead, emphasis is placed on the need
for policies that
place
aggregation in higher priority so that the number of external
and internal routes will be
practically limited in the large address
space to ensure stable Internet operations for a long
time to come.
Emphasis on
aggregation sometimes leads to somewhat lower priority on
address conservation because these two goals
tend to conflict with
each
other.
It should be noted that an exclusive
choice between aggregation and
conservation will not be made on the basis of the
policies or
judgment of any
registry practices in accordance with these policies.
Both aggregation and conservation
should be taken into consideration
in the right balance. In IPv6, the right balance is
generally "more
aggregation,
less conservation".
The balance between aggregation and
conservation will be reviewed
over time according to various factors, such as
operational
experience and
address consumption.
Some or all of the goals described
here may occasionally be in
conflict with the interests of individual IRs or end users.
Therefore, all IRs evaluating requests for
allocations and
assignments
must make judgment, seeking to balance the needs of the
applicant with the needs of the Internet
community as a whole.
The policies 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.
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 global IPv6 policies in this
document are based upon the
understanding that address space is lease-licensed for use rather
than owned. All Internet Registries
are expected to manage address
space operations correctly in accordance with this
principle.
According to this policy, IP
addresses will be allocated on a lease-
license basis, with such lease-licenses to be of
specific limited
duration of
normally one year. Conditions of a lease-license have
specific conditions applied at the start or
renewal of the lease.
Lease-licenses will typically be
renewed automatically at the end of
their duration when the following two conditions are
met:
a) The original
basis of the allocation remains valid.
b) Registration requirements relating to that
allocation have been
fulfilled at the time of
renewal
However, when a lease-license is
renewed, the new lease-license will
be evaluated under and governed by the applicable
resource allocation
and
renewal policies in place at the time of renewal.
It is not clear what "resource
allocation and renewal policies" are exactly. There is no definition of
them in this document.
Sounds like we are moving towards
the way the DNS system works with the renewal of Domain Names.
Changes to the conditions of current
lease-licences shall be subject
to a definite period of notice, except in exceptional
circumstances
recognized by
a consensus of the Internet community.
As address space is not owned, and
consistent with the desire to
avoid excessive fragmentation of address space, it may
become
necessary in extreme
circumstances to renumber assignments. Such
renumbering will only be undertaken after extensive
consultation with
the
Internet community.
4.2. Routability not guaranteed
Because IPv6 is fundamentally based
upon aggregatable addresses, its
circumstance differs from IPv4, which contains a number
of non-
provider-based
assignments for historical reasons. Nonetheless,
registries are not responsible for
routability, which is affected by
the technical implementation by LIRs/ISPs. RIRs must
take steps,
however, to
ensure that allocations they make will not result in
excessively fragmented address space, as that
may lead to loss of
routability.
4.3. Minimum Allocation
As under current IPv4 management
policies, it is proposed that IPv6
policies establish a "minimum allocation" of address
space, which
serves to limit
the distribution by Internet Registries of portable
address prefixes.
Generally speaking, making minimum
allocation size too small leads to
address fragmentation, and making the size too large
lowers the
efficiency of
address use. Discussion about the appropriate size of
allocation needs to be continued in the
future. The interim policies
adopt the following concept:
First, a minimum address space (/32)
will be provided by default by
RIR/NIR to LIRs. However, many large providers
will quickly deplete
a /32
space and need to use more address space within a short time.
For this reason, providers
requiring space larger than a /32 may
request more address space, but must provide
justification for such a
request.
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 as a reason for requesting more
space in justifying IPv6 address space
requests. This is based upon
the implicit assumption that service providers having a
large number
of IPv4
customers are likely to have many customers in IPv6 as well.
This assumption should be evaluated
and reviewed on the next occasion
of revising the policies.
5. Policies for allocations and
assignments
5.1. Consistency of IR address space
management policies
All Internet Registries shall adopt
policies that are consistent with
the policies formulated by the Internet community and
described in
this
document.
5.2. Initial allocation
5.2.1. Initial allocation criteria
A requesting organization can
receive an initial allocation by
demonstrating that it has an immediate (i.e., within
next three
months)
requirement for at least a /36 prefix. That is, immediately
after the allocation, the
organization will have 776 or more sites in
need of address assignments. 776 is the number of
/48 address blocks
that can
be assigned out of a /36 address block to achieve an HD-
Ratio of 0.8. The HD-Ratio is an
address allocation utilization
metric proposed in RFC 3194 as an adaptation of the
H-Ratio
originally defined
in [RFC1715]. (See also Section 5.3.3.)
This para now mention 3 months, but
this is too short a time to connect 776 customer sites. It is not obvious
what the new time frame should be, but it should be longer than 3
months.
[Note: discussion is needed as to
whether justification for need of a
/36 is reasonable initial starting point, or whether the
criteria of
an immediate
need to address 776 sites is too high. Note also, that
once a request for an initial allocation has
been granted, the
minimum
allocation (i.e., /32) is provided, even though the requestor
has not justified a need for such a
large amount of space.]
5.2.2. Initial allocation size
A requesting organization satisfying
the initial allocation criteria
can receive an initial allocation of the minimum /32
address block.
Any
organization requesting a larger address block may receive the
necessary size of allocation by
submitting documentation that
reasonably justifies the necessity. For instance,
a provider or an
enterprise
currently providing IPv4 address services may apply for
and receive an initial allocation of the size
reasonably judged
necessary
to provide all the existing users with IPv6 services. In
this case, the necessary size will be judged
on the basis of the
number
of existing users and infrastructure.
Shouldn't this be that the IPv4
provider should be allocated an initial allocation for its IPv4 customers
PLUS the next 2 years growth, as in 5.3.4. Otherwise we will have the
scenario where an IP v4 provider switches to IPv6, and changes its customers
over to IPv6 and then has to go back to the RIR to request an additional
block for its new IPv6 customers. Suggest that the "2 year rule"
should be applied here also.
This can be represented by the
following expression:
S(0) =
shorter(/32, eval(required prefix size))
where (required prefix size) is the
prefix size of applicant
requesting allocation
5.3. Subsequent allocation
An organization (ISP/LIR) that has
already received an address block
from an RIR/NIR may receive a subsequent allocation in
accordance
with the
following policies.
5.3.1. Subsequent allocation
criteria
Subsequent allocation will be
provided when an organization (ISP/LIR)
satisfies the evaluation threshold of past address
utilization in
terms of the
number of sites in units of /48 assignments. The HD-
Ratio is used to assess the utilization of
the existing address block
as described below.
5.3.2. Utilization Metric
In general, HD-Ratio [RFC3194] is
expressed as follows:
Log (number of allocated objects)
HD = ------------------------------------------------
Log (maximum number of allocatable objects)
where the objects are IPv6 site addresses (/48s)
assigned from an
IPv6 prefix
of length P.
The utilization threshold T,
expressed as a number of individual /48
prefixes to be allocated from IPv6 prefix P, can be
calculated as:
((48-P)*HD)
T = 2
Thus, the
utilization threshold for an organization requesting
subsequent allocation of IPv6 address block
is specified as a
function
of the prefix size and target HD ratio. This utilization
refers to the allocation of /48s to end
sites, and not the
utilization of those /48s within those end sites. It is an address
allocation utilization ratio and
not an address assignment
utilization ratio.
5.3.3. Applied HD-Ratio
A desirable HD-Ratio for evaluation
is thought to lie between 0.80
and 0.85, with the actual value needing to be determined
as
experience is gathered
from implementation of this policy. An HD-
ratio of 0.8 is adopted for this interim policy. The
value may change
in response
to implementation experience.
5.3.4. Subsequent Allocation Size
The size of an "n"-th time
subsequent allocation S(n) is found as:
S(n) =
shorter(S(n-1)-1, eval(two_years_req))
where S(n-1)-1 represents one bit shorter prefix address
block size
of the previous
allocated address block size, and eval(two_years_req)
represents the evaluation of two-year demands
of the requesting
organization.
In other words, an organization
(ISP/LIR) satisfying the criteria can
receive at least one bit shorter prefix
automatically.
If an organization needs more
address space, it needs to demonstrate
its two-year demand to an RIR/NIR. Then, the RIR/NIR
evaluates it and
allocates
the address prefix enough to satisfy its two-year
requirements.
5.4. LIR-to-ISP allocation
There is no specific policy for an
organization (ISP/LIR) to allocate
address space to subordinate ISPs. Each LIR
organization may develop
its
own policy for subordinate ISPs to encourage optimum utilization
of the total address block
allocated to the LIR. However, the LIR is
required to keep track of all /48s assignments,
including assignments
made
by its subordinate ISPs to end users, and report the assignment
status to RIR/NIR so that the
HD-Ratio can be evaluated when a
subsequent allocation becomes necessary.
Here the text implies that the LIR
should keep track of all subordinate allocations, which means that if an LIR
allocates a block to a subordinate ISP then the LIR needs to keep track of
all the /48s that the subordinate ISP allocates to its own customers.
Then, when the LIR requests a larger allocation, that same LIR needs to
report these allocations to RIR/NIR so that the RIR/NIR can then calculate
the subsequent allocation. However, earlier in "3.3.
Registration" it says that "Every assignment and allocation of Internet
address space must be registered in a public registry database accessible to
all members of the Internet community"
It also talks about registration in
5.6 see below.
This
registration question needs clarifying - the document contradicts
itself.
Currently in IPv4, addresses are
registered in either a public database or in the LIR's own database, thus
allowing a mixture. Thus, if we need to keep our customer information
private, we can keep it "off" a public database, but if the customer does
want to be seen in the public database then we can enter it. Suggest
the same principle needs to be applied to IPv6.
5.5. Assignment
This section describes the
assignment policy.
5.5.1. Assignment address space size
Address space following the 64th bit
is the IETF boundary [RFC2460].
Address space following the 48th bit is a policy
boundary, with IETF
recommendations [RFC3177] and RIR agreement [RIRs-on-48] recommending
the assignment of:
- /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 user networks as they did in IPv4, except for
the cases described in Section 4.4.
and for the purposes of measuring
utilization as defined in this document.
5.5.2. Assignment to a site
5.5.3. Assignment of multiple /48s to a
single site
When a single site requires an
additional /48 address block, it can
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.
5.5.4. Assignment to operator's
infrastructure
An organization (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. On the other hand, a separate
assignment can be obtained
for the in-house operations of the operator.
5.6. DB registration
When an organization in reciept of
an IPv6 address allocation makes
IPv6 address assignments, it must register assignment
information in
a public
database (initially a database maintained by an RIR/NIR,
which may be replaced by a distributed
database for registering
address management information in future). Information is
registered
in units of
assigned /48 networks. When an organization assigns an
address space larger than a /48 to
another organization, it must
monitor if this organization has registered address
utilization
information in a
public database.
This para talks about an
organization (LIR) assigning an address space larger than a /48 to another
organization. In this case it implies that the other organization (NOT
THE LIR) must register its /48's in a public database and that the LIR must
ensure that the other organization has done this. But section 3.3
implies that every allocation be an a public database, and section 5.4
implies that it is not.
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.
Each registry shall handle personal
information with ultimate care.
Concrete methods of protecting personal data shall be in
accordance
with privacy
policies of each RIR/NIR (e.g., assign providers as
tech-c or admin-c, divide an address in the
middle, etc.).
5.7. Reverse lookup
When an RIR/NIR delegates IPv6
address space to an organization, it
also delegates the right to manage the reverse lookup
zone that
corresponds to the
allocated IPv6 address space. Each organization
should properly manage its reverse lookup
zone. When making an
address assignment, the organization must delegate to an assigned
organization, upon request, the
right to manage the reverse lookup
zone that corresponds to the assigned address.
5.8. Validity of allocations and
assignments
An allocation or assignment of
address space is valid only so long as
the original criteria on which the allocation or
assignment was based
continues to be valid.
If an allocation or assignment is
made for a specific purpose, but
the original purpose or original justification no longer
applies, the
allocation or
assignment shall become invalid.
If an allocation or assignment is
based on information that is found
to be false or incomplete, the allocation or assignment
shall become
invalid.
Invalid allocations shall be
returned to the appropriate IR.
5.9. Existing IPv6 address space
holders
Once the policies described in this
document have been adopted, an
organization already receiving an allocation according
to the
"PROVISIONAL IPv6
ASSIGNMENT AND ALLOCATION POLICY DOCUMENT"
[RIRv6-Polices] is immediately eligible to having its
allocation
expanded to a /32
address block. 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
organization. Requests for
additional space beyond the minimum /32 size will be evaluated as
discussed elsewhere in the
document.
6. Special case
Special considerations will be given
to the cases described below,
with no regard to the provision of this document.
Individual RIRs are
currently discussing policies for these cases independent of this
document.
6.1. IX (Internet Exchange)
An IX is a point at which ISPs
connect with one another. It requires
ISP-independent addresses.
7. Acknowledgment
The initial version of this document
was produced by The JPNIC IPv6
global 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 organized
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 RIPE-
NCC's IPv6 WG).
The editing team would like to
acknowledge the contributions to this
document of Takashi Arano, John Crain, Steve Deering,
Kosuke Ito,
Richard
Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun
Murai, Paul Mylotte, Thomas Narten, Ray
Plzak, Paul Wilson and
Wilfried Woeber.
8. References
[RFC1715] "The H Ratio for Address
Assignment Efficiency", C.
Huitema.
November 1994, RFC 1715.
[RFC1771] "A Border Gateway Protocol
4 (BGP-4)", Y. Rekhter, T. Li.
March
1995, RFC 1771.
[IAB-Request] "Email from IAB to
IANA", [XXX need better reference].
See IAB
Minutes, Dec. 12, 1998, <ftp://ftp.iab.org/in>-
notes/IAB/IABmins/IABmins.981208, <ftp://ftp.iab.org/in>-
notes/IAB/IABmins/IABmins.990112.
[RFC2373] "IP Version 6 Addressing
Architecture", R. Hinden, S.
Deering.
July 1998, RFC 2373.
[RFC2373bis]
draft-ietf-ipngwg-addr-arch-v3-07.txt.
[RFC2460] "Internet Protocol,
Version 6 (IPv6) Specification", S.
Deering,
R. Hinden. December 1998, RFC 2460.
[RFC2780] "IP Version 6 Addressing
Architecture", R. Hinden, S.
Deering.
July 1998. RFC 2373.
[RFC2928] "Initial IPv6 Sub-TLA ID
Assignments", R. Hinden, S.
Deering,
R. Fink, T. Hain. September 2000, RFC 2928.
[RFC3177] "IAB/IESG Recommendations
on IPv6 Address". IAB, IESG.
September 2001, RFC 3177.
[RFC3194] "The H-Density Ratio for
Address Assignment Efficiency An
Update
on the H ratio", A. Durand, C. Huitema. November 2001,
RFC
3194.
[RIRs-on-48] <http://www.arin.net/minutes/bot/bot08152001.html>,
XXX
fill
in.
[RIRv6-Policies]
<http://www.arin.net/regserv/ipv6/ipv6guidelines.html>,
<http://www.ripe.net/ripe/docs/ripe-196.html>,
<http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html>.
9. Appendix A:
In accordance with the
recommendations of "The Host-Density Ratio for
Address Assignment Efficiency: An update on the H ratio"
[RFC 3194],
it is proposed
in this draft to adopt an HD-Ratio of 0.8 as the
utilization threshold for IPv6 address space
allocations.
The following table provides
equivalent absolute and percentage
address utilization figures for IPv6 prefixes,
corresponding to an
HD-Ratio
of 0.8
P
48-P Total
/48s
Threshold Util%
48
0
1
1 100.0%
47
1
2
2 87.1%
46
2
4
3 75.8%
45
3
8
5 66.0%
44
4
16
9 57.4%
43
5
32
16 50.0%
42
6
64
28 43.5%
41
7
128
49 37.9%
40
8
256
84 33.0%
39
9
512
147 28.7%
38
10
1024
256 25.0%
37
11
2048
446 21.8%
36
12
4096
776 18.9%
35
13
8192
1351 16.5%
34
14
16384
2353 14.4%
33
15
32768
4096 12.5%
32
16
65536
7132 10.9%
31
17
131072
12417 9.5%
30
18
262144
21619 8.2%
29
19
524288
37641 7.2%
28
20
1048576
65536 6.3%
27
21
2097152
114105 5.4%
26
22
4194304
198668 4.7%
25
23
8388608
345901 4.1%
24
24
16777216
602249 3.6%
23
25
33554432
1048576 3.1%
22
26
67108864
1825677 2.7%
21
27
134217728
3178688 2.4%
20
28
268435456
5534417 2.1%
19
29
536870912
9635980 1.8%
18
30
1073741824
16777216 1.6%
17
31
2147483648
29210830 1.4%
16
32
4294967296
50859008 1.2%
15
33
8589934592
88550677 1.0%
14
34
17179869184
154175683 0.9%
13
35
34359738368
268435456 0.8%
12
36
68719476736
467373275 0.7%
11
37
137438953472
813744135 0.6%
10
38
274877906944
1416810831 0.5%
9
39
549755813888
2466810934 0.4%
8 40
1099511627776
4294967296 0.4%
7 41
2199023255552
7477972398 0.3%
6 42
4398046511104
13019906166 0.3%
5 43
8796093022208
22668973294 0.3%
4 44
17592186044416
39468974941 0.2%
DRAFT
[Page 20]
