[ppml] Policy Proposal: IPv4 countdown policy proposal
Member Services
info at arin.net
Thu Feb 22 10:59:06 EST 2007
ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.
The AC will review this proposal and may decide to:
1. Accept the proposal as a formal policy proposal as it is presented;
2. Work with the author to:
a) clarify the language or intent of the proposal;
b) divide the proposal into two (2) or more proposals; or
c) combine the proposal with other proposals; or,
3. Not accept the proposal as a formal policy proposal.
The AC will review this proposal at their next meeting. If the AC
accepts the proposal, then it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting. If the AC
does not accept the proposal, then the AC will explain that decision;
and at that time the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.
The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html
Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html
Regards,
Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Policy Proposal Name: IPv4 countdown policy proposal
Author: Toshiyuki Hosaka (Japan Network Information Center (JPNIC))
Co-Authors:
Takashi Arano (Intec Netcore, Inc.)
Kuniaki Kondo (Atelier Mahoroba)
Tomohiro Fujisaki (NTT)
Akinori Maemura (JPNIC)
Kosuke Ito (IRI Ubitech)
Shuji Nakamura (IPv6 Promotion Council)
Tomoya Yoshida (NTT Communications)
Susumu Sato (JPNIC)
Akira Nakagawa (KDDI)
Proposal Version: 1
Submission Date: 22 February 2007
Proposal type: new
Policy term: renewable
Policy statement:
- Set the date for termination of (IPv4) allocations and the
date of announcement
Set the date to terminate allocations as a general rule, and
announce it a certain period in advance. Define the date of
announcement as "A-date" and the date to terminate allocations
as "T-date". The two dates will be set as follows:
A-date (Date of Announcement):
- The day in which the IANA pool becomes less than 30*/8
- RIRs must announce "T-date" on this day, which is defined
later
(*) There will be no changes in the policy on A-date
T-date(Date of Termination):
- Exactly two years after A-date
- 10*/8 blocks should remain at T-date, and defined as two
years after A-date, based on the current pace of
allocations
- It is however possible to move T-date forward at the point
where address consumpution exceeds the projections during
the course of two years
(*) new allocations/assignments from RIRs should terminate
on T-date as a general rule. Allocations or assignments
to "critical infrastructure" after T-date should be
defined by a separate policy.
Rationale:
1. Introduction
The exhaustion of IPv4 address is approaching round the corner.
Geoff Huston's latest projection at Potaroo (as of January 6,
2007) (http://www.potaroo.net/tools/ipv4/) draws the date of IANA
pool exhaustion as 31st May 2011, and that of RIR pool as 14th
July 2012.
Tony Hain projects similar dates based on a different algorithm
of his own. From these data, we may observe that if that the
current allocation trend continues, the exhaustion of IPv4
address space is expected to take place as early as within the
next five years.
ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve
smooth termination of IPv4 address space as the Internet bodies
responsible for stable management and distribution of IP number
resources.
This proposal provides some ideas as well as concrete examples of
the policy that helps IPv4 allocations come to an end with "the
minimum confusion" and in "as fair manner as possible".
"Five years at the earliest" is not too far in the future for the
exhaustion of IPv4 address space. Assuming the minimum of one
year is required for sufficient policy discussions with this
proposal as a start, and two years for preparation and transfer
by LIRs, we need to start the discussions right at this time.
2. Summary of current problems
Despite the fact that several projections are made on IPv4
address to run out as early as within the next few years, no
discussions are taking place on any of the RIR's policy fora.
(we have submitted the same proposal to APNIC on January 2007)
This section lists possible problems if no policies are defined
to prepare for the terminal period of allocations.
2-1. LIR
LIRs currently do not consider IPv4 address exhaustion as an
imminent issue in the first place. It is possible that they will
finally realize the situation only when impacts of the
exhaustion becomes visible as a practical matter, and lead to
confusions such as re-addressing their network or making
subsequent requests at the last minute in within a limited time
frame.
There could also be cases where allocations blocks cannot be
allocated to some of the LIRs even though requests are submitted
on the same day. Moreover, although it would be necessary for
LIRs to announce to their customers that IPv4 address space will
not be available for assignments eventually, it is difficult to
plan this timing without clear policy for the last phase of
allocations.
As new IPv4 address allocations space will no longer be
available, LIRs have no choice but to build networks based on
IPv6. However, there are risks of trouble if preparations are
made from that point in time, as it will lead to premature
actions even if some time can be bought by re-addressing and
subsequent allocations.
Lastly, using up all available IPv4 address space will disable
assignments to services inevitable for co-existence of IPv4 and
IPv6 networks, such as the translator service between the two
networks, which it may create situation where transfer to IPv6
network will not even be possible.
2-2. RIR/NIR
It is likely that smooth allocations by RIRs/NIRs will be
hindered by rush of inquiries during the terminal phase of
allocations.
2-3. End users
End users generally receive address assignments from ISPs
accompanied with Internet connection service. If an ISP no longer
has IPv4 address space available, nor unable to provide IPv6
service, end users will not be able to receive services from that
ISP.
Moreover, if the terminal date of allocations remains ambiguous,
it may leave end users behind to prepare for IPv6 ready network.
3. Benefits
There will be the following benefits by implementing the policy
for IPv4 address exhaustion as proposed on this paper.
3-1. LIR
LIRs will be able to consciously plan their addressing within
their networks if the final date of allocations is clearly
demonstrated. Keeping a certain amount of unallocated address
blocks enables allocations/assignments for "critical
infrastructure" after the termination of regular allocations,
which will be explained later section in more details.
3-2. RIR/NIR
Announcing the date of terminating allocations in advance and
ensuring that all allocations before this date will be made
according to the policy at the time enables RIRs/NIRs to make the
last allocation without confusions and avoids causing feelings of
unfairness among LIRs and end users. In addition, consistent
policy applied to all RIRs removes bias towards certain region as
well as inter-regional unfairness. The period which IPv6 support
is completed becomes clear, therefore, RIRs/NIRs can prepare for
this.
3-3. End user
As this proposal enables LIRs to prepare for the terminal period
of allocations in advance, it reduces the risk of delays/
suspensions of assignments from LIRs to enduers, and end users
will be able to continuously receive services from LIRs. As in
the case of LIRs, end users will be able to prepare for IPv6
support by the date of allocation termination is clarified. In
addition, IPv6 connectivity as well as IPv4 address required
during the allocation termination period will be smoothly
secured by LIRs preparing for such period.
As listed above, there will be important, notable benefits for
stakeholders as a result of this policy. It is therefore
necessary to take the following actions to achieve a smooth
transfer to IPv6 and prevent causing instability in the Internet
as well as;
- start discussions on allocation scheme during the exhaustion
period,
- indicate a roadmap to exhaustion after raising awareness on
the issue, and
- allow enough time for LIRs to plan timing of addressing of
their networks, submit allocation requests, and consider
how to switch to IPv6.
4. Proposal principles
As the first step to discuss IPv4 exhaustion planning, we would
like to have an agreement(consensus) on the following four
principles.
--------------------------------------------------------------------
(1) Global synchronization:
All five RIRs will proceed at the same time for measures
on IPv4 address exhaustion.
(2) Some Blocks to be left:
Keep a few /8 stocks instead of distributing all.
(3) Keeping current practices until the last moment :
Maintain the current policy until the last allocation.
(4) Separate discussions on "Recycle" issue :
Recovery of unused address space should be discussed
separately.
--------------------------------------------------------------------
(1) Global synchronization:
All RIRs must proceed at the same time to take measures for
IPv4 address exhaustion. This is important not only for
ensuring fairness for LIRs across the regions, but alsot to
prevent confusions such as attempts to receive allocations
from an RIR outside their region. The five RIRs should
facilitate bottom-up discussions, which should be well
coordinated under the leaderships of ICANN ASO and NRO.
(2) Some blocks to be left:
It is not practical to consider that IPv4 address blocks can
be allocated to the last piece. It is expected to cause
confusions if one party can receive an allocation while the
other has to give up, just with a touch of a difference. The
best solution to avoid such confusion is to set in advance,
a date in which one is able to receive an allocation if
requests are submitted before this timeline.
Furthermore, there are few cases where allocations or
assignments of IPv4 address space become absolutely necessary
in the future. For example, requirements to start a
translator service between IPv4 and IPv6 networks should be
supported, and there may be some requirements in the future
that are beyond our imagination at this current moment.
As such, a date to stop allocations under the current policy
should be set/defined so that certain number of IPv4 address
blocks will be kept as stocks instead of allocating all blocks
without remains.
(3) Maintaining current practices until the last moment :
Allocations should be made based on the current policy until
the time to terminate allocations. As the IPv4 Internet has
now developed into a social infrastructure supporting large
number of businesses, making large changes in the current
policy towards conservation within the next one or two years
will lead to large-scale confusions, and difficult in the
reality.
(4) Separate discussion from "Recycle" issue
Recovering unused allocated/assigned address blocks is an
important measure, and in fact, it has already be discussed
and implemented in each RIR regions. This issue, however
should be considered separately from this proposal as
recovery of a few /8 blocks extends the lifetime of IPv4 for
less than one year while efforts for the recovery is expected
to require substantial time.
5. Rationale for "A-date" & "T-date"
A-date is set in order to:
- Allow some grace period and period for networks to be IPv6
ready until the termination of allocations.
- Prevent unfairness among LIRs by clarifying the date, such
as not being able to receive allocations by a small difference
in timing.
The rationale for setting A-date as "when IANA pool becomes less
than 30*/8" is as follows:
The rate of allocations from IANA to RIRs after 2000 is as
follows.
2000 : 4*/8
2001 : 6*/8
2002 : 4*/8
2003 : 5*/8
2004 : 9*/8
2005 : 13*/8
2006 : 10*/8
Approximately 10*/8 has been allocated annually after 2003,
and the consumption is likely to accelerate with rise of the
last minute demands.
As it is better to keep minimum stocks of address pool at
IANA, 30*/8 is set as the threshold value, and allocations
should be terminated two years after it reaches the value,
which ensures that IANA/RIRs secure the address space for
allocations/assignments to critical infrastructure.
6. Effect on RIR members
RIR members are expected to concretely grasp the termination date
of allocations and take actions within their organization to
prepare for the event.
Timetable for implementation: Immediate after all 5 RIRs ratified this
policy.
More information about the ARIN-PPML
mailing list